Re: DMARC methods in mailman --- [LEDE-DEV] DMARC related mass bounces / disabled subscriptions (fwd) Jo-Philipp Wich: [LEDE-DEV] DMARC related mass bounces / disabled subscriptions

[S Moonesamy <[e-mail]>]

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 <[e-mail]>

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.