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

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 May 2018 13:00:15 +0100

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, "[email-masked]" email address would become "alexey=[email-masked]". 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.

Best Regards,
Alexey

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 11 May 2018 10:12:20 -0400

Alexey,

Many thanks to you, Henrik, and the team!

Cheers,
Andy

On Fri, May 11, 2018 at 8:00 AM, Alexey Melnikov <[email-masked]>
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 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, "
> [email-masked]" email address would become "alexey=
> [email-masked]". 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.
>
> Best Regards,
> Alexey
>
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 May 2018 11:02:31 -0400

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\[email-masked]" or
  "alexey?utf8"?40?[email-masked]"
) 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 
  [email-masked]

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
<[email-masked]> 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 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, "[email-masked]" email address would
> become "alexey=[email-masked]". 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.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 11 May 2018 15:13:20 +0000

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 [email-masked] account for some working groups and will switch participation on the ietf list to that account.

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: Friday, May 11, 2018 11:03 AM
> To: Alexey Melnikov; [email-masked]
> 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.,
> 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
> 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
> 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
> 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.
> 
> 
> > 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 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,
> > "[email-masked]" email address would become
> > "alexey=[email-masked]". 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.
> 
> 
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 May 2018 12:59:13 -0400

--On Friday, May 11, 2018 15:13 +0000 "MH Michael Hammer (5304)"
<[email-masked]> wrote:

> 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,

I tried to say at least twice in that note that, while this
decision saddens me, I am not going to argue that it is the
wrong one to make.  Maybe I'm just suffering for nostalgia for
happier and less hostile times.   However --and with the hope
that this doesn't set off a series of rants in the "final
ultimate solution" category-- I do wonder how far we should be
pushing the assumptions that underlie the design of our email
protocols without reviewing and rethinking those designs.

Or, given the number of reports that almost all people younger
than us are not using email but prefer interactive conversations
of a few hundred characters per turnaround and observations of
people responding to attempts to discuss complex issues with
"TL;DR", perhaps even worrying about email or other
communications in units of paragraphs is nostalgia for a fading
technology and/or culture.

    john

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 May 2018 20:17:09 +0300

Hi John,

> On 11 May 2018, at 18:02, John C Klensin <[email-masked]> wrote:
> 
> sign in a local part as an indication of a name-value setup.

As far as the DMARC workaround for IETF mailing lists is concerned, the encoding is an implementation detail and might change in the future. Use of = is in fact configurable.
The only requirement on encoding is that it should somehow be reversible.

I published specific details because IETF is a technical community and people want to know details about IETF infrastructure.

>  We

Deploying EAI for IETF mailing lists would be a big undertaking in itself. We can cross this bridge when we need to cross it.
>  [email-masked]

The short answer is that Henrik tries to use % and found that various software (including some non IETF mailing lists, if I remember correctly) was buggy and assigned some special meaning to % that made it unsuitable for our purposes.

Best Regards,
Alexey

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 May 2018 13:18:17 -0400

TL;DR is really just the elevator pitch for why you should read the whole message.   It's a conversational grace.   I think the reason Kids These Days don't use email is as you say, that the design is wrong for an internet in which we can't trust other participants to be considerate.   A properly designed email system would almost certainly get substantial uptake from the younger generation, but what we have at present competes poorly with federated social solutions.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 11 May 2018 14:03:07 -0400

This is getting a bit off-topic, but that said, my son is at the upper
range of what we might think of as “Kids These Days”, and is a college
professor, so he interacts with the actual Kids on a daily basis. He’s
reported to me in conversation that at least anecdotally in his experience,
the death of email is being greatly exaggerated.

Cheers,
Andy

On Fri, May 11, 2018 at 1:18 PM, Ted Lemon <[email-masked]> wrote:

> TL;DR is really just the elevator pitch for why you should read the whole
> message.   It's a conversational grace.   I think the reason Kids These
> Days don't use email is as you say, that the design is wrong for an
> internet in which we can't trust other participants to be considerate.   A
> properly designed email system would almost certainly get substantial
> uptake from the younger generation, but what we have at present competes
> poorly with federated social solutions.
>
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 May 2018 14:04:57 -0400

--On Friday, May 11, 2018 20:17 +0300 Alexey Melnikov
<[email-masked]> wrote:

> Deploying EAI for IETF mailing lists would be a big
> undertaking in itself. We can cross this bridge when we need
> to cross it.

My only concern is that, unless the IETF is going to consider
making SMTPUTF8 "not recommended", we do nothing that would
either make deploying it harder or encourage non-conforming
hacks that would have the same effect.  Neither of those require
deploying it or deciding it would be a good idea for IETF
mailing lists (personally, I think it would not be), only that
we think about the possibility.  From that perspective, "cross
that bridge when we come to it" sounds a bit like "put heads in
sand".

>> 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 
> The short answer is that Henrik tries to use % and found that
> various software (including some non IETF mailing lists, if I
> remember correctly) was buggy and assigned some special
> meaning to % that made it unsuitable for our purposes.

Very good.  If the possibility was considered and caused its own
set of problems, then I'm happy avoiding it.   I believe it
would be helpful to document what issues have been found in some
way, if only because that information would be helpful if we
ever try to advance 5321/5322 on the standards track.

thanks and best regards,
    john

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 11 May 2018 13:13:41 -0500

Hi, Alexey,

On Fri, May 11, 2018 at 12:17 PM, Alexey Melnikov <[email-masked]>
wrote:

> As far as the DMARC workaround for IETF mailing lists is concerned, the
> encoding is an implementation detail and might change in the future. Use of
> = is in fact configurable.

Perhaps I've spent too much time talking to  QUIC WG participants about
header invariants, but can you actually change the encoding, or did you
mean just adding a new encoding, so that if someone tries to respond to an
earlier e-mail from someone with a re-written =40 address, that would still
work?

Spencer

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 May 2018 15:05:59 -0400

--On Friday, May 11, 2018 13:13 -0500 Spencer Dawkins at IETF
<[email-masked]> wrote:

> Perhaps I've spent too much time talking to  QUIC WG
> participants about header invariants, but can you actually
> change the encoding, or did you mean just adding a new
> encoding, so that if someone tries to respond to an earlier
> e-mail from someone with a re-written =40 address, that would
> still work?

Spencer,  because I started the subthread, let me give you a
partial answer.  I think you know this already, but probably
have other things on your mind.   There is basically a firm rule
in SMTP (5321, but going back to 821 and maybe earlier) that
nothing in the mail path between what we now call the submission
server and the final delivery server gets to interpret, much
less tamper with, the internals of the local part of an address.
While we have many examples of systems breaking that rule, the
integrity of the mail systems depends on it in important ways.  

Having a mailing list management system transform an address
between receipt and [re]distribution does not violate that rule
because we treat the message as having been delivered to that
system and then rewritten and hence not altered in that path.
However, had Alexey been writing very precisely, I don't think
he would have used "encoding" but instead talked about this as a
convention or something similar.   Then the question becomes
whether, if the mailing list system changes an address using
that convention, whether the user, MUA, or delivery MTA at the
receiving end recognizes the convention.   

Speaking as a user who sees that convention, it took me around
five seconds to figure out what =40 referred to (and it should
not have taken me that long).  I don't know whether that would
be true of the typical IETF participant; it certainly is not
true of my delivery MTA or my now-ancient MUA.

So, there are really several possible questions:

(1) If your question is whether a recipient of the mailing list
distribution of the address would recognize the convention and
be able to infer the original address, the answer is "anyone's
guess", but most users tend to pay more attention to the
personal name phrase than to the address anyway, so maybe it
isn't important.

(2) If someone receives a message whose envelope MAIL FROM and
header "From:" fields show 
  "alexey=[email-masked]" 
and replies to it offlist without recognizing the convention or
de-converting the address, I assume that dmarc.ietf.org will
recognize its own convention, rewrite the message headers, and
send it off to [email-masked].  If it does not do that
rewrite, then the message (or the copy addressed to him) bounces
or gets lost, which is not necessarily a bad thing.  If it does
do the rewrite, it works even if the convention is changed to 
   "alexey☺[email-masked]"
as long as dmarc.ietf.org keeps track of all of the conventions
it has used.  It does raise a privacy concern that might or
might not be important -- if I pick up Alexey's address (that
one) for use in a private reply, having the message pass through
IETF mail servers leaves traces (and possibly the message in
clear-text form and that might not be desirable.

(3) If the expectation is that a delivery server or receiving
MUA, upon receiving a message from, e.g.,
     "alexey=[email-masked]" 
will recognize the convention, decode it and present
"[email-masked]" to the user, well, don't hold your breath
waiting for it to happen with this convention so worrying about
how disruptive a change in convention might be is hardly worth
the effort.  In addition, if we wanted / expected that
recognition to occur, I'd expect to see an Internet-Draft
proposing some sort of standards action to establish the
convention and encourage all mail systems to recognize it.
Alexey quite noticeably did not propose that.

best,
    john

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 May 2018 15:30:13 -0400

> On May 11, 2018, at 3:05 PM, John C Klensin <[email-masked]> wrote:
> 
> I assume that dmarc.ietf.org will
> send it off to [email-masked].

This rather invites abuse, since now ietf.org becomes an open relay
for all the "DMARC-protected" contributors.  Other lists I'm on
do something that I find more useful:

	From: List Name <[email-masked]>
	Reply-To: Author Name <[email-masked]>, ...

This does not introduce any anomalous reverse routing.

-- 

	Viktor.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 11 May 2018 15:31:15 -0500

Hi, John,

> > e-mail from someone with a re-written =40 address, that would

Thanks for the clues!

> integrity of the mail systems depends on it in important ways.

When I'm not thinking about QUIC invariants, or QUIC spin bits, that sounds
familiar, but it wasn't the first thing I thought about.

> clear-text form and that might not be desirable.

(2) is closest to what I was curious about - whether if we are running =40
as the convention, and decide that =80 would be twice as good (just
kidding, I mean "any other value besides =40"), and implement the new
convention, if something good would happen someone who replies to an e-mail
that was processed using the original convention.

So I was stumbling toward asking if we planned to remember old conventions
if we adopted a new one, and it sounds like if we did remember old
conventions, most of the reply-to-old-convention e-mail would end up in the
right place, most of the time.

Your explanation was helpful. And thanks for clues, as always.

Spencer

---

From: "John Levine" <[email-masked]>
Date: 11 May 2018 17:31:38 -0400

In article <61B1EDB45FC4FF33154B13B0@PSB> you write:
>DMARC is an attack on the mail system ...

Here's two related thoughts.

I agree with everything bad you have to say about DMARC but we're
stuck with it for the time being.  There is s thing called ARC that
large providers say they plan to use to re-enable list mail from
DMARC'ed addresses.  It's pretty far along, Gmail is adding ARC
headers and sometimes looking at them, various mail libraries and list
software are starting to support them, and sometime in the future we
may be able to undo the anti-DMARC kludge.  It's a kludges on kludges,
but that is the nature of e-mail these days.

>  [email-masked]

My experience is the same as Henrik's, percents don't work because
many mail systems (usually correctly) assume it's a botnet looking
for very old misconfigured sendmail open relays.

I did the original rewrite hack on which the IETF's is based, but I
rewrite the domain, so that address would be rewritten as

  [email-masked]

I have a wildcard MX to collect and forward the mail.  Works great.
Dunno why the current IETF scheme doesn't do that (perhaps postfix
doesn't handle wildcarded domains as easily as qmail) but we can keep
it in mind, since it doesn't mess with the local part and it should
work with EAI the same as ASCII mail.

For whoever said it's an open relay, sheesh, we're not totally dim.
My scheme remembers what addresses it's rewritten and only forwards
for those.  Mine also uses really draconian spam filters since in this
context it can safely assume that the only messages worth forwarding
will be from individuals and anything bulky can be discarded.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 May 2018 17:36:22 -0400

--On Friday, May 11, 2018 15:31 -0500 Spencer Dawkins at IETF
<[email-masked]> wrote:

>...
>> and replies to it offlist without recognizing the convention
>> or de-converting the address, I assume that dmarc.ietf.org
>> will recognize its own convention, rewrite the message
>> headers, and send it off to [email-masked].  If it does
>> not do that rewrite, then the message (or the copy addressed
>> to him) bounces or gets lost, which is not necessarily a bad
>> thing.  If it does do the rewrite, it works even if the
>> convention is changed to "alexey☺[email-masked]"
>> as long as dmarc.ietf.org keeps track of all of the
>> conventions it has used.  It does raise a privacy concern
>> that might or might not be important -- if I pick up Alexey's
>> address (that one) for use in a private reply, having the
>> message pass through IETF mail servers leaves traces (and
>> possibly the message in clear-text form and that might not be
>> desirable.
>...

> (2) is closest to what I was curious about - whether if we are
> running =40 as the convention, and decide that =80 would be
> twice as good (just kidding, I mean "any other value besides
> =40"), and implement the new convention, if something good
> would happen someone who replies to an e-mail that was
> processed using the original convention.
 
> So I was stumbling toward asking if we planned to remember old
> conventions if we adopted a new one, and it sounds like if we
> did remember old conventions, most of the
> reply-to-old-convention e-mail would end up in the right
> place, most of the time.
> 

Glad to help.  Incidentally, while my mini-analysis had not
gotten that far, Victor is probably correct.  If mail can
actually be sent to
   "alexey=[email-masked]"
with the expectation of delivery to 
   "[email-masked]"

we would need to either have a very complex filtering or
validation system or we would basically have created an open
relay (btw, another issue with the use of "%").  For that
reason, it might actually be better to either refuse to accept
incoming mail with dmarc.ietf.org as a nominal destination or to
bounce all such mail with a message similar to 

   550 No such mailbox; this was a cheap hack to prevent DMARC
problems with mailing list postings

And just move on.  I'm confident that those who worry about
blowback and similar bad behavior would prefer the former.   If
that were the approach, it really wouldn't make any difference
what conventions were used or how often they were changed as
long as a competent human could manually decode them.

best,
   john

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 May 2018 17:44:37 -0400

> On May 11, 2018, at 5:31 PM, John Levine <[email-masked]> wrote:
> 
> For whoever said it's an open relay,

I'm not ashamed of that post. :-)

> sheesh, we're not totally dim.

Of course.  And yet, I may want to reply to a saved message years
later.  How may years of reverse forwarding is the ietf.org mail
service signing up for?  If Gmail, Yahoo, ... are having trouble
filtering out all the outbound 419 scams they're sending me, should
I expect ietf.org to do better?

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 11 May 2018 17:51:14 -0400

In article <[email-masked]> you write:
>service signing up for?

Probably not many.  It's a kludge, remember.

I can also report that if you don't need to allow bulk mail when you
forward, it's a lot easier to do reliable filtering.  You can, for example,
enforce DMARC policies with a near-zero error rate.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 May 2018 18:04:56 -0400

> On May 11, 2018, at 5:51 PM, John Levine <[email-masked]> wrote:
> 
> It's a kludge, remember.

Yes.  The kludge I would prefer is prepending the unmolested author
address to the Reply-To: header.  Many lists do this.  It is ugly,
but does not alter or break the reverse path, and IMHO less ugly
than address munging.

-- 
	Viktor.

---

From: Hector Santos <[email-masked]>
Date: Sat, 12 May 2018 20:18:18 -0400

Two comments:

1) While I don't particular like changing of the From field (it will 
promote, invites fakes actors, more overhead), this specific mapping 
can work,  IFF, the failure of such proper mapping (as you described) 
is an rejectable (negatively handled) event.

For example, if the rewrite does not have from "@dmarc.ietf.org" 
domain, is the message then rejectable, classified as a negative, when 
the X-Original-From-Header domain has a p=reject policy?   If the 
Mapping exist, can we technically assume the there is p=reject involved?

   If Policy(RFC5322.X-Original-From.Domain) == REJECT
      and
      RFC5322.From.Domain != "dmarc.ietf.org" then
   begin
      return failed message
   end

What if the "X-Original-From" header does not exist but the From has 
the "@dmarc.ietf.org" domain?

2) Suggestion: Restrictive DMARC Domains that accept this new IETF 
practice SHOULD add a DMARC policy tag such as:

    rewrite=allowed

The whole point of DKIM and its policy layers is to honor it.  By 
encouraging rewrites, there is no point in receivers checking it if 
there is no "payoff" in checking it.   If changed, I suppose by adding 
a new rule, the receivers SHOULD have more information to properly 
handle it.

-- 
HLS

On 5/11/2018 8:00 AM, Alexey Melnikov wrote:
> 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..
>

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 12 May 2018 22:35:44 -0400

Hi,

Somewhat in keeping with a cheeky question I asked the IAB at the last
plenary, I want to ask some questions.  These are not actually for
John, though they hang off his message.  The 2d person pronoun is
directed at the reader of this message, not John.

> integrity of the mail systems depends on it in important ways.  

Do you think that, given the various ways that this is now actually
violated pretty widely around the Internet, the "integrity of the mail
systems" is already lost?

If so, does that mean that we have a new _de facto_ mail system
emerging?

If so, does that imply that we ought to document it in some
documentation series?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 13 May 2018 13:50:23 +0200

Just a couple of notes:

> For emails from p=reject domains:

Some put p=reject; pct=0; for the sole purpose of having From: rewritten.  The
principle of least surprise would suggest to apply rewriting uniformly.

> "alexey=[email-masked]". The original From header field will
> be preserved in the X-Original-From header field, which can be used for
Besides encoding, the semantic of alexey=[email-masked] will
never be clear, even to those familiar with DMARC.  My experience after
replying "all" on one of those messages was not what I expected, and I couldn't
tell if that was a bug[*].  How about just appending the original address to
Reply-To[**]: and keep the From: address as simple as [email-masked]?

jm2c
Ale
-- 

[*] IIRC, my reply was duplicated and one of those messages had three DKIM
signatures bearing d=ietf.org; s=ietf1; rather than the usual two ones.

[**] Or a brand new field such as List-Reply-To:, when we'll standardize
rewriting  --no, I don't think it's going to go away with ARC.

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 May 2018 11:22:50 -0400

Andrew,

I think the questions are appropriate and hope others will
address them.   For my personal reactions, see below but, for
those who don't know (I think you do), I've become increasingly
concerned in recent years that the IETF is doing work that
assumes an Internet that no longer really exists or is making
decisions that are unrealistic given external and operational
changes.  I also think it has gotten very hard to talk
constructively about tradeoffs and compromises in the IETF, with
far too many strategic decisions made either on the basis of
"several large vendors (or open source implementations) have
done this, so we must (uncritically) adapt" or "X is important,
we believe in X, and therefore anything that doesn't support X
is evil and should be suppressed or eliminated".  However, I
hope my comments below help initiate that discussion rather than
leading to defensiveness.

--On Saturday, 12 May, 2018 22:35 -0400 Andrew Sullivan
<[email-masked]> wrote:

> Hi,
> 
> Somewhat in keeping with a cheeky question I asked the IAB at
> the last plenary, I want to ask some questions.  These are not
> actually for John, though they hang off his message.  The 2d
> person pronoun is directed at the reader of this message, not
> John.
> 
>> nothing in the mail path between what we now call the
>> submission server and the final delivery server gets to
>> interpret, much less tamper with, the internals of the local
>> part of an address. While we have many examples of systems
>> breaking that rule, the integrity of the mail systems depends
>> on it in important ways.  
> 
> Do you think that, given the various ways that this is now
> actually violated pretty widely around the Internet, the
> "integrity of the mail systems" is already lost?

I think we are in a losing battle and that DMARC, and these
changes, are just symptoms.  I suggest that one of those other
fundamental assumptions of the mail system was that we would
have a large collection of MTA installations, with systems
located logically close enough to the senders and recipients to
make notions of user control and authorization for policies and
actions meaningful.  Instead, one of the things we hear often
today is that a very large percentage of the world's email
either originates with, or terminates on, and extremely small
number of providers and that much of it is intra-provider, i.e.,
from one <foo>mail user to another <foo>mail user.

One of the manifestations of those changes for email is that, if
someone had come along 20-odd years ago and said "we think this
new idea is really a great one for solving problem Z and don't
really care about what our solution will break because it won't
affect our users", we would have said something like "can't stop
you, have fun, and let us know how it works out for you".  The
result was clear: to borrow from a metaphor from that period,
the sides of the information superhighway became littered with
the corpses of proprietary email systems that didn't
interoperate well with Internet mail.   In that same
environment, the IETF examined the impact on possible changes to
interoperability very carefully.  As examples, I am convinced we
could have done much better with the SMTP extension model, and
perhaps even somewhat better with MIME, had we not cared about
interoperation with deployed and installed systems that
conformed to the earlier specs and their users.

Today, we have a small collection of dominant mail providers.
Their users may be asked to agree to their policies (and
periodic changes to those policies).  If the users disagree,
they are presumably free to go elsewhere, but, as those
providers become more and more dominant and their policies more
and more similar, for many users there really isn't an
"elsewhere" to go    Then several of those dominant mail
providers get together, design a piece of protocol (and, in
DMARC's case, a trust model) outside the IETF or any other open
process that will work for them and their understanding of, or
preferences about, their users/customers, and then effectively
say to everyone else "you just need to adapt to this because,
otherwise, we won't let you talk with our users" and maybe even
(although I admit I've not heard this explicitly) "if it breaks
your mailing list system, that is not a problem because we have
a better solution anyway and it is free (if you don't count
paying in control, privacy, etc.)".

So, what does the IETF do?  We adapt to whatever decisions those
providers we have made and have arguments about which of the
small details of the adaptations are least harmful.  On a
technical and operational front, I actually don't see what else
we can do.  We have enough participants who use the systems of
those providers and who have no practical choice that not
adapting in some way would make the IETF less open.  That is why
I've tried to be careful to ask questions about the approach
taken that might result in better understanding or minor tuning,
but not to oppose it.   We also create a WG to consider and
develop alternatives, but it moves slowly in a complex
environment (probably inevitable).  We don't know if it will
produce a useful result, nor whether that result will be
deployable, with all of the workarounds, adaptations, and other
kludges that are installed in between possibly acting as
impediments and other sources of inertia. 

There are some non-technical things we possibly could have done
(I don't know whether they are still feasible).  We could have
worked with ISOC to explain and widely publicize the risks of
protocol development by oligopoly or trade associations
controlled by big actors.  We might even have been able to do
something jointly with, e.g., ISO, IEC, and/or ITU to deliver
that message: they are certainly aware of the problem and have
been since before there was an IETF.   Would anyone have
listened?  I don't know.  Was the decision not to do that
influenced by noticing that the same large providers are paying
a large fraction of ISOC's bills and the expenses of many IETF
participants?  I hope not.  

> If so, does that mean that we have a new _de facto_ mail system

Maybe but, if so, it isn't new.  It is an updated version of a
system in which to most of toe world, "email" meant accounts
with, e.g. (and in no particular order), AOL, CompuServe,
MSMail, Prodigy, MCIMail, some BITNET/EARN/NETNORTH hosts, and
some CSNET hosts, each of which could transfer traffic to the
others either indirectly or via quasi-proprietary gateways.  We
"won" that time because Internet mail became the core
interoperability model.  I'm less optimistic this time.

On the other hand and as just one example, if we have really
decided that having messages encrypted in transit is critically
important, then maybe we need much better "best practices"
advice about how MX preferences and relays should be configured
than was the case when we considered reliably getting the
messages through as our most important objectives.
 
> If so, does that imply that we ought to document it in some

If so, yes.  In many respects, my problem isn't that these
changes are occurring but that the IETF is in denial about them.
That also suggests that this is exactly the wrong time to be
discussing ways of shutting down mechanisms for getting things
documented that may not be consistent with, e.g., the majority
IETF view of reality.

best,
    john

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 May 2018 18:05:39 -0400

John C Klensin <[email-masked]> wrote:
    > changes.

I think that our great tradition is to lead the industry with asperational
Draft Standards, and then to document reality in trailing Internet Standards.

We *have* been slow on the second part, because it's hard to get that kind of
work paid for.    (That's one of the things I want to tell ISOC in June)

    > I also think it has gotten very hard to talk

I agree.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 13 May 2018 22:35:14 -0400

​What worries me rather more than people bending the SMTP standards to make
them meet their needs is that the idea of open communications ​is being
lost.

Open source and open specifications are fine. But they are much less
important than open infrastructures. What matters to me with mail is that
it is the one communications network everyone I know is on. I don't have
that for messaging (30+ competing closed networks) and I don't have that
for voice any more. The telephone system is becoming more and more useless
every day because it has no technical controls to block spam.

We faced a similar issue with sharing files over the Internet in the early
90s. FTP worked, kinda but the specification was really not fit for
purpose. It is layered on Telnet for a start and it assumes a particular UI
model which is a really bad one. But FTP was the way everyone did things so
there was absolutely no point in ever thinking about replacing it with
something better.

Until some people did - HTTP

The Web was not simply a replacement for FTP though, it was a whole
different application that just happened to subsume enough FTP
functionality to replace it. And it did that in a very particular way, by
introducing an interoperability layer over the old and the new so that you
could use an FTP server to serve the Web if you wanted to.

I think we could certainly hive off many of the functions SMTP doesn't do
very well and develop a protocol that supports those functions decently
because it is designed to support them, they are not afterthoughts. Mailing
lists would be one of those functions.

SMTP is still a decent protocol but what people have done with it has
created an infrastructure that makes fixing it pretty much impossible.

As far as I am aware, nobody other than myself is working on a mailing list
protocol that is end-to-end secure right now. We could try to fit those
features into the old infrastructure but why do that when everyone will
need new client and server support?

---

From: Hector Santos <[email-masked]>
Date: Tue, 15 May 2018 09:37:57 -0400

> principle of least surprise would suggest to apply rewriting uniformly.

At the very least, we should allow the declaring DMARC domain to 
dictate/publish his intent specifically using a new tag in the domain 
record, such as 'rewrite=allowed|1" or something directly specific to 
this technical protocol intent.

I don't think pct=0 was it.  It was not documented for such an 
technical protocol intent so we shouldn't be inventing new meanings of 
the existing tags.   If we going to change code, then leverage the 
opportunity and use a new specific tag,

I don't prefer rewriting at all.  Once we "normalized" the 5322.From 
rewriting, the long time DKIM issues may be finally done with, i.e. 
ARC is less meaningful but in fact, DKIM itself becomes more 
meaningless, if not already.  The 5322.From is the only required hash 
binding header for DKIM.   Any transformations, including a rewrite 
with a "X-Original-From" addition, should be reversible and verifiable.

We make email more complex by justifying 5322.From rewriting.

Thanks

-- 
HLS

---

From: Brandon Long <[email-masked]>
Date: Tue, 15 May 2018 15:15:03 -0700

On Sun, May 13, 2018 at 4:50 AM Alessandro Vesely <[email-masked]> wrote:

> will

One of the benefits for having a per-sender unique from address to rewrite
to, is that it plays better with email clients who might otherwise get
confused that all of the messages are from the same person.  For example,
Gmail doesn't display quite right the "authors" of a thread if they're all
from the mailing list.  Other address book software might "learn" the name
of a list, or add the list address to the name or other confusion.

That said, using unique rewrites does open up a different can of worms in
terms of spam forwarding and different types of address book issues.

A client could use the List-ID header matching the From header to be
smarter, it's a bit harder if every mailing list provider used a different
rewriting scheme
to be smarter.

Which works better in practice, I don't know.  Adding Reply-To, even if the
from keeps the per-user rewriting, is probably a good idea.

Brandon