Grant Taylor via Mailman-Users writes: > I would think / hope / expect that such services would be from a > different (sub)domain of the client that they are sending email on > behalf of.
That's not how "on behalf of" worked in practice. What happened in April 2014, was that a home business owner (HBO) would send a pile of completed order notices to intuit.com, and intuit.com would send an invoice to each customer on behalf of h...@yahoo.com, from h...@yahoo.com. HBO, of course, doesn't have a vanity domain, just a Wordpress or SquareSite (or even Facebook) home page. Tens of thousands of invoices worth millions of dollars bounced off of personal accounts and tiny business owner accounts at Yahoo! and other receivers who take p=reject as a command. Note that if I were intuit.com's CISO, I would fight tooth and nail against the system you suggest, because it implies that I have DKIM private keys for all those subdomains owned by clients. Every spammer in the world would be trying to hack the server that has those keys. I could probably keep them out, but Lordy, the liability involved! Less financially painful are the services that newspapers and tourist destinations provided (note past tense, they're mostly dead now) where you could sit at a terminal and send a "postcard" recommending an article or with a picture of the attraction to family and friends "from" yourself, including your email address, simply by typing name and address in. Not a huge loss, I guess, but .... > > The other *possible* use case for ARC would be non-mailing list > > forwarding. But these almost never break the DKIM signature of the > > originator. > > They may not break DKIM. But depending on how they operate, they may > break SPF directly (re-sending with the original SMTP envelope From: > thus violating SPF) -or- indirectly (re-sending with something like SRS) I've never seen SRS in the wild, except in the headers of some of the crazier denizens of IETF mailing lists. YMMV, of course. > thus breaking DMARC alignment. Simple .forwarding breaks SPF of the author domain, period, unless entirely within one administrative domain, and that domain is well-configured so that all the forwarding is internal, and the SPF checks are all done at the boundary. I guess in the case where forwarding takes place entirely within an administrative domain, DMARC From alignment could be broken without breaking SPF itself because From alignment is validated on a different host from SPF, but that sounds like a case of "evolution in action". > My understanding is that DMARC can be configured to require both SPF and > DKIM alignment. That's non-conforming to RFC 7489. Section 4.2: A message satisfies the DMARC checks if AT LEAST ONE of the supported authentication mechanisms: 1. produces a "pass" result, and 2. produces that result based on an identifier that is in alignment, as defined in Section 3. [Emphasis mine.] > The point being that simple .forward(ing) may still break things. > > I maintain that detecting such is one of the functional purposes of > DMARC. Of course. That's why it's not "DMAC" (although either would be a great street name for a hip-hop DJ!) > I question the wisdom of making processing of ARC conditional on RFC > 2369 List-* headers. I mainly say this because there is nothing that > prevents malicious actors from inserting (possibly bogus) List-* > headers. (Or lots of tiny lists of single recipients.) I'm afraid I failed to make the concept explicit again. Remember, authenticating mail origin doesn't prevent anyone from sending malicious mail, or even from having it delivered. So while I suggest that ARC processing results be taken seriously in the presence of (List-* headers) for DMARC alignment purposes, delivery is also conditional on (not malicious). If a site wants to be conservative and assume some degree of malice until it's seen "enough" benign traffic, that's consistent with what I intended. Also, sites like GMail and Yahoo! might very well be willing to specially handle From addresses at sites known to have leaked a billion address books. Similarly, they could "throttle" on floods of ARC email via purported mailing lists that have never been seen before. I acknowledge that sites managed by single admins would likely be unwilling, and perhaps even unable, to come up with such systems. N.B. By "intended," I mean to admit that my wording in the previous post strongly suggested that they would start with the assumption that mail is benign until proven otherwise. I can't fault you for taking my words literally. :-) 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