"Rolf E. Sonneveld" <[email protected]> wrote: >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
I think DMARC is widely enough used that it's worth documenting. Along with that, I think it is critical to give operators guidance about the risks associated with p=reject for different domain usage patterns. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
