----- Original Message -----
> From: "Barry Leiba" <barryle...@computer.org>
> To: "Franck Martin" <fra...@peachymango.org>
> Cc: "Dave Crocker" <dcroc...@gmail.com>, dmarc@ietf.org, "Murray Kucherawy"
> <superu...@gmail.com>
> Sent: Wednesday, April 16, 2014 10:12:55 AM
> Subject: Re: [dmarc-ietf] DMARC's purpose
>
> >> I'm not sure that any issue with mailing lists is documented in
> >> draft-kucherawy-dmarc-base at all, well or otherwise. A search for
> >> "mailing list" (or even "mailing") shows hits in three places, all in
> >> back matter, none of substance.
> >>
> >> There's nothing that I can see anywhere that warns of possible
> >> consequences (neither considerations for the domain publishing the
> >> policy nor discussion of collateral damage to mailing lists) of using
> >> "p=reject" -- not in the explanation of "p=reject", not in Section 6
> >> ("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting
> >> Messages"), not in the Security Considerations.
> >>
> >> Where is [it] well documented?
> >
> > In the upcoming BCP
>
> 1. I don't see it adequately covered there, on a quick scan. I
> haven't read it thoroughly, though.
Work in progress, feel free to submit some text to Dave.
>
> 2. There is no reference from dmarc-base to dmarc-bcp, not even an
> informative one. And this is an important enough consideration that I
> think it should be a normative reference.
>
> > Should we also document in this Murray's draft that MS-Exchange
> > breaks DKIM on forwarding, inventory all the operational cases? I
> > don't think so. The draft is to describe the protocol, the BCP is here
> > to document on how to operationally deploy and use it.
>
> I can't parse the first sentence, nor figure out what you're trying to
> refer to. But to answer the question that's behind what I think
> you're asking: Yes, we should document, either in the specification or
> in an Applicability Statement that the specification cites as a
> normative reference, considerations that are critical to getting the
> configuration right.
It is well know that MS-Exchange breaks DKIM on forwarding by design, therefore
breaks DMARC. It is not a trivial problem. Also Blackberries, break DMARC too.
Should we cite all these cases in the draft? Make a laundry list?
We always said do monitor mode and then decide if it makes sense to move to
p=reject.
Besides section 2.4 says it is out of scope:
Handling of undesirable or malicious mail that is coming from the
domain from which it claims to be sent.
>
> It's fine to separate the protocol bits and the "other information"
> into different documents, but it *all* has to be there in order to
> fight against misconfiguration and the damage that can cause.
>
As far as I can see (I just did another search on the RFCs) there is no
misconfiguration as there is no normative RFC to define what a mailing list is,
how it operates, how it handles bounces, subscriptions, etc..... I think this
is what Ned was referring to in his post.
Section 15.4 gives some advice to all sending systems:
In the latter case, when doing an SMTP rejection, providing a clear
hint can be useful in resolving issues. A receiver might indicate in
plain text the reason for the rejection by using the word "DMARC"
somewhere in the reply text. Many systems are able to scan the SMTP
reply text to determine the nature of the rejection, thus providing a
machine-detectable reason for rejection allows automated sorting of
rejection causes so they can be properly addressed.
I don't see the issue with mailing lists (and other systems) be different from
doing appropriate bounce processing.
So I propose the following to be added in 15.4:
Some forwarding systems (including some mailing lists) are notably known to
have a simple bounce processing system, in such cases, the forwarding system
may consider after a few bounces that the recipient address is not valid
anymore and unsubscribe such recipient.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
