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 dotzero@xxxxxxxxx account for some working groups and will switch participation on the ietf list to that account. > -----Original Message----- > From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of John C Klensin > Sent: Friday, May 11, 2018 11:03 AM > To: Alexey Melnikov; ietf@xxxxxxxx > 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'example.com@xxxxxxxxxxxxxx" or > "alexey?utf8"?40?example.com@xxxxxxxxxxxxxx" > ) 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 > alexey%example.com@xxxxxxxxxxxxxx > > 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 > <aamelnikov@xxxxxxxxxxx> 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, > > "alexey@xxxxxxxxxxx" email address would become > > "alexey=40example.com@xxxxxxxxxxxxxx". 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. > > >
