On 09/17/2013 06:33 AM, Scott Kitterman wrote:
On Tuesday, September 17, 2013 10:50:32 Roland Turner wrote:
[...]
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.
We're in the middle of the ADSP part of the argument here and it was written
differently. Personally, I find silent discards to be abhorrent. They
interfere with the reliability and consistency of the mail system, but that's
perhaps just me.
You're not alone on this one: silently discarding mail cannot be
explained to the ordinary end-user of the e-mail eco-system. See [1] and
various opinions in [2]. RFC5321 section 6.2 addresses these concerns as
follows:
As discussed inSection 7.8 <http://tools.ietf.org/html/rfc5321#section-7.8>
andSection 7.9 <http://tools.ietf.org/html/rfc5321#section-7.9> below, dropping mail
without notification of the sender is permitted in practice.
However, it is extremely dangerous and violates a long tradition and
community expectations that mail is either delivered or returned. If
silent message-dropping is misused, it could easily undermine
confidence in the reliability of the Internet's mail systems. So
silent dropping of messages should be considered only in those cases
where there is very high confidence that the messages are seriously
fraudulent or otherwise inappropriate.
Apart from some corner cases (small organizations) neither sending mail
eco-system nor receiving mail eco-system is able to adequately and
reliably determine which messages are handled by a MLM and which are
not. And even if one finds a way to determine this, it certainly will
not be scalable to the entire Internet. With that in mind, the question
is: is option 2 of par 15.4 of the DMARC base spec ('silent discard')
contradicting the above quoted principle as stated in RFC5321, or not?
I certainly won't argue for them.
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.
Too much of this and they'll find their bounces get them blacklisted.
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.
No. Here I'm still talking about ADSP. It's similar to, but not identical to
DMARC.
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 think the potential for harm is identical. If it's concerning for ADSP, it
should be concerning for DMARC. DMARC does have a few more knobs to turn, but
if you don't want mail that fails authentication sent to the receiving user,
you have to use p=reject and that has the exact same problem with mailing list
subscriptions that ADSP does.
Correct.
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.
Ah, so DMARC is only for domains without real users?
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.
Workable for who? Probably for large providers that can do it via data
mining. I don't even know all the mailing lists I'm subscribed to let alone
everyone who uses my domains.
+1.
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".
DKIM came out in 2007. I'm subscribed to dozens of mailing lists and I can
think of two that don't break DKIM signatures (and not even this one). I
think the idea that mailing lists are going to do anything more for DKIM than
add their own signatures is wishful thinking, certainly not supported by my
experience.
I don't have a good solution either, but I'm also not convinced with what
looks to me like a lot of handwaving. We KNOW it was a problem with ADSP and
while I really like things about DMARC like the feedback mechanisms, I don't
think it's meaningfully different from ADSP in this regard and it will somehow
have to be addressed.
As ADSP has been adopted by the IETF as standards track document, the
question is: are there any new insights/ regarding this problem in
relation to DMARC? If not, it makes little sense redoing the entire
MLM/ADSP discussion for MLM/DMARC?
Don't get me wrong: in my opinion new standards have to interoperate
with the current Internet, so the existence of MLM's and the way most of
them operate at this moment, can't be ignored. Using special domains for
'DMARC signed mail' to prevent damage may be a good advise, but
companies may want to 'protect' their main (and most well-known)
domains, with which they also send transactional and IPM as well.
Then the next question is: is it worth standardizing DMARC within the
IETF? Obviously it already is a _de facto_ standard, why should we aim
at making it a _de jure_ standard as well?
I for myself have not yet found the answer to this question.
/rolf
[1]
http://www.macworld.com/article/2029570/silent-email-filtering-makes-icloud-an-unreliable-option.html
[2] http://www.webhostingtalk.com/showthread.php?t=1227028
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
