On Mon, 27 Apr 2015 11:44:38 PDT, "Murray S. Kucherawy" <[email protected]> wrote:
> On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels < > [email protected]> wrote: > > > On Sun, 26 Apr 2015 12:21:04 +0200, > > "J. Gomez" <[email protected]> wrote: > > > > > On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote: > > > > > > > The From header field is not in the public domain, and not available > > > > for appropriation. "Taking ownership" of something that isn't yours is > > > > properly called "theft" > > > > > > Is the message Subject in the public domain? Is the message Body in the > > > public domain? Why are many mailing lists taking liberties with them? > > > Sorry, but I think your analogy of email vs property does not compute. > > > > Whether any header field is in the public domain is a legal question on > > which I won't venture an opinion, but the From header stands out as one > > that is treated specially by RFC5332, section 3.6.2: > > > > [...] The "From:" field specifies the author(s) of the message, > > that is, the mailbox(es) of the person(s) or system(s) responsible > > for the writing of the message. The "Sender:" field specifies the > > mailbox of the agent responsible for the actual transmission of the > > message. For example, if a secretary were to send a message for > > another person, the mailbox of the secretary would appear in the > > "Sender:" field and the mailbox of the actual author would appear in > > the "From:" field. If the originator of the message can be indicated > > by a single mailbox and the author and transmitter are identical, the > > "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD > > appear. > > > > [...] > > > > In all cases, the "From:" field SHOULD NOT contain any mailbox that > > does not belong to the author(s) of the message. [...] > > > > It seems clear to me that, at the very least, the mailbox of the message's > > author ought not to be and replaced by the mailbox of an automaton that > > added a subject tag and a list trailer. If the mailing list software has > > made DKIM-breaking changes, it may make sense for it to *add* its own > > mailbox to the From header (as a "coauthor"), and make itself the > > Sender. > > > > The question to me is whether the message that the MLM software emits is > the same as the original message. If it is, then the Author ought to be > preserved across the MLM. If it is not, then the MLM emits a new message, > and it actually SHOULD NOT keep the Author the same, as described above. > So we get to argue about "same", and of course the specs aren't > particularly rigorous about this. In the context I was considering -- one in which the message had been reversibly transformed as indicated in draft-kucherawy-dkim-transform-00 and reversibly transformed by adding tags "ftf=" (From TransFormed) and "stf=" (Subject TransFormed) -- the initial Author's message is entirely contained in the "new" message, and it's easily reconstructed from the "new" message. A downstream Receiver can reconstruct the original message such that the reconstructed message passes the original DKIM test and aligns as required by DMARC. By hypothesis, since the transformed message has changed enough to invalidate the original DKIM signature, the MLM has also signed the transformed message (with its mailbox appended to the 5322.From header.) Given that the message has been transformed, the question arises whether it's "the same" as the original or not. Obviously it's not strictly identical, but equally obviously (at least in the case of normal mailing list decorations) it's not significantly different; it lies somewhere in the continuum between strictly identical and significantly different. According to RFC 5322, section 3.6.4: [...] In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message. I can't see a reading of that sentence that would require a new Message-ID on a single message as transformed automatically by an ordinary mailing list. > RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that it > doesn't change From, from which I infer it doesn't change Author, although > it does say it's a "new" message that's emitted. That document is not a > proposed standard and merely documents current use (as I understand it), so > it's merely recording the fact that MLMs technically violate the SHOULD NOT. Right, although that had already been a long-standing and widely accepted practice long before RFC5598 was published in July 2009. Adherence to the normative RFC5322 counts for more, I'd say. > So it seems to me the points of contention here are: > > 1) Is the MLM violation of the SHOULD NOT cited above the kind of violation > that we accept based on how "SHOULD NOT" is defined in RFC2119? It seems > to me that it is, especially given how long they've been doing it without > objection (until now). One could argue they've been "getting away with it" > for too long, but we can't change history. Yup. > 2) Is the MLM emitting a new message? I would agree with Michael and > contend that it is if there have been any content changes at all, in the > same way that someone making a compilation of a series of independent works > (a "mix tape") owns the copyright on the mix, though not on the original > material. Now, MLMs do that with digests already -- who else could one > legitimately put in the From of a digest? -- but typically not for resent > messages. My view is that it's a "new" message in the sense that it breaks a DKIM signature, but not RFC5322's sense of changing the meaning of the original author's message, so the Message-ID should stay the same. Of course, this is assuming normal mailing list handling. Ne'er-do-wells might take advantage by making the standard reversible transformations but adding large chunks of spam. In such a case, it would at least be clear that the original author's domain was only responsible for the original message, and the ne'er-do-wells' domain for the rest. Normal spam/phishing filtering can still be deployed, and who knows; maybe MUAs might even help out by marking the differences for the human recipients. > To the point of Message-IDs, I would say that should follow the same rule > as the From change: If the content changes, it's a new message, and it gets > a new Message-ID. I think that's too strong, but I wouldn't go to the wall defending that position. > Might it be sufficient to declare an "Original-Message-ID" or > "Author-Message-ID" or "List-Original-Message-ID" field that contains the > author-generated Message-ID, allowing for the duplicate suppression that's > done now? That could work, too. > If MUAs do unpredictable things with multimailbox From headers, it > > may be because they don't see them often enough. I'm sure they'll fix > > their errors if list mail begins to arrive with heretofore unusual but > > RFC5322-compliant headers. > > I would far rather have MUA developers work with us directly, but the IETF > has a persistent allergy to us tampering in user space. As I understand > it, our desire in general tends to be to create well-defined interfaces > (not APIs, mind you) at which MUAs can "meet" us on their own, and let them > take it from there. Thus, the best we can do is be very clear about what > information is presented by a multi-From message and perhaps why, and hope > they'll adapt. Agreed. I really wouldn't even contemplate dictating standards for MUAs. MJA _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
