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

[John C Klensin <[e-mail]>]

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.