On Jan 25, 2014, at 6:49 AM, J. Gomez <[email protected]> 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
>> harmless,
>> 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 ( [email protected]
> ) do pass a plain-SPF check because the sending IP address ( 208.69.40.157 )
> is allowed for the domain of the MAIL-FROM address (
> [email protected] ) 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.
https://community.intuit.com/questions/891872-my-emails-are-not-being-sent-because-of-dmarc-could-somebody-of-quickbooks-tell-me-how-to-fix-it-or-better-yet-can-anybody-of-quickbooks-fix-it-after-all-is-a-paid-service-and-is-not-too-much-useful-if-i-can-not-send-a-simple-invoice-to-my-customers?jump_to=answer_2099361
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.
Regards,
Douglas Otis
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
