On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels < mjass...@encs.concordia.ca> wrote:
> On Sun, 26 Apr 2015 12:21:04 +0200, > "J. Gomez" <jgo...@seryrich.com> 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. 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. 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. 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. 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. 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? 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. The sad legacy is that different mail operators have historically done different things, which has led to MUAs doing different things, which has in turn led to a global system that interoperates enough to be useful but not enough to be able to lock down certain undesirable things without a great deal of pain. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
