Grant Taylor via Mailman-Users writes: > On 07/24/2018 03:16 PM, John Levine wrote: > > Turning it on for aol.com, yahoo.com, and other domains with user > > mailboxes, > > So, are you stating that DMARC should NOT be used on domains that > (predominantly) contain end user mailboxes?
Let's be careful to distinguish between "DMARC" and the "p=reject" and "p=quarantine" policies. (1) DMARC's reporting features *can* and *should* be used on all domains that send email, with very few exceptions. (2) "p=reject" should never be used on domains that contain any non-transactional mailboxes (ie, mailboxes used as the From which might be reinjected into the mail system with changes). This recommendation was actually in some early unofficial drafts or author discussions of RFC 7489, but doesn't appear to be in the Internet-Draft prepublication series, and it's definitely not in the published RFC. (I believe that keeping such verbiage out of the RFC is why the RFC is informational rather than normative.) > "legitimate mail that DMARC cannot describe" That sounds distinctly > like a problem with the DMARC specification, /not/ with use there of. Hey, did you really want to write that? There's about a millennium of mail-RFC-writing and/or large site admin experience on the DMARC-WG. So, there's fundamental misunderstanding here somewhere. DMARC depends on DKIM and SPF. Neither can ensure that the *purported author domain* of an email can be authenticated when passed through a mailing list. *The whole purpose of DMARC From alignment is to authenticate the author domain in the context of her message!* This is simply impossible, unless the signed portions of the message arrive at the destination *unchanged*, or the list is an authorized mail source of the author domain for SPF. Much legitimate email *does* change them, however, and few lists cater exclusively to subscribers of the same administrative domain. (Of course getting list host IPs authorized as mail sources for all potential SPF-using posters would be a nightmare!) You propose that mailing list should munge From (and in fact you've proposed that it should do so independent of DMARC, IIRC). AFAICS, this has three nasty effects (at least). (1) It ensures that validation of From alignment of the actual author will *fail*, because the From header *must* be signed in DMARC. (SPF is pretty useless in the context of mailing lists.) (2) It breaks all the quoting mechanisms in every existing MUA, which now instead of, e.g., >>>>> Grant Taylor writes: will insert >>>>> Grant Taylor <gtay...@tnetconsulting.net> via Mailman-Users writes: Some styles would look a little better, some worse. All, gag me. This is imposing work on a lot of MUA authors, and it will be ongoing as mailing lists keep changing their munging styles. (3) Users may start to accept From: "Grant Taylor <gtay...@tnetconsulting.net> via All-Passwords-Yours-Now-Ours ML" <v...@kremlin.ru> (or whatever their MUA displays) as indicating authentic email from you, because a lot of authentic mail indeed looks like that in your scheme. (This is a controversial point: a lot of security pundits believe that most users will click on anything anyway.) > I feel like DMARC requires a paradigm shift in how email is forwarded > and handled by mailing lists. Three points for your consideration here: (1) There's a fundamental problem, though: the *only* paradigm shift compatible with DMARC's goal of authenticating the author's domain is to *pass the message through with all signed portions unchanged.* (SPF doesn't have this problem: SPF can't authenticate author domains of mailing list posts *at all*, unless the list is hosted by the author's domain or its host's IP is listed as a valid mail source by the author's domain!) (2) DMARC is a *private protocol*. RFC 7489 is *Informational*, it has *no normative implications* for the rest of us. We would be perfectly conformant to all normative RFCs if we decided that mail from sites that have a p=reject policy is undeliverable and dangerous, and rejected it. We're not going to do that, nor even offer it as an option, but I'll leave that here for consideration. (3) ARC, if the mailing list is accepted as trustworthy by recipients, requires *no* change to mailing list behavior (aside from participation in the ARC protocol, of course). If not trusted, we're back in the world of (1) and (2). > I suspect "imposed on innocent bystanders" and "not their problem" can > also be used to describe requiring reverse DNS, SPF, and DKIM. No, it can't, not in the same way. (1) All of the above can be implemented in the MTA without any change in end user or Mediator behavior. These upgrades were frequently transparent to admins of virtual domains (except that their mail started working to sites it used to fail at). Not so, DMARC. Most mailing lists munge Subject, or add footers, or both. Either those modifications have to be abandoned, or the address in From must also be munged. Most of us find those alternatives extremely distasteful. (2) All of those requirements may result in denial of service to posters, but not to subscribers. Turning on "p=reject" did DoS unrelated subscribers whose providers participate in DMARC. Steve ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org