Subject: [dmarc-ietf] Dmarc-escape draft available

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Apr 2015 16:10:14 -0700

Dear WG,

A draft has been posted offering two alternatives not
requiring cooperation of disruptive ESPs.

Basic unilateral escape methods include use of a From
replacement header IM-From:. This header can include the tag
normally added to the Subject line as the display name in
the Group syntax.  It also includes a placeholder for
resource connection used in a "live" discussions, hence the
use of IM. This header is free to carry the author role
since it will not be excluded by DMARC policy. The other
unilateral mode is to defined a DMARC fallback policy 'p'
for public user accounts.  This mode permits acceptance
based on the Sender header field alignment with assumed MUA
displaying the identity sourcing the message.

It also attempts to remove concerns related to adoption of
TPA-Label from the perspective of large providers by
allowing DMARC policy to indicate a consolidated tpa-label
zone rather than being directly accessed from the customer's
zone. This avoids use of DNAME or zone delegations.

While TPA-Label may appear to contain too much information,
all of it is optional. The goal behind providing a structure
for additional third-party information is to allow
anticipated limitations be imposed on the scope of
authorization granted.  This scope also selectively permits
other authentication methods be accepted beyond just DKIM or
SPF. It is able to indicate the message must be DKIM signed
AND must contain a specific LIST-ID header, for example. 
This ensures recipients in this domain can depend on safer
sorting of disparate messages sources from the same domain.

http://tools.ietf.org/html/draft-otis-dmarc-escape-00

Regards,
Douglas Otis

---

From: Terry Zink <[email-masked]>
Date: Tue, 21 Apr 2015 23:20:02 +0000

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

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Tuesday, April 21, 2015 4:10 PM
To: dmarc ietf
Subject: [dmarc-ietf] Dmarc-escape draft available

Dear WG,

Regards,
Douglas Otis

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Apr 2015 10:58:03 -0700

>   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>".

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.

Regards,
Douglas Otis

---

From: Brandon Long <[email-masked]>
Date: Wed, 22 Apr 2015 17:28:44 -0700

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" next to the author, for
example.

Brandon

On Wed, Apr 22, 2015 at 10:58 AM, Douglas Otis <[email-masked]>
wrote:

> >   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
> >
>
> >   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,
>

---

From: Terry Zink <[email-masked]>
Date: Thu, 23 Apr 2015 17:33:53 +0000

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:[email-masked]] 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.

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 <[email-masked]<mailto:[email-masked]>> wrote:

Dear Terry,

Regards,
Douglas Otis

_______________________________________________
dmarc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 Apr 2015 13:46:35 -0400

Since the core lookup key off of which everything in DMARC is based is the 
5322.From, if you change to use something different, is it even DMARC anymore?

Scott K

On Thursday, April 23, 2015 05:33:53 PM Terry Zink wrote:

I’ve played around a bit with Gmail, Hotmail/outlook.com, and Outlook desktop 
client. Here’s what I have found so far.

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

 
99% of users won't use the more information for anything useful or even really 
notice it or at best get confused, but eh.

 
Brandon
 
On Wed, Apr 22, 2015 at 10:58 AM, Douglas Otis <[email-masked]> wrote:

Dear Terry,

Regards,
Douglas Otis

---

From: Terry Zink <[email-masked]>
Date: Thu, 23 Apr 2015 17:53:30 +0000

Doug,

> It takes seconds using OS X Mail …
>
> For Thunderbird, users will need to access …
>
> For other MUAs this may require plugins or similar
> tinkering…
>
> Nonetheless, Sender header protection is

Requiring users to have to do something is not a good solution because the average user doesn’t understand and won’t do it. We’d have to convince mail clients to show it by default, and at least two large providers (Hotmail and Gmail) don’t do it today, and most largely-deployed mail clients don’t, either (Outlook being an exception).

I don’t understand the flow of things for a Sender: header alignment that you propose. Is it something like this:

Message 1
========
5321.MailFrom: <[email-masked]>
From: Terry Zink <[email-masked]>
Sender: Terry Zink <[email-masked]>
To: mailing list <[email-masked]>
Subject: Here is a message
DKIM-Signature: d=example.com [Signature is intact]

Message 2 after replaying
===================

5321.MailFrom: <[email-masked]>
From: Terry Zink <[email-masked]>
To: Doug Otis <..>
Sender: Terry Zink <[email-masked]
Subject: [MAILING LIST] Here is a message
DKIM-Signature: d=example.com [Signature broken]
DKIM-Signature: d=mailing-list.com [Signature intact]

What’s supposed to happen next?

-- Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Terry Zink
Sent: Thursday, April 23, 2015 10:34 AM
To: Brandon Long; Douglas Otis
Cc: dmarc ietf
Subject: Re: [dmarc-ietf] Dmarc-escape draft available

-- Terry

Brandon

Dear Terry,

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Thu, 23 Apr 2015 15:34:06 -0400

No.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Apr 2015 17:18:29 -0700

> Message 2 after replaying
If DMARC is not in the way and forgoing friendly names...

5321.MailFrom: [email-masked]
From: Terry Zink <[email-masked]>
To: Doug Otis <..>
Sender: [email-masked]
Subject: [MAILING LIST] Here is a message
DKIM-Signature: d=example.com [Signature broken]
DKIM-Signature: d=mailing-list.com [Signature intact]

When DMARC is in the way...
Message 2 after replaying
===================

5321.MailFrom: [email-masked]
From: [email-masked]
IM-From: [MAILING LIST]:Terry Zink <[email-masked]> 
To: Doug Otis <..>
Sender: [email-masked]
Subject: [MAILING LIST] Here is a message

Dear Terry,

Which is why is seems proper for popular MUA configurations
to be offered by the provider but we may need better hooks.

What happens with a message depends on recognized trust
establish with the sender, not just the from.
 
TPA-Label via DMARC feedback can help assist in preventing
the misapplication of trust.
> 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.

Where possible, disable friendly email displays. Too many
years offered plenty reasons not to trust its rules.

Iconix is a good example for what is possible with Web email
as well.  They greatly increase user comprehension while
affording better protection.

Show recipients verified information when possible. 
<Sender> on behalf of <From> at least shows identities
contained in both headers.  DMARC will not prevent all
spoofing, but a less disruptive scheme that does not require
name munging helps more than hurts.  People groping for
messages in spam folders hurts more than helps.   The
5321.mailfrom is not part of DKIM, only SPF which fails From
header alignment beyond the first hop for most mediated
messages.  Our domain asserts a DMARC record without
requesting either Reject or Quarantine and instead relies on
administrative relationships or LE after determining
malefactors.  It took a fair amount of effort, but we made a
difference in Turkey and Brazil, for example.

With DMARC, it is increasingly common to only see From
header fields or a munged From header field rather than a
proper Sender.  How does less verifiable information because
of DMARC policies help anyone?  Just as people are not
better protected using Chip and Signature rather than Chip
and Pin, the same can be said of email lacking proper Sender
header fields replaced by munged Froms. 

Regards,
Douglas Otis

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 25 Apr 2015 10:47:38 +0200

On Wednesday, April 22, 2015 1:10 AM [GMT+1=CET], Douglas Otis wrote:

> (...snip...)

I have dificulty parsing this paragraph:

"[DMARC] section 10.5 offers
   feeble advice by stating although mediator transformations may
   conform with standards, this may not avoid message Reject or
   Quarantine handling nor does it allow provisions for alignment with
   verified Sender header fields likely preferable to diverted placement
   of valid and legitimate messages."

I can, more or less, understand it, reading it like this (<blah> are additions I make to try to understand it):

"[DMARC] section 10.5 offers feeble advice by stating <that> although mediator transformations may conform with standards, this <-strike previous word-; they> may not avoid message Reject or Quarantine handling nor does it <-strike previous 2 words-; do them> allow provisions for alignment with verified Sender header fields <, which is> likely preferable to diverted placement of valid and legitimate messages."

Or something.

Regards,
J.Gomez