On May 31, 2013, at 7:44 AM, "John R Levine" <[email protected]> wrote:
>> Sorry, I missed the URL to the "Build an appropriate DMARC record" form that
>> has the distilled wisdom of someone that has read every post to this list.
>> Especially the official DMARC record creator tool with the "Do you have
>> users that subscribe to email lists?" radio button that disables the rest of
>> the form when I choose Yes.
>
> Snarkage aside, this question is going to keep coming up,
I am very happy to see that my point wasn't entirely lost.
> and while I don't expect most mail system operators to be as clue resistant
> as, ah, some,
Thanks John, for putting the snarkage aside.
> we're going to have the same set of issues that came up with SPF -all for
> people who naively imagine that more restrictive policies are always better.
> and who have users who do what users do with sending from Gmail and Yahoo,
> mailing lists, and all the other stuff we know about.
>
> As it stands, the best advice I can give to people about implementing DMARC
> is to collect the statistics, but do not publish a policy or believe policies
> that other people publish, which is unfortunate.
Telling people to collect the statistics assumes they can read the stats and
achieve the same level of understanding about their message streams as you get
from reading them. That seems excessively optimistic.
We should be able to agree that it's not helpful to say, "you're doing it
wrong," when there is scant information available to users (think: Domain
Owners) about how to use DMARC policy correctly. Reading over Section 10 of the
draft would lead a domain owner to believe that they could and should
eventually use a policy of p=reject with pct=100. Section 2 has a mention of
mailing list issues, but the content implies that the limitation is solvable.
Considering that phishing or a joe job event will often be the impetus for a
domain owner to deploy DMARC, its limitations with regard to p= values is
something we should be abundantly clear about in sections 10.2 and 6.2. What
is missing is a disclaimer, to read the limitations section, which should say
something like this:
LIMITATIONS
DMARC policies are not appropriate for domains with users who send mail through
mailing lists or forwards. SPF does not (generally) cover this use case and
DKIM signatures are routinely invalidated by mailing lists that append trailers
and subject prefixes. When users send email to email lists from a domain with a
reject or quarantine policy, recipients whose mail server performs DMARC
validation may block the message. Consequently, DMARC validators SHOULD attempt
to distinguish among message streams from well behaved mailing lists and
whitelist them.
Being explicit and expressing limitations like this in the draft and FAQ will
go a long ways towards setting appropriate expectations.
Matt
_______________________________________________
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)
