Subject: [dmarc-ietf] Yet another mailing list solution thread

From: Brandon Long <[email-masked]>
Date: Fri, 30 May 2014 01:13:07 -0700

What can mailing lists do today

1) Reject posting from p=REJECT users
2) Re-write From header for p=REJECT/QUARANTINE users
3) Don't break the DKIM signature (no subject prefix, no footer)
4) Recognize DMARC reject bounce messages and don't consider them as reason
to unsubscribe users
5) Add a sender header and sign their messages with DKIM
6) Add an Authentication-Results header with the auth-results for the post.
 Consider adding an OAR header as well (though, this may be premature).

It seems like #4 should be relatively uncontroversial, arguably there are
whole classes of bounce messages which don't indicate that all future
messages would be rejected... Perhaps we should agree on an extended smtp
status code that such rejections should use in order to make this easier to
implement.  I also realize that for some servers, the increased rate of
bounces, even if they're to be ignored, is itself a problem, which means
one of 1-3 would need to also be implemented.

#2 could potentially use some finessing or standardization.  For example,
several MLMs are moving the original From header to X-Original-From, I
could also imagine a List-Original-From or List-Poster header.
 Standardizing on that would allow clients to do intelligent things about
the display of the two pieces of information, or handling reply-to better.

#5 won't fix DMARC alignment, but its a step in the authenticated mail
direction, and likely to be necessary for any next steps such as OAR

What can DMARC enforcing domains do right now:
1) Whitelist mailing lists from enforcement.  This is obviously a hole in
DMARC which lowers the overall utility.  Its basically saying "we don't
trust your p=REJECT, we'll sometimes downgrade it to p=QUARANTINE".

2) Put a really simple DKIM signature on messages which doesn't cover the
subject/body.  Ick, but it could theoretically be done.

The Future
1) Support Original-Authentication-Results.  This requires the MLM to add
them in the first place, and for the DMARC enforcing domains to check them.
 Has an open question of how best to "trust" the OAR header on a message.
 Options there are explicit whitelists from the sending domains (tpa-labels
or whatever) or to leave it up to the individual receiving domain.

2) A new mailing list specific DKIM canonicalization.  Its unlikely to be
possible to be 100% authentication, its open for debate whether we could
come up with one that'll provide some level of auth that may be useful in a
more complicated "spam/phishing evaluation".

3) Some sort of "permission to relay" token.  This is pretty similar to the
DKIM above.

4) Plain old whitelisting (tpa-labels or whatever).  Personally, I think
without AuthRes/OAR, this is too big a hole to be useful.

5) More radical changes to MLMs/clients such as defining new headers with
associated client requirements (ie, the footer / subject prefix is
theoretically redundant with the adoptions of List-* headers).  Other
alternatives include embedding the original message in a wrapper (a
message/digest of one).  Are there any other clients besides mutt which
handle this well?

Other ideas?

Brandon

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 31 May 2014 00:08:21 +0200

Brandon Long wrote:
> 4) Recognize DMARC reject bounce messages and don't consider them as
> reason to unsubscribe users 
> 6) Add an Authentication-Results header with the auth-results for the
> post.  Consider adding an OAR header as well (though, this may be
> premature).  
> 
> (snip)
> #2 could potentially use some finessing or standardization.  For
> example, several MLMs are moving the original From header to
> X-Original-From, I could also imagine a List-Original-From or
> List-Poster header.  Standardizing on that would allow clients to do
> intelligent things about the display of the two pieces of
> information, or handling reply-to better.

I think #2 is the way to go, and in my opinion for consistency that re-write of the From header should be done to all messages relayed trough the list, irrespective of the Sender's published DMARC policy. This also would make DMARC-checking a task not-for-the-mailing-list-program, which is better because it's simpler.

In my opinion, all the other options are either too complex, too expensive, or depend on non-encouraged third parties whose collaboration is doubtful.

Regards,
J.Gomez

---

From: "John Levine" <[email-masked]>
Date: 31 May 2014 03:10:56 -0000

>or whatever) or to leave it up to the individual receiving domain.

This keeps reducing to the previous case.  If you know what senders
you trust, why do you need the OAR header?

R's,
John

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 31 May 2014 22:07:06 +0900

> 1) Reject posting from p=REJECT users

+1 <0.2 wink>

 > It seems like [ignoring DMARC bounces when checking if the
 > recipient is able to receive] should be relatively uncontroversial,

Mailman is already working on this.  Unfortunately, some domains just
use a generic 5.7.x policy bounce, and other don't even give you that
much information.  (We are guessing, but backtracking to the sender --
you don't always even get that information -- and correlating with
other DMARC bounces, we're pretty sure that these are DMARC bounces.)

 > messages would be rejected... Perhaps we should agree on an
 > extended smtp status code that such rejections should use in order
 > to make this easier to implement.

This will take years to diffuse into the installed base, and some
sites have this boneheaded idea that giving any information about why
a message was rejected harms their security, so won't implement anyway.

 > [Rewriting From:] could potentially use some finessing or
 > standardization.  For example, several MLMs are moving the original
 > From header to X-Original-From, I could also imagine a
 > List-Original-From or List-Poster header.  Standardizing on that
 > would allow clients to do intelligent things about the display of
 > the two pieces of information, or handling reply-to better.

The *last* thing we want is clients doing anything intelligent with
any of those headers.  The problem that DMARC addresses has nothing to
do with the letters F-R-O-M.  It has to do with identity alignment.
It just happens that RFC5322 (and predecessors) standardized From: for
conveying originatory identity.  So as soon as MUAs start displaying
Use-This-Field-To-Bypass-DMARC: to users, DMARC will *need* to be
revised to sign that one, too -- with a signature authorized by the
Author Domain, *not* the ML domain.  This of course is impossible
without Doug Otis's TPA-labels or something like that.

 > trust your p=REJECT, we'll sometimes downgrade it to p=QUARANTINE".

That horse already left the barn.  I don't know what GMail's criterion
is, but our testing demonstrates that some mailing list posts are
passed through to the spam folder rather than rejected.

I don't understand what you mean by "lowers overall utility".  In
fact, it's quite clear from the way Yahoo! is advocating various
mitigation strategies that they really do not mean DMARC reject, they
mean Do-What-I-Mean reject.  That's what GMail gives them.

For the others, I agree with John Levine's comments.