On 09/17/2013 08:04 AM, Franck Martin wrote:
----- Original Message -----
From: "Scott Kitterman" <[email protected]>
To: [email protected]
Sent: Monday, September 16, 2013 4:45:44 PM
Subject: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations
For DMARC
The recent discussion about moving ADSP to historical brought up the issue of
people being inadvertently unsubscribed from mailing lists due to rejecting
mail that failed ADSP tests.
Time to rush in where angels fear to tread :-)
AIUI, the following would happen:
- A user at a domain that signs DKIM and has an ADSP "discardable" policy
published sends a mail to a mailing list.
- Like most mailing lists, the mail gets munged and the signature is broken.
- At the border MTA of the domain of a subscriber that checks ADSP, it is
determined that the message fails ADSP and bounces/rejects it.
- Rejects/bounces from this user accumulate in the list manager and
eventually they get unsubscribed for excessive bounces.
Yes, and much the same scenario can arise for DMARC.
There are arguably several things done wrong here:
- Sending user: why are you sending mail to a ML with an ADSP protected
domain.
Because you can... You can't control all your users and it is hard to know when
an email address is the one of a mailing list...
As for the argument you should not put an ADSP on a domain with users, well,
any domain from a targeted entity becomes eventually a target that needs
protection too...
+1
This is a domain-owner's choice. They take their chances with the
consequences of course. What we're not able to do is provide a
child-safe environment in which there are no trade-offs and where
actions have no consequences.
- Receiving border MTA: why are you bouncing/rejecting and not discarding?
This is not "wrong", as the spec acknowledges
(draft-kucherawy-dmarc-base-01
<http://www.ietf.org/id/draft-kucherawy-dmarc-base-01.txt> 15.4). There
are strong arguments in favour of both SMTP refusal (5xx response) and
silent discard (2xx response, then delete the message); different
receivers will make different choices. This dilemma is part of why
mailing lists complicate the "let's authenticate everything" desire that
many people share.
Bouncing (2xx response, followed by generating and sending a new DSN to
the RFC5321.MailFrom) arguably is wrong - or at least unwise - because
it contributes to backscatter risk however, again, this is a receiver's
choice and some receivers may still do this.
Because they are told to do so by the policy, but with DMARC they can overwrite
the result, while it is not possible with ADSP (see what is a mailing list
question)
I don't think that was Scott's question; p=reject is a proposal by the
domain owner to the receiver refuse/discard/bounce at receiver's
discretion messages which fail both authentication methods. Scott
appeared to me to be positioning anything other than silent discard as
being "wrong" for p=reject. The DMARC spec makes clear that this is not so.
So in theory, this should be fine, but it's not. This (assuming I got it
right) is one of the arguments for moving ADSP to Historic (since it's not
only lightly used, it's known to cause damage when it does.
Barry or Dave may correct me on this, but the argument for moving ADSP
to historic is simply that its use is negligible (and perhaps that
having it retain a standards status may lead unwitting implementers
astray) and - in light of DMARC's adoption - unlikely ever to grow.
There is _*more*_ harm in ADSP than in DMARC (because DMARC adds various
protective and softening mechanisms: rua/ruf, p=quarantine, pct), but
this is more the driver for the adoption of DMARC than the argument for
moving ADSP to historic.
I got to thinking about this and asked myself how DMARC might be better in
than ADSP in this situation, and as far as I can tell, it's not.
In the sense that DMARC provides rua/ruf to improve a domain owner's
situational awareness and decision making, DMARC actually is
[marginally] better than ADSP in this situation, however this is the
wrong question. Interoperating with [existing] mailing lists is not part
of the goals of either protocol, consequently the failure to do so is
not a large concern.
It would be nice if it were straight-forward (or even possible) for this
level of interoperability to exist, but no-one can currently see a way
for this to work. This is largely because all technically viable
approaches require all mailing list operators to implement them ahead of
evidence that they're appropriate. Like everybody else, their budget for
speculatively expending resources in the hope that they might fix other
people's problems is rather small. The practical upshot is that any
receiver implementing DMARC filtering requires an accurate database of
mailing list servers which host lists to which the receiver's users are
subscribed. This is untidy but workable and, again, is not a large
concern because it doesn't impede DMARC's objective.
Most
mailing
lists use their own Mail From, so even if SPF passes on the mailing list
message, it won't have identity alignment.
Did I miss something?
Yes, ;)
Why the mailing list software would consider such a bounce as a hard bounce,
while it is clearly not and identified as such with extended smtp error codes.
For instance, EZMLM handles this better than Mailman by sending probes before
unsubscribing members.
That's clever; I'd wondered how it was avoiding the problem.
As a receiver, how do I know I'm dealing with a mailing list?
As part of your ongoing monitoring and assessing of mailstreams...
Why MLM have to break DKIM? It seems the lists at apache.org do not break DKIM
on transit and do not suffer these problems.
"Have to" is a bit strong, but see RFC 6377. To avoid DKIM breakage, a
list must avoid doing _*all*_ of those things.
I'd suggest that there is a way forward and not too much need to worry
about it:
* In the short term, receivers are likely to need to maintain a
database of list servers from which authentication failures can be
ignored. It would be helpful for such receivers to report this to
domain owners as reason={forwarded|trusted_forwarder|mailing_list}.
* As receiver adoption proceeds, it may be the case that mailing-list
mapping is of sufficiently low importance to enough receivers that
list operators start to see real (rather than hypothetical) benefit
in addressing this, in which case any of the following will work, at
the list operator's discretion:
o Leave the message sufficiently unaltered to still pass DKIM
o Replace the RFC5322.From with something that points to the list
operator
o Reject submissions from domains with p=reject (or reject only
those where the list's changes break the DKIM signature on the
message in question; noting that the signer determines what is
signed and therefore a given message's DKIM signature may break
for a given list, where others' wouldn't)
As with domain-owner use of p=reject on domains that aren't heavily
spoofed, or even the potential use of DMARC filtering by a receiver
without a mailing-list/forwarder database, the use or not of the
practices above by list operators should be positioned as "here's a way
to make this work if you wish to" not "you are irresponsible if you
don't do this".
- Roland
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
