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.
MUAs may have widely varying methods of dealing with multiple mailbox From
headers, but in my experience, MTAs have no trouble with them, and they're
generally the ones handling DMARC issues. RFC7489 has this to say (in
Section 6.6.1) about multiple-mailbox From headers:
o Messages bearing a single RFC5322.From field containing multiple
addresses (and, thus, multiple domain names to be evaluated) are
typically rejected because the sorts of mail normally protected by
DMARC do not use this format;
[...]
The case of a syntactically valid multi-valued RFC5322.From field
presents a particular challenge. The process in this case is to
apply the DMARC check using each of those domains found in the
RFC5322.From field as the Author Domain and apply the most strict
policy selected among the checks that fail.
The first paragraph seems to imply that DMARC admits the validity of
a multimailbox From field, but simply doesn't plan to support it. The
second paragraph makes clear how the nonsupport is to be accomplished.
I understand that a ne'er-do-well might craft a spammy message with
From: "Need enhancement? See http://bad-example.com";
<[email protected]>, <[email protected]>
Sender: <[email protected]>
DKIM-Signature: [...]i=bad-example.com[...]
DKIM-Signature: [...]i=example.org[...]
among the headers; hence the second quoted paragraph of RFC7489 above.
However, given an opportunity by DKIM, e.g., implementing Murray's
draft-kucherawy-dkim-transform-00, with some extra detail to accommodate
reversible From and Subject transformations, a mailing list could
fairly easily get away with something like
From: <[email protected]>, <[email protected]>
Sender: <[email protected]>
Subject: [list] Original subject
DKIM-Signature: [...]i=example.com; ftf=2; stf=[list]; [...]
DKIM-Signature: [...]i=example.org[...]
where "ftf=2" means "the second mailbox in the From header was added", and
"stf=[list]" means "the tag '[list]' in the Subject header was added. Both
transformations are easily reversed.
MTAs implementing draft-kucherawy-dkim-transform-00 supplemented with ftf
and stf transformations should be able to reconstruct the original message
and verify its DKIM-Signature. This adds plenty of work for Mediators --
possibly more than they can handle if the MLM has no direct access to DKIM
-- and only a little extra for Receivers.
RFC 7489's paragraph dealing with multimailbox From headers would have to
be change to something like
The case of a syntactically valid multi-valued RFC5322.From field
presents a particular challenge. The process in this case is to
apply the DMARC check using each of those domains found in the
RFC5322.From field as the Author Domain and apply the most strict
policy selected among the checks that fail. However, if one
DKIM-Signature fails on its own but passes under the reversal
of transformations specified by another passing DKIM-Signature,
then the first DKIM-Signature is deemed to have passed.
> I think that point was settled as "it is debatable". That field contains
> the Author, and if the Author signed with DKIM and the mediated message
> breaks that signature, it can then be argued that Authorship has suffered
> and therefore that the From: Header should reflect that fact.
The Authorship certainly hasn't suffered to the extent that the content has
been significantly changed. At worst, the Authorship has been augmented by
the addition of content by another Author, which, I think, merits the
addition of a mailbox to the From header, not the replacement of the
principle Author with a minor contributor, which would be tantamount to
replacing a book's author with its publisher, who added the binding and
the copyright notice.
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.
MJA (regretting that this turned out to be so long)
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
