I'm working on an Outlook Web Add-In and I'm struggling with knowing what value to set for the X-Frame-Options: ALLOW-FROM header. As far as I know, users may access Outlook via three different domains (office.com, office365.com and live.com). Does anyone know how I can tell which site is making the request, so I can set the header appropriately?
The add-in needs to be able to run in an iFrame in order to work in Outlook Web, thus X-Frame-Options header should not be included at all. ALLOW-FROM can't really be used because the number of domains to list is way more than 3 mentioned, and that list is growing – there are many cases where various users access Office365 and outlook.com using custom domains.
Related
I tried and searched a lot to track email client but i am getting to use other bananatag or mailchimp tool. I dont want to use other tools. i only want to track which email client is being used or on which email client the mail has been opened.
I tried capturing via HTTP_USER_AGENT but did not get only got the browser information. Used document.referrer too but it returned "" .
How do mailchimp , banantag and other campaign tools figure out the mail client?
Every email client will send a user agent string, but Google Analytics is optimized for web browser hits. The email tracking vendors have accumulated the user-agent signatures of the most common email clients and do the mapping for you. (See for instance Udger Email Client List.)
The GA interface does not give you direct access to the user-agent strings of your hits, so you can't implement this mapping yourself.
One can hope that as more clients use the GA measurement protocol for email tracking the GA team will see the need to provide alternative mappings. When you know your hits are coming from email clients, it makes very little sense to map to web browsers.
As an particularly insidious example, Google's own GMail product identifies itself with this user-agent string:
mozilla/5.0 (windows nt 5.1; rv:11.0) gecko firefox/11.0 (via ggpht.com googleimageproxy)
Which ends up making it look like your hits came from Firefox v. 11 running on Windows NT, according to the canonical GA mapping. :P
You can't track this information with Google Analytics. You'll have to survey your users and use statistical analysis to determine which e-mail client(S) they use.
You can track offsite activities with Google Analytics Measurement Protocol. So you can fool your email template to include a blank image that sends out a hit to Google Analytics on each open of the email.
<img src="https://www.google-analytics.com/collect?v=1&tid=UA-XXXXXXX-Y&cid=*|UNIQID|*&t=event&ec=email&ea=open&el=*|UNIQID|*&cs=email&cm=email&cn=*|CAMPAIGN_UID|*&cm1=1" />
(example from a Mailchimp newsletter template)
Then you can select as a dimension in your event reports the Browser/Browser version and have a look at them
This is based on this article from Lunametrics
Does it make a difference at all whether I serve the images in an email campaign from an encrypted domain? Will this make emails less likely to end up in a client's spam folder?
Using http insteadt of https will most likely not affect the spam/ham classification.
However, it could throw warnings in older browsers, which may confuse your recipients. The reason is because most webmail services - like Gmail, Outlook.com (former Hotmail), or Yahoo! Mail - default to SSL when the user logs in. Loading images from non-secure sources now is a possible security leak. This blogpost and the screenshot below illustrate the problem and the resulting browser behaviour.
Furthermore, you'll miss referrer information of a recipient who opened an email on https, when the tracking pixel is located just on http.
Finally, if you use https, make sure the certificate is valid and up-to-date. Otherwise email clients like Thunderbird throw warnings.
It doesn't make a difference. Almost everyone uses http:// without any spam hit, so there is nowhere for https:// to improve on that, even though spam filters are an accumulative score.
If there was something in either your content or reputation flagging you as spam, having https:// linked images wouldn't award you any 'bonus points' to save the day.
I second #lukeA's answer and would like to stress that the impact of using images served over http:// connections has certainly increased, even in web-based email clients.
See for example Google Inbox in Chrome (48.0.2564.109), before and after looking at an email which includes an image served over http:// (in that case, a spam email). Note the green lock is gone until you refresh the page!
Gmail's image proxy serves all images over https:// - however, it is unclear (to me) for which images the proxy is really used. For that particular spam mail that I opened to create the below snapshots, it certainly isn't.
We have a newsletter that uses media queries to display it in a responsive format for smaller screens. It displays as it should in Outlook, but when the email is forwarded on, it appears that Outlook is removing the media query code. We are using Outlook to send the email since we have exchange lists that we need to include. Does anyone know if there is a way around Outlook removing the media query code when forwarding, or another way to send an email with media queries through Outlook?
Unfortunately Outlook uses it's industry famous Microsoft Word render engine to reinterpret html email. This means that when forwarding, your email is full of MS garbage and, in this case, removing some of the original wanted code.
I've had issues with some corporate exchange servers stripping media queries - I think caused by their security software. Try sending to a different domain.
Best way to see if it is stripping your media queries is to check your email code. Scroll to the bottom of your email and right click>view source just inside your Outlook viewing window.
If sending to a different domain doesn't work, I'm afraid you may be out of luck as there is no way to force Outlook to preserve your original code.
Are you sending the newsletter via an Outlook email merge?
If you want better control, use a email newsletter service like Aweber or Constant Contact.
Granted, you need your contacts to opt-in but this shouldn't be a big problem if they want your newsletter.
I'm trying to get a mailto link that would open a new outlook email window with a modified from field (i.e. to use a secondary account as it were). Is that possible?
No. Certainly not in most of the popular mail clients.
I assume you are wanting to do this just to save time in your own mail client. I would certainly be annoyed with a website that tried to change my from or reply-to address, so I'd expect my mail client to ignore it.
MAILTO is designed to facilitate a sender contacting an address that has been listed on a website. So there are very few things that the sender would expect to have dictated by the website. Even the standard options can be pretty annoying if handled badly by the website owner.
Your options are pretty much limited to
subject
body
cc
bcc
Even if a client were to support From (and I am not aware of any that do), there is no obvious way for them to handle edge-case scenarios such as a from address that has not been configured in the mail client.
What do you need this for? Perhaps you can use a script to send mails and dynamically set the From header. For example, PHP has a mail() function which would allow you to set a custom From address (and modify other headers).
I have a client who needs some html mass emails sent. I've coded the email, but for some reason, probably a problem with their mail client, the test emails they've received have been marked with low importance.
I believe I could override this by adding an x-priority header to the email, however the mass mail service I'm forced to use (have no choice about this unfortunately) won't allow me to customize headers.
Is it possible to set the header within the actual body of the email? Are there html tags that allow for this?
No. Email HTML is just markup, and clients don't read the content for headers.
Which client are they using? Some clients (Hotmail, Gmail) analyse the content and assign their own rule, so there is no header you can change. This is done at the mailserver level, so if a user's client is, say, Thunderbird but their server is Gmail, it may still mark as low priority based on Gmail's rules.
If the client is Outlook and the mailserver is an in-house Postfix installation (for example), then you can set X Headers but by default, Outlook will strip them. For this reason, I suspect either the server or the client is setting the priority, it's not at the send level.
Look at the original source, and see whether or not it does contain the Priority header.