I’ve played around a bit with Gmail, Hotmail/outlook.com, and Outlook desktop client. Here’s what I have found so far.
Gmail and Hotmail have similar but not identical behavior: 1. If the 5322.From address is in your address book or you have a conversational history (implicit contact) or is on your safe senders (in Hotmail), then Gmail, Hotmail, and Outlook show only the Friendly From (display from) and not the 5322.From full address. If it isn’t in your contacts, then all show the display from + 5322.from email address. 2. If the 5321.mailfrom is different than the 5322.From, Gmail shows “Display From <and 5322.From if not in address book> via 5321.mailfrom” whereas outlook.com and Outlook desktop don’t show the discrepancy at all (i.e., no equivalent of ‘via’ in Hotmail or Outlook desktop). Gmail does not show the via if the 5322.from domain and 5321.mailfrom domains are the same which is why there is a recommendation to authenticate with SPF and DKIM. 3. Neither Gmail nor Hotmail show the Sender: header at all. Outlook desktop shows “<sender> on behalf of <from>.” I haven’t done a large matrix of testing but I have played around with different rendering; obviously, spam filtering and searching for conversational history may have something to do with it, too. -- Terry From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Brandon Long Sent: Wednesday, April 22, 2015 5:29 PM To: Douglas Otis Cc: dmarc ietf Subject: Re: [dmarc-ietf] Dmarc-escape draft available Gmail will display the Sender information with a on behalf of or similar in certain circumstances when we think its necessary to give the user more information. 99% of users won't use the more information for anything useful or even really notice it or at best get confused, but eh. More information: https://support.google.com/mail/answer/1311182?hl=en So, the messages on this list have "via ietf.org<http://ietf.org>" next to the author, for example. Brandon On Wed, Apr 22, 2015 at 10:58 AM, Douglas Otis <doug.mtv...@gmail.com<mailto:doug.mtv...@gmail.com>> wrote: On 4/21/15 4:20 PM, Terry Zink wrote: > Some quick comments: > > - Section 3 is really short. Some examples of how it would work would be nice. > - Regarding this from section 3: > > This makes an assumption users employ Mail User Agents that display the > identity contained in the Sender header field when used as a basis > for acceptance. > > I've tested Hotmail and Gmail and both suppress the Sender: header in favor > of the 5322.From address. Conversely, Outlook and Outlook Web Access (OWA) > show it as "<sender> on behalf of <from>". > > -- Terry > On 4/21/15 4:20 PM, Terry Zink wrote: > Some quick comments: > > - Section 3 is really short. Some examples of how it would work would be nice. > - Regarding this from section 3: > > This makes an assumption users employ Mail User Agents that display the > identity contained in the Sender header field when used as a basis > for acceptance. > > I've tested Hotmail and Gmail and both suppress the Sender: header in favor > of the 5322.From address. Conversely, Outlook and Outlook Web Access (OWA) > show it as "<sender> on behalf of <from>". > > -- Terry Dear Terry, You make a good point. I consider <sender> on behalf of <from> a reasonable approach. It takes seconds using OS X Mail (Mail, Preferences, Viewing, Show message headers: custom, type Sender) to display the Sender header. It is not displayed when it is not there of course, nor is this setting the default. For Thunderbird, users will need to access Preferences, Advanced, General tab, click Config Editor, Enter mail.compose.other.header and double click mail.compose.other.header entry and type the desired headers in the string dialog. For other MUAs beyond Outlook, Mail, and Thunderbird, this may require plugins or similar tinkering. Nonetheless, Sender header protection is available and likely something better configured using a script offered by the provider. In the early days when working with Iconix, they were able to offer fairly comprehensive coverage for web access and MUA using javascript overlays with company icons. This improved source trust based on verification methods then available. It seems these MUAs offer proof it can be done and Iconix proved people could understand the results. This seems rather important since it is the Sender being trusted in most cases; the result of mail's store and forwarding protocol. DKIM and SPF only offer assurances between hops. Use of IM-From better protects the role of author and enables improved availability for direct paths while also offering greater flexibility at adding easily noticable information. http://tools.ietf.org/html/draft-otis-dmarc-escape-00 Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org<mailto:dmarc@ietf.org> https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
