For multiple decades, starting with mail systems predating RFC822, with everyone one of them there was a common mail engineering taboo, "thou shall not tamper with mail" and one of the primary anchoring fields, the author of the message was a principle field you didn't screw around with. You either get it or you don't. Mostly those at the application level didn't and it's understandable. But at the system level, it will cause problems. Even if there was a legitimate transformation, it needs to be reversible and the security remained intact. In this rewrite, it is neither. It was done prematurely without even trying to fix DMARC first and this irresponsible rewrite action will cause problems for everyone. The door was cracks opened and even if there is a new solution to address it, you can't put this one away. The bad guys now know how to get around DMARC security. This is not good mail engineering. I make no apology for having strong moral ethical feelings about it.
-- Hector Santos http://www.santronics.com > On Sep 9, 2014, at 11:44 PM, "Stephen J. Turnbull" <step...@xemacs.org> wrote: > > Derek Diget writes: > >> How are such modifications RFC5321 compliant? See section 3.9. >> >> ...the message header section (RFC5322 [4]) MUST be left unchanged; in >> particular, the "From" field of the header section is unaffected. > > RFC 5321 is irrelevant in the case of mailing list management software > (MLM) like GNU Mailman, because the changes don't happen in the MTA. > Mail is received, processed outside of the purview of RFC 5321 > (including the usual alterations made by the MLM), and then reinjected > into the mail transport system. Note the last paragraph from 3.9.2: > > There exist mailing lists that perform additional, sometimes > extensive, modifications to a message and its envelope. Such > mailing lists need to be viewed as full MUAs, which accept a > delivery and post a new message. > > where "new message" clearly should *not* be construed to necessarily > mean "new" in the sense of changing RFC5322.Message-Id. It means > wrapping some version of the message in a fresh "envelope". > > OTOH, RFC 5322 specifies the content of the From field to be the > address(es) of the author(s), and that it is an originator field. I > don't have a channel to the original intent of the RFC authors, but I > personally interpret "originator field" to mean that From-munging is > violation of that RFC, as per policy of most mailing lists (in the > sense of "GNU Mailman", not RFC 5321. Like John Levine, I don't like > From-munging, and consider it a serious imposition. > >> I thought a different RFC gives more detail, but see section 3.9.1 and >> 3.9.2 of RFC 5321. > > I interpreted John Kelley to be describing difficulties users report. > >> IMO both "lists" and "groups" are a sub-set of "exploders". The >> way I (and the MTA we run) differentiate the two is that "lists" >> change the RFC5321.MailFrom address for bounce handling (see >> RFC5321 section 3.9.2) while "groups" ("alias" in RFC5321 section >> 3.9.1) don't. > > That's a useful distinction, although we should probably be careful > about terminology here. I don't think RFC 5321 terminology is a good > default, since the applications that are hurting are generally not > bound at all by RFC 5321, being MUAs in the sense of that RFC, as > described by the paragraph I quoted above. > > But it's fine to deliberately borrow from RFC 5321. For the > distinction Derek describes above, I like the term "mailing list > manager" (MLM) for exploders that set RFC5321.MailFrom to themselves > and "alias" for exploders that don't. I think that even if the WG > members all agree on "group" for the latter, some of the people whose > use cases we'll discuss are going to be using "group" for something > else. I'd rather not have to deal with that. I can live with "list" > instead of "MLM", though. > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
