Brandon Long writes:

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

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

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.

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

Reply via email to