[dmarc-discuss] missing part of the DMARC FAQ, was is it safe to reject?
doug.mtview at gmail.com
Fri Jun 6 09:29:33 PDT 2014
On Jan 25, 2014, at 6:49 AM, J. Gomez <jgomez at seryrich.com> wrote:
> On Friday, January 24, 2014 4:46 PM [GMT+1=CET], John Levine wrote:
>>>> 1. the listserver implement none of http://dmarc.org/faq.html#s_3
>> None of the current advice is useful for people who don't want to
>> screw up useful features of their lists. (The "OAR" header is
>> but doesn't fix the innocent victim bouncing off the list problem.)
>> Please add this bullet above the first one:
>> * Check DMARC on incoming mail, and refuse mail to the list from
>> domains that have a p=reject or p=quarantine policy.
>> I have actually implemented this on my running lists.
> And what about this additional bullet in that section of the FAQ:
> * Check plain-SPF before checking DMARC, and if SPF-result is pass then skip DMARC processing.
> For example, messages coming from this mailing list ( dmarc-discuss at dmarc.org ) do pass a plain-SPF check because the sending IP address ( 22.214.171.124 ) is allowed for the domain of the MAIL-FROM address ( dmarc-discuss-bounces at blackops.org ) in its SPF record in DNS.
> So if you would do an old-style SPF check before the DMARC check, and the result is pass, then you could skip the DMARC processing altogether and no mailing list problem would arise. Ain't it so? After all, DKIM itself does not state policy, but SPF itself is indeed capable of stating policy...
Dear J. Gomez,
Although SPF can state a policy, this is largely ignored since its use results in a significant loss of legitimate email. By significant, this may even mean even less than 1%. Recommendations pushing DMARC p=quarantine or p=reject for domains serving normal emails users is sure to also cause DMARC policy requests to fall into the same category of being ignored and that would be a shame. This will mean emails being lost with endless reminders to check spam folders. Not a bright future.
I can't have a ML exchange with Yahoo without doing this. I want to know who sent the message and be able to review what they said in the past. Either that means there can be no subject tags or list footers or the original DKIM will not survive. Even suggesting that mailing-lists should "own" the From header field would be suggesting a ML that offers a far less effective method to communicate. Even suggesting what ML can do to retain their DKIM signature MUST NEVER extend to suggesting what a receiver can do to fix ML or Intuit like issues. Only suggest what the sender can do.
For those who insist it is unreasonable to determine what valid and venerable third-party services your users employ, it is doubly unreasonable to suggest that this should be the tasked of receivers. You as a sender obtain ample information regarding which of your users email subsequently fails an alignment check. Even to the point of exposing those who never send a single message to the list. Once again, there is a proposal for the sending DMARC domain "own" this issue called TPA-Label.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dmarc-discuss