Subject: Re: DMARC and ietf.org

From: John Payne <[email-masked]>
Date: Mon, 18 Jul 2016 07:42:44 -0400

> On Feb 24, 2016, at 1:46 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> On 25/02/2016 05:06, Michael Richardson wrote:
>> 
>> Russ Housley <[email-masked]> wrote:
>>> We are in the process of upgrading mailman. As part of that upgrade
>>> there are new settings. The Secretariat has been discussing the various
>>> choices for those new settings with some of the Tools Team. If there is
>>> anyone in the community that has a lot of experience with mailman
>>> setting, we would like to consult with you.
>> 
>> Good, thank you for this update.
>> 
>> I'd like to ask that we capture the reasons (the thought process) for the
>> settings into at least a wiki page, if not a BCP.
> 
> Yes, and maybe leave a little time for public debate before implementation,
> because a lot of people's working habits may be affected.

Things seem to have been (publicly) silent on the topic of IETF mailing lists and DMARC since feb.  Can we have an update please?

Thanks
John

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Jul 2016 10:38:28 -0400

John Payne <[email-masked]> wrote:
    >>> I'd like to ask that we capture the reasons (the thought process) for
    >>> the settings into at least a wiki page, if not a BCP.
    >>
    >> Yes, and maybe leave a little time for public debate before
    >> implementation, because a lot of people's working habits may be
    >> affected.

    > Things seem to have been (publicly) silent on the topic of IETF mailing
    > lists and DMARC since feb.  Can we have an update please?

+1

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Russ Housley <[email-masked]>
Date: Tue, 19 Jul 2016 11:00:48 -0400

John:

>> On Feb 24, 2016, at 1:46 PM, Brian E Carpenter <[email-masked]> wrote:On 25/02/2016 05:06, Michael Richardson wrote:
>>> 

This is my understanding of the current situation.  First, no one offered to assist with the new Mailman settings.  We remain open to community review and suggestions.

The IETF mail server does not reject on SPF or DMARC mismatches.  All incoming email is passed through SPAM Assassin, and SPF/DMARC are taken into account in the scoring system.

Outgoing Mailman email still has the problem.  Mailman has an option we can enable to force DMARC-spoofing sender rewriting of all outgoing Mailman email.  If we enable that option, the From: field rewriting and could be disruptive in unknown ways.

We know that outgoing alias email still has the problem.  The Secretariat is did some experiments with some additional headers (Resent-*) to alias mail.  They were not able to determine whether this headers helped destination servers or not.

Russ

---

From: Dave Crocker <[email-masked]>
Date: Tue, 19 Jul 2016 17:34:26 +0200

> We know that outgoing alias email still has the problem.  The Secretariat is did some experiments with some additional headers (Resent-*) to alias mail.  They were not able to determine whether thi…

The major issue is for mail sent through a mailing list, from authors 
whose From: domain has a DMARC policy calling for dire action (reject or 
quarantine) if DMARC does not validate at the final recipient's side.

To overcome this, the ad hoc convention for mailing lists is to rewrite 
the From: header field, using an address belonging to the mailing list 
-- ie, no longer using the author's address -- and modifying the Display 
(friendly) string to /add/ something like "- via <listname>".  In 
addition the Reply-to: header field is set to be the original author's 
address, so that direct replies from a recipient will go back to the 
proper place.

When organized by author address, this means that an actual author's 
mail is listed differently depending upon whether their messages are 
direct to the recipient, versus whether they went through a mailing 
list.  It likely also means differential listing when sorted on the 
Display string...

The modified display string will now have the extra visual cruft and 
there is no empirical basis for justifying that cruft, in terms of user 
behavior or any other safety and security.  That is, it's an entirely 
logical modification, but there is no basis for believing that it is 
useful. (This is an unfortunate fact of usability life.)

There is an effort (ARC) to develop a capability that might let 
DMARC-related messages survive transit of a mailing list, but that 
effort is still nascent.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jul 2016 19:47:49 +1200

On 20/07/2016 03:34, Dave Crocker wrote:
>> Outgoing Mailman email still has the problem.  Mailman has an option we can enable to force DMARC-spoofing sender rewriting of
>> all outgoing Mailman email.  If we enable that option, the From: field rewriting and could be disruptive in unknown ways.
>>
>> We know that outgoing alias email still has the problem.  The Secretariat is did some experiments with some additional headers
>> (Resent-*) to alias mail.  They were not able to determine whether this headers helped destination servers or not.
> 
> 
> The major issue is for mail sent through a mailing list, from authors whose From: domain has a DMARC policy calling for dire
> action (reject or quarantine) if DMARC does not validate at the final recipient's side.
> 
> To overcome this, the ad hoc convention for mailing lists is to rewrite the From: header field, using an address belonging to
> the mailing list -- ie, no longer using the author's address -- and modifying the Display (friendly) string to /add/ something
> like "- via <listname>".  In addition the Reply-to: header field is set to be the original author's address, so that direct
> replies from a recipient will go back to the proper place.

Can mailman do that *selectively*, i.e. only for sending domains that publish
a reject or quarantine dmarc policy?

If so, I think we have little alternative than to switch this on at some
point in the next few months. (And the equivalent for the aliases.)

For me, that point would arrive on the day that gmail changes its behaviour
to obey the reject policy. At the moment, gmail treats reject as quarantine,
which means that I have to fish stuff out of spam sometimes. If that changes
to "reject means reject", I will have to rush around finding another email
address to use for IETF purposes, unless sendmail does the rewrite.

So we need a definite decision whether the IETF (and IRTF) mailman will
be changed to do the rewrite.

Could we do an experiment with the rewrite on a couple of mailing lists?
Soon?

    Brian

> 
> When organized by author address, this means that an actual author's mail is listed differently depending upon whether their
> messages are direct to the recipient, versus whether they went through a mailing list.  It likely also means differential
> listing when sorted on the Display string...
> 
> The modified display string will now have the extra visual cruft and there is no empirical basis for justifying that cruft, in
> terms of user behavior or any other safety and security.  That is, it's an entirely logical modification, but there is no basis
> for believing that it is useful. (This is an unfortunate fact of usability life.)
> 
> There is an effort (ARC) to develop a capability that might let DMARC-related messages survive transit of a mailing list, but
> that effort is still nascent.
> 
> 
> d/

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2016 11:32:14 -0000

>(Resent-*) to alias mail.  They were not able to determine whether this headers helped destination servers or not.

I can promise you they don't.  There is a thing called ARC under
development that is intended to undo most of the DMARC damage.  The
large mail systems and the Mailman developers are all aware of it.

Until then, there's a range of workarounds that range from bad to
really unpleasant:

http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

The most common (and in my view one of the worst) is to rewrite the
From: line to use the list's address, sometimes just addresses with
DMARC problems, sometimes for all addresses.  For this audience I
expect I don't have to explain why that's bad.

On my lists (which are in sympa rather than mailman, but with the
same issues) I do a per-author rewrite on DMARC'ed addresses, e.g.

 From: Ms Meyer <[email-masked]>

turns into

 From: Ms Meyer <[email-masked]>

That makes DMARC happy, and I set up forwards good for a few days
so replies generally work.  (Yes, dmarc.fail is a real domain.)

I'd be happy to talk to whoever maintains our Mailman to help do the
same thing.  Mine is implemented as a small shim between the list
software and the sendmail program, with no patches to the list manager
code.

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jul 2016 13:31:42 -0400

Russ Housley <[email-masked]> wrote:
    >> Things seem to have been (publicly) silent on the topic of IETF
    >> mailing lists and DMARC since feb.  Can we have an update please?

    > This is my understanding of the current situation.  First, no one
    > offered to assist with the new Mailman settings.  We remain open to
    > community review and suggestions.

>>>> setting, we would like to consult with you.

So, I think we are waiting for some posting to tools-discuss about what the
settings are going to be.

    > Outgoing Mailman email still has the problem.  Mailman has an option we
    > can enable to force DMARC-spoofing sender rewriting of all outgoing
    > Mailman email.  If we enable that option, the From: field rewriting and
    > could be disruptive in unknown ways.

    > We know that outgoing alias email still has the problem.  The
    > Secretariat is did some experiments with some additional headers
    > (Resent-*) to alias mail.  They were not able to determine whether this
    > headers helped destination servers or not.

okay, so I believe that the 10 nomcom members need to be given @ietf.org
accounts available via IMAP for their deliberations, as the DMARC debacle
has essentially broken the ability for the nomcom to receive comments.
(I hope that will get through the china firewall, because email regularly
failed in all the years I was involved)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jul 2016 13:34:01 -0400

Dave Crocker <[email-masked]> wrote:
    > DMARC-related
    > messages survive transit of a mailing list, but that effort is still
    > nascent.

It's been two years of "please wait" (or is it three?)

I think that it is time to reject email coming into mailing lists that
has p=reject policy, and not forward it, as that is the policy of the mail
system.   I realize that this screws a large number of people, but I think we
have really no choice.  The protocols are either respected, or not.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Jul 2016 19:42:22 +0200

> It's been two years of "please wait" (or is it three?)

Indeed.  And it will be longer before a work-around is both developed 
and deployed.  You're welcome. No, really, it was a pleasure 
contributing to the effort...

> system.

Go ahead.  I'm sure the relevant users will not pursue any remedies at 
losing connectivity, such as moving to a different list provider.

Which is to say, that I and almost all others are /very/ unhappy with 
this 'side effect' problem caused by DMARC, but that real-world 
pragmatics are making it unrealistic to take simple, purity-based 
actions in response.

d/
-- 

   Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2016 17:35:28 +1200

On 21/07/2016 05:42, Dave Crocker wrote:
> Indeed.  And it will be longer before a work-around is both developed and deployed.  You're welcome. No, really, it was a
> pleasure contributing to the effort...
> 
> 
> Go ahead.  I'm sure the relevant users will not pursue any remedies at losing connectivity, such as moving to a different list
> provider.
> 
> Which is to say, that I and almost all others are /very/ unhappy with this 'side effect' problem caused by DMARC, but that
> real-world pragmatics are making it unrealistic to take simple, purity-based actions in response.

Yes. So I repeat the question: Since the most pragmatic, non-purity-based
solution is to rewrite the sender field for mail from p=reject (or p=quarantine)
domains, when will we change the IETF and IRTF mailmen to do so?

I'm happy to help experiment for any lists for which I am an admin, but we need
the IETF's IT support to take this very seriously very soon. The day that gmail
changes its policy, I estimate that at least 20% of the IETF will be broken.

    Brian

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Jul 2016 08:29:21 +0200

> domains, when will we change the IETF and IRTF mailmen to do so?

I'm sure you really meant this, but just to be careful, what with this 
being a technical point in a technical forum, it's worth clarifying that 
the rewriting is for the rfc5322.from field and not the rfc5322.sender 
field.

d/

ps. you're welcome.  no need to thank me...

-- 

   Dave Crocker

---

From: [email-masked]
Date: Thu, 21 Jul 2016 09:43:03 -0700 (PDT)

> the rewriting is for the rfc5322.from field and not the rfc5322.sender

I have an additional suggestion.

If we're going to do this - and I'm not going to offer an opinion on whether or
not it should be done - I'd like to see it done in a fashion that's both
detectable and reversible. That way people using sieve or procmail or whatever
will be able to undo the damage.

The most straightforward way to accomplish this would be to make copies of the
original fields with different names, but of course many other approaches  are
possible.

				Ned

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Jul 2016 13:12:10 -0400

> original fields with different names, but of course many other approaches  are

I do not see MailMan settings to make that happen.  Maybe I missed something...

Russ

---

From: [email-masked]
Date: Thu, 21 Jul 2016 18:24:56 -0700 (PDT)

> I do not see MailMan settings to make that happen.  Maybe I missed something...

That's most unfortunate, and I have to say moves my position from neutral
to "don't do it".

Reversible damage is one thing, irreversible damage another.

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jul 2016 17:13:25 +1200

> Reversible damage is one thing, irreversible damage another.

That's the dilemma. An agent that obeys p=reject does irreversible
damage too. I can figure out how to live with p=reject being treated
as p=quarantine, but not with "reject means reject". And it isn't
just me, it's every IETFer using a certain mail operator that has
threatened to obey p=reject Real Soon Now.

   Brian

   Brian

---

From: Dave Crocker <[email-masked]>
Date: Fri, 22 Jul 2016 08:55:41 +0200

On 7/22/2016 7:13 AM, Brian E Carpenter wrote:
> as p=quarantine, but not with "reject means reject".

There are different levels of issue here.  The one that Ned is raising 
is something that we might be able to affect.

The changes made by mailing list software were done in haste and without 
community deliberation, in response to a sudden escalation.  The efforts 
were well-intentioned, but haven't been vetted.

Since the changes are going to be with us for quite awhile (and maybe 
permanently) we ought to formulate a recommendation, up to the level of 
making it a BCP (or even PS...)

Reversibility of the changes to the message is a requirement I hadn't 
heard before, but it makes complete sense.  My own complaint is about 
messing with the usability of the From field by the recipient.

I suggest initiating a small effort to formulate a suggested 'standard' 
behavior by mediators (eg, mailing lists) that modify the rfc5322.From 
field, in response to DMARC issues.

The effort should include some usability folks, since this is visible to 
recipients and the design of the details should attend to... well, you 
know, utility and ease of use.

d/

-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 22 Jul 2016 10:46:24 +0200

On Fri 22/Jul/2016 08:55:41 +0200 Dave Crocker wrote:
>>>>> The most straightforward way to accomplish this would be to
>>>>> make copies of the original fields with different names, but
>>>>> of course many other approaches  are possible.
>>>>
>>> That's most unfortunate, and I have to say moves my position from
>>> neutral to "don't do it".
>>>
> There are different levels of issue here.  The one that Ned is raising is
> something that we might be able to affect.
>
> community deliberation, in response to a sudden escalation.  The efforts were
> well-intentioned, but haven't been vetted.
>
> permanently) we ought to formulate a recommendation, up to the level of making
> it a BCP (or even PS...)
>
> Reversibility of the changes to the message is a requirement I hadn't heard
> before, but it makes complete sense.  My own complaint is about messing with
> the usability of the From field by the recipient.

So, in principle, it would be a decent solution to mitigate as follows:

1) MLM alters From: but copies it to, say, MLM-Original-From:,

2) MX receives a duly signed and aligned From:, and accepts the message,

3) a mitigation-aware filter, possibly using sieve or procmail or whatever, 
detects and reverses the damage introduced in (1), and

4) recipients are happy.

Let me stress that the legitimacy of (3) hinges on recipients setting up the 
damage-fixer themselves, in person.  Specifically, they should allow undoing 
alterations by MLMs they recognize, and only if their signature verifies. 
Otherwise, any attacker can add a spurious MLM-Original-From:.

> behavior by mediators (eg, mailing lists) that modify the rfc5322.From field,
> in response to DMARC issues.
>
> recipients and the design of the details should attend to... well, you know,
> utility and ease of use.

IMHO Ned's proposal is better than conditional signatures as it can be 
modulated per recipient and per list.  However, it requires double effort by 
concerned users, who have to set up the damage-fixer everytime they subscribe 
to a list.  That operation cannot be automated, because neither recipient's MX 
nor client are aware of subscriptions.  There are various ways to overcome the 
latter issue, which can be included in the above suggested effort.

Ale
-- 
http://fixforwarding.org/

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2016 09:12:47 -0000

>I do not see MailMan settings to make that happen.  Maybe I missed something...

The Mailman crew is putting all of their effort into 3.x so I doubt
you'll see anything in 2.x beyond what's there now.

I've found that the best place to do anti-DMARC stuff is in a shim
between the list package and the sendmail program, since it can do
whatever you want to the message and it still works when you upgrade
the list software.

R's,
John