RE: Enabling DMARC workaround code for all IETF/IRTF mailing lists

["MH Michael Hammer (5304)" <[e-mail]>]

John, I have to disagree with your comment in the appendix about a decline in bounce messages and changes/implementations such as DMARC. Joe Jobs and other abuse have been around a long time. Given a choice between constraining (some functionality) to mitigate/minimize damage and enabling large scale breakdowns of functionality due to abuse, I'll choose the former.  I guess it's a case of picking your poison. Adjust, don't conform.

Mike

P.S. At the end of this month I am leaving American Greetings and will no longer be participating using this account. I already use my [e-mail] account for some working groups and will switch participation on the ietf list to that account.

> -----Original Message-----
> From: ietf [mailto:[e-mail]] On Behalf Of John C Klensin
> Sent: Friday, May 11, 2018 11:03 AM
> To: Alexey Melnikov; [e-mail]
> Subject: Re: Enabling DMARC workaround code for all IETF/IRTF mailing lists
> 
> Alexey,
> 
> This may be the best that can be done given the degree to which DMARC is
> an attack on the mail system (those who don't understand that assertion
> should see the appendix below) but I think we should all be concerned about
> the trend it seems to represent.  Again, that is not a suggestion that we not
> do this (and wouldn't be one even if the decision had not yet been made),
> just a plea that we be very aware of, and document, the tradeoffs that are
> being made.
> 
> That said, I'm uncomfortable with using "=40" as a convention in the middle
> of an address.  First, there is nothing that supports the idea of encoded
> octets in the middle of local parts and, as you know, there is ample
> precedent for interpreting an equal sign in a local part as an indication of a
> name-value setup.  We haven't seen SMTPUTF8 addresses on the IETF list
> yet, but I think there is a strong case to be made that, if we are going to start
> encoding things, we should be encoding Unicode code points (e.g.,
>   "alexey\u'0040'[e-mail]" or
>   "alexey?utf8"?40?[e-mail]"
> ) rather than inventing yet another new system.   I don't think
> that is a good idea, in part because I encountered an example in the last 24
> hours that tries to use encoded words to deal with a non-ASCII local part
> (something the EAI WG considered and rejected and that, if performed in
> transit, is non-conformant with the SMTPUTF8 specs).  Any encoding trick like
> the above (or like just using "=40") is going to encourage that sort of
> "innovation".
> 
> With the understanding that I'm holding my nose while saying this (because I
> have been happy to see the convention fade from use), we already have a
> widely-supported and recognized convention for this type of encoding and I
> wonder why those who have been involved with this effort rejected it.  That
> would be to use
>   [e-mail]
> 
> just a thought.
> best,
>     john
> 
> 
> 
>     -------
> Appendix:
> 
> I've said this before but, to the degree to which the spam and other attacks
> which DMARC is intended to mitigate force us to change the mail system in
> ways that make it less functional, we are essentially admitting that the bad
> guys have won.  This is certainly not the only case and may not be the most
> important one.  For example, the mail system was designed on the
> assumption that delivery would be reasonably reliable, that non-delivery
> would be indicated by NDNs ("bounce messages"), and therefore that
> delivery or read acknowledgments would typically be unnecessary
> (important because they pose privacy problems).
> However, because of concern about blowback attacks, fewer and fewer sites
> are generating bounce messages, at least to unauthenticated senders.
> 
> Rules against tampering with or even inspecting message content in transit
> have also eroded due to the need to do malware
> filtering.   That is probably also the least-bad solution
> possible but takes us down a path similar to the switch from HTTP to HTTPS-
> based web connections: enterprises with concerns about attacks hidden
> behind the encryption have huge incentives, even a sense of necessity, to
> fake termination points and keys
> to allow content inspection at firewalls or the equivalent.
> 
> In each case, the bad guys may get frustrated in their immediate goals but
> the long-term effect is a narrowing of the functionality and reliability of the
> Internet.
> 
> 
> --On Friday, May 11, 2018 13:00 +0100 Alexey Melnikov
> <[e-mail]> wrote:
> 
> > Hi,
> > Many of you have seen several long discussions thread about DMARC and
> > how it affects use of IETF/IRTF mailing lists.
> >
> > After testing DMARC workaround code written by Henrik Levkowetz on
> > several high volume IETF and IRTF mailing lists (e.g. CFRG, WebRTC,
> > DMARC, QUIC), the tools team and the IESG decided that Henrik's code
> > should be deployed for all IETF and IRTF mailing lists. In particular
> > the workaround allows people from DMARC p=reject domains to
> > participate in IETF mailing lists, as well as to avoid the problem of
> > recipients being unsubscribed from mailing lists. These 2 issues were
> > the main reasons for developing the DMARC workaround code..
> >
> > The workaround will be deployed today, May 11th.
> >
> >
> > Below are some technical details on how the email address rewriting
> > workaround is going to work:
> >
> > Emails from domains that don't have a p=reject DMARC setting are not
> > going to be affected in any way.
> >
> > For emails from p=reject domains:
> >
> > - The From header field of such emails will be rewritten to be under
> > @dmarc.ietf.org domain (which will have a p=none policy). For example,
> > "[e-mail]" email address would become
> > "alexey=[e-mail]". The original From header field
> > will be preserved in the X-Original-From header field, which can be
> > used for automatic message processing by Sieve and Mail User Agents.
> >
> > Note that the mapping is reversible, so it is possible to send replies
> > or new messages to an original sender by sending them to the
> > corresponding mapped @dmarc.ietf.org email address.
> 
> 
>