Hi John,
At 12:29 17-12-2016, John C Klensin wrote:
Maybe this is what you meant by the scare quotes, but the IETF
has been fairly clear -- in RFC 5321 and 5322 and elsewhere--
that
RFC 7960 states that: "To alleviate unsubscribes to the Mailing List
due to the messages bouncing because of DMARC, the MLM needs to not
act on notification messages due to message authentication
issues". That would entail interpreting the Enhanced Status Codes,
specifically the ones related to message authentication failures and
ignoring them for unsubscription purposes.
(1) Mailing lists can be handled at MTA level, in which case the
backward-pointing envelope address is changed to point to the
list but that, other than adding trace information (including
List identification), the headers and message body should be
unchanged.
Yes. It is the message body change which indirectly causes the
rejection for mail from those "p=reject" domains.
(2) Mailing lists can also be handled at MUA level, in which
case "Resent-" fields are added, possibly also with List
information, but the header "From:" and "Sender:" fields are to
be unchanged.
Yes.
(3) Because we deliberately do not have standards about what an
MUA can do -- precisely because it is ultimately an agent acting
on behalf of the end user -- such a system can plausibly
construe such a message as being received, modified as desired,
and then forwarded to a list of others. Again, there is no
standard, but treating mailing list traffic that way opens up a
whole series of potential attacks because, if the "MUA can make
changes" model is applied, nothing prevents such an MUA from,
e.g., changing every instance of "black" in the message body to
"white".
The problem is that we are getting into what a MUA does, e.g.
auto-completion. We would also not be following RFC 5322 by making a
change to the "From:" field [1]. In a way, this validates the
argument that a whole series of potential attacks is being opened.
(4) We have never encouraged anything that attributes semantics
to either a name phrase (<display-name> in RFC 5322-speak).
While we have never taken a position about auto-complete and
populating address books based on those fields, doing the latter
is fraught with risks, particularly if all I need to do to
divert mail from Ted to you to an attacker is to send him a
message with a "From:" header field of
S Moonesamy <evil-SM(_at_)example(_dot_)com>
Yes. We might end up having to consider whether to attribute
semantics to the <display-name> as a way to solve the problem. Let's
assume that 20% of IETF mailing list subscribers use a "p=reject"
domain name in the "From:" field and that they are no longer allowed
to post messages to the mailing list because of the policy advertised
by that sending domain. What should the mailing list moderator do in
response to complaints from those subscribers?
Regards,
S. Moonesamy
1. This is related to Point 2.