Subject: Problem with the draft-all aliases

From: "Christian Huitema" <[email-masked]>
Date: Tue, 3 Jan 2017 12:39:13 -0800

Last week, I was sending a SECDIR review of a draft in WGLC last week. The
guidelines are to send such reviews to the SECDIR list, the IESG and the
<draft>.all alias. And shortly after that, I received a mail from "Mail
Delivery System <[email-masked]>" telling me that something
went wrong. The problem report said this (I have edited the draft author
name and domain):

<[email-masked]> (expanded from
    <[email-masked]>): host
    mx1.example.com[x.x.x.x] said: 551 5.7.1 SPF fail:
    'mail.ietf.org'[4.31.198.44], 'huitema.net'; REJECT (in reply to RCPT TO
    command)

I just copied the review directly to the authors' individual addresses, and
they received it fine. But obviously, something is wrong in the IETF's
guidance to reviewers, or in the implementation of these expansion lists.
The simple "exploder" function just does not work if the sender is left to
the original "from" address. That exploder function is not compatible with
SPF, or presumably with DMARC. Who would be a good contact to discuss
improvements?

-- Christian Huitema

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 Jan 2017 15:54:49 -0500

> On Jan 3, 2017, at 3:39 PM, Christian Huitema <[email-masked]> wrote:
> 

IIRC Glen from AMSL reads this list, in which case the message has already
reached the right ears.  As for possible remediation, if the lists are
implemented as local aliases(5) in the ietf.org Postfix server, then assigning
an "owner-" alias to the list is sufficient to avoid trouble with SPF and simple
forwarding should not break DKIM or DMARC.

The aliases(5) file (or its database representation) would then contain
something along the lines of:

	document.all: [email-masked], [email-masked]
	owner-document.all: [email-masked]

-- 
	Viktor.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 3 Jan 2017 15:20:23 -0600

I've also seen it and will make sure it gets in front of the right people.

RjS

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Jan 2017 21:21:59 -0000

FWIW,

If you go to https://datatracker.ietf.org/doc/draft-ietf-blah-blah-blah/email/
you can see what the datatracker thinks the aliases expand to.

[email-masked] is intended to work, so the advice is
good.

Clearly something is currently broken.

https://trac.tools.ietf.org/tools/ietfdb/newticket is a good place to go to
report problems.

Adrian

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 Jan 2017 21:43:17 +0000

On Tue, Jan 03, 2017 at 03:54:49PM -0500, Viktor Dukhovni wrote:

> As for possible remediation, if the lists are

Another (more complex) option is to implement SRS, which routes
any bounces back to the original message envelope sender.  This
can be done via one of the various SRS milters, or more simply via
IPC rewriting tables, such as (untested, YMMV):

    https://seasonofcode.com/posts/setting-up-dkim-and-srs-in-postfix.html#_step_2_srs

Somebody with operational experience with one of the SRS options
would be a much better source of advice on this than I.

-- 
	Viktor.

---

From: Glen <[email-masked]>
Date: Tue, 3 Jan 2017 13:51:51 -0800

On 1/3/17 2:54 PM, Viktor Dukhovni wrote:
> reached the right ears.

Hi Viktor and everyone -

Thank you for the vote of confidence.  :-)

I actually do not normally subscribe to this list, for bandwidth
reasons; however, many people know how to reach me directly when there
is a concern, so I stay pretty well-informed (as I did in this case!)

I'm on vacation until January 9th, but since I was summoned by name
:-) I just wanted to respond back to let you all know that I'm aware
of this situation with the aliases.

And, in this particular case, the TMC is directly managing concerns
regarding SPF/DKIM/DMARC/etc and with Robert's response you can be
sure that they, too, now, are aware of this, and will take it under
advisement.

Thanks, and Happy New Year to you all.

Glen
--
Glen Barney
IT Director
AMS (IETF Secretariat)