Subject: Re: DMARC and ietf.org

From: =JeffH <[email-masked]>
Date: Fri, 12 Aug 2016 10:20:12 -0700

Regardless of details, applying some sort of remediation to 
ietf.org/mailman is becoming more pressing IMV -- I am noticing that 
email, sent from pingidentity.com (p=quarantine; pct=100;) via IETF 
mailing lists, is not being delivered to my paypal.com inbox at all. 
Also, the same is occurring for some email from microsoft.com 
(p=quarantine; pct=30;). The same is true for email I might send via my 
@paypal.com persona.

The W3C mailing list manager (MLM) is apparently configured to do 
rfc5322.from field re-writing which seems to ameliorate the DMARC-MLM 
issues (in my experience, at least), and it would be helpful if the IETF 
would take similar measures.

thanks,

=JeffH

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 12 Aug 2016 23:23:31 +0100

I couldn’t agree more.

Cheers,
Andy

On Fri, Aug 12, 2016 at 6:20 PM, =JeffH <[email-masked]>
wrote:

> (p=quarantine; pct=30;). The same is true for email I might send via my @
> paypal.com persona.
>

---

From: "John Levine" <[email-masked]>
Date: 12 Aug 2016 23:15:11 -0000

>would take similar measures.

Due to the volume of mail from IETF lists, I have a bunch of procmail
rules to sort them that would break if the lists put the list address
on the From: line.  And, of course, then you can't reply to the author.

I doubt that I'm the only one in this situation.

There are DMARC workarounds that are more work but suck less.

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

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Aug 2016 14:57:02 +1200

> I couldn’t agree more.

Yes. It's been months and we need to know ASAP which of the various remediations
the IETF mailing list service will apply. We all know that there's no ideal
solution but practicality requires something to be done now. Mail via IETF
lists being rejected or quarantined by mainstream mail services is not OK.
It's actually quite hard to discover if the mail service one is using is
rejecting messages.

I know that rewriting breaks some peoples' procmail setups, and I sympathise
with that, but it's a matter of choosing the least bad solution:

On 13/08/2016 11:15, John Levine wrote:
...
> See http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

Regards
   Brian

---

From: "John Levine" <[email-masked]>
Date: 13 Aug 2016 02:39:57 -0000

>Yes. It's been months and we need to know ASAP ...

ASAP?  Nothing has changed for months.

Google has repeatedly said that they're not going to turn on DMARC
until ARC is available.

R's,
John

PS: For my lists, I have a shim that rewrites addresses like
[email-masked] to [email-masked], and sets up
temporary forwards.  It's simple and works nicely, and since it's
a shim between the list manager and the MTA, it doesn't require
surgery on mailman.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 13 Aug 2016 08:02:32 -0400

There are certain senders from whom all the IETF mail I get is marked by
gmail as spam and winds up in the spam folder, because they are using
dmarc.   This hasn't gotten more urgent.   It was urgent when it started.
The complaint is that nothing has changed since then.   This is a classic
case of "best is the enemy of good enough."

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 13 Aug 2016 11:00:04 -0400

> case of "best is the enemy of good enough."

The real problem is that in the absence of standardization, when the
folks who implemented DMARC went ahead without doing something that
didn't break all use cases, there's no consensus on what is the "good
enough" solution.

Everyone can say that it's someone else's problem to fix.  Some folks
could say that you should just change mail provideres, even though
that would impose lots of pain on you.

Others could say that the mailing list admins should change their
mailing lists, even though that would impose pain on people's procmail
setups.

Others could say it was the fault of companies like Yahoo and Paypal
who didn't use different mail addresses for their official mail versus
mail from their employees who need to participate in various standards
and open source efforts, and so it should be Yahoo and Paypal's
problem to change, even though they would have to deal with the pain.

And worse, it's not obvious that anyone has the moral high ground when
they demand that someone else shoulder the burden and the pain of the
change.

ARC is supposed to be the magic bullet that will fix all of this, but
this assumes someone is going to create ARC implementations for all of
the common mailing list server implementations, and it's not obvious
that this is going to be happening, either.

Given that, it's not all that surprising that there hasn't been much
in the way of movement, since yes, people are feeling pain with the
status quo.  But it's a lot easier to blame the people who made the
change which broke things.....

					- Ted

---

From: "John R Levine" <[email-masked]>
Date: 13 Aug 2016 11:10:59 -0400

> didn't break all use cases, there's no consensus on what is the "good

DMARC was fine when it was used to protect high value company domains like 
paypal.com.  It became much less fine when AOL and Yahoo started using it 
to force the costs of their own security failures on third parties.

> that this is going to be happening, either.

The Mailman people are certainly working on it, and I plan to work on 
Sympa.  What list software are you thinking of?

More to the point, ARC lets lists keep working they way they're supposed 
to.  All of the workarounds break stuff.  The most popular workaround, 
putting the list address on the From: line, makes it hard to tell who the 
message is from, close to impossible to reply to the author of the 
message*, and trains people to be phished.

> But it's a lot easier to blame the people who made the change which 
> broke things.....

Well, yes, they certainly deserve it.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

* - anyone who says "you can put it in the Reply-To" has just shown that 
they don't understand the problem.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 13 Aug 2016 08:22:52 -0700

On 8/13/2016 8:10 AM, John R Levine wrote:
> to.

I participate in the informal group that created ARC.  I am hoping ARC 
will be helpful.

But we need to be cautious with our expectations.  First, it isn't 
operational yet, so we don't even know whether it will do what we want 
it to.  Worse, we don't know how much that will help.

That's not a claim that it won't work or won't be useful, but it is 
playing amidst some Internet-scale, multi-stage dynamics that can get 
complicated.

By way of example:  With DKIM, trust assessment is of the entity doing 
the signing, typically the originating service.  With ARC, that 
assessment still must be made, but it must be coupled with an assessment 
of the first ARC-signing entity.

Maybe that's not a big deal.  But I think that combinatorial trust 
assessments are new and therefore might be challenging.

And that's not counting the question of whether an ARC signature will 
survive better than a DKIM signature...  (The design is intended to have 
better survival, but again, it hasn't been tested in the field.)

In terms of the current discussion, the essential point is that we need 
to make decision based on the here and now, and ARC isn't part of it and 
won't be for some time yet.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Theodore Ts'o <[email-masked]>
Date: Sun, 14 Aug 2016 11:50:42 -0400

On Sat, Aug 13, 2016 at 11:10:59AM -0400, John R Levine wrote:
> The Mailman people are certainly working on it, and I plan to work on Sympa.
> What list software are you thinking of?

Do you know of anyone working on Majordomo?  (This has been the only
mailing list software that has proven to be capable of handling the
mailing list traffic for the kernel.org mailing lists.)

	     	     	     			- Ted

---

From: "John R Levine" <[email-masked]>
Date: 14 Aug 2016 12:57:19 -0400

> Do you know of anyone working on Majordomo?

Of course not.  Both MJ1 and MJ2 have been abandonware for a long time.

>  (This has been the only mailing list software that has proven to be 
> capable of handling the mailing list traffic for the kernel.org mailing 
> lists.)

This suggests it's been quite a while since you looked at the 
alternatives, since MJ1 is not particularly fast.  The most popular 
actively maintained open source list managers these days seem to be 
Mailman (python and postgres, from the GNU crowd) and Sympa (perl and 
mysql, from Renater in France.)  Both are used to manage large numbers of 
large busy lists, with archives.

I switched from MJ1 to MJ2 in about 2002 because MJ2 had much better list 
management and filtering tools, but finally gave up on MJ2 a year ago when 
it had trouble with perl 5.20 and moved everything to Sympa without much 
trouble.

More to the point, DMARC isn't going away.  If ARC works, which seems 
likely, and your lists put ARC headers on the mail, your lists can keep 
working the way they do now.  The alternative is either gross hacks to 
rewrite From: lines, or to make your lists irrelevant by telling people 
they can only use non-DMARC mail providers which in a few years will be 
none of the large ones.

Furthermore, having actually added anti-DMARC shims to both MJ2 and Sympa, 
I know that you don't have to change the list manager code at all other 
than one line to call the shim rather than calling sendmail (or whatever) 
directly.  The shim does what it needs to do and passes the message to the 
real mail injection program.  My current shim which does the dmarc.fail 
From: hackery and adds DKIM signatures is 282 lines of not particularly 
tightly written perl.

If a bunch of Linux kernel hackers can't do that to MJ1, Linux is in even 
worse shape than I thought.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 14 Aug 2016 17:22:46 +0000

> mailing list traffic for the kernel.org mailing lists.)

While I don't know the situation wrt majordomo, perhaps "ezmlm-idx"
would also work?  There is some support for DMARC in that codebase.

    https://github.com/bruceg/ezmlm-idx/commit/925870c82d7ffa6c00ce22cc348e27a48e764a09

When Postfix added support for QMQP in July of 2001, it was to
support ezmlm, which at the time was the only list manager that
was scalable enough to support the SecurityFocus lists with IIRC
more than 100k recipients.

Though that would likely require running qmail for final delivery
on the list input side, with ezmlm and Postfix handling output.

-- 
	Viktor.

---

From: S Moonesamy <[email-masked]>
Date: Sun, 14 Aug 2016 10:23:54 -0700

Hi Jeff,

For information about the facilitators experiment, please see
http://www.ietf.org/mail-archive/web/ietf/current/msg97290.html

At 10:20 12-08-2016, =JeffH wrote:
>(p=quarantine; pct=30;). The same is true for email I might send via 
>my @paypal.com persona.
>
>rfc5322.from field re-writing which seems to ameliorate the 
>DMARC-MLM issues (in my experience, at least), and it would be 
>helpful if the IETF would take similar measures.

There was a message [1] from Russ Housley on this thread in which he 
mentioned that: "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".  It was also mentioned that "SPF/DMARC are taken 
into account" for the scoring of incoming email to ietf.org.

Regards,
S. Moonesamy

1. https://www.ietf.org/mail-archive/web/ietf/current/msg98965.html

---

From: Michael Richardson <[email-masked]>
Date: Sun, 14 Aug 2016 18:20:37 -0400

From: Michael Richardson <[email-masked]>

I agree strongly with you: the IETF needs to do something in some direction.

That something could be to properly reject email with a DMARC policy that
does not permit forwarding.  That would piss off an awful lot of IETF
participants, but it would be simple, since it requires no protocol
changes, just social changes.

=JeffH <[email-masked]> wrote:
    > mailing lists, is not being delivered to my paypal.com inbox at
    > all. Also, the same is occurring for some email from microsoft.com

It seems that email is operating exactly as DMARC intends :-)

    > issues (in my experience, at least), and it would be helpful if the
    > IETF would take similar measures.

But, that would also render the From: field meaningless.

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

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2016 01:22:08 -0000

>changes, just social changes.

Hmmn, the one approach that is unambiguously worse than doing nothing,
since it would confirm every worst fear that we're more interested in
playing purity games than in getting work done.

If we actually want to do something, we should decide what to do and do it.

It's not like there's any mystery about what the options are.  This
page in the old ASRG wiki lists them all and hasn't changed in ages:

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

The options built into mailman 2 are:

 * moderate or reject DMARC'ed submissions

 * rewrite the From: line with the list address

 * wrap messages sort of like one-message digests

Personally, I think those are all pretty bad, so we should do
something else.  (If I had to pick one, I'd pick the last one since
it's the easiest to undo on the way in.)

Anything else would require some development.  I am one of the few
IETF participants who has actually written anti-DMARC code for mailing
lists, so I have some idea of how much work it is.

My preferred approach until ARC is usable is to rewrite the From:
address to a legible forwarding address.  The IETF already handles a
bazillion forwarding addresses for I-D and RFC authors, so I'd think
it wouldn't be terribly hard to adapt that.  You don't have to change
any mailman code; you can do everything in a shim between the list
manager and the outgoing postfix submission program.

My form is [email-masked],* but if wildcard MX records
are scary, it could be [email-masked].  Having done
this before, I know it's not terribly hard, and I'd be happy to help
make it work.

R's,
John

* - yes, dmarc.fail is a real domain.  If the IETF asks nicely, I'd be
happy to give you dmarc.wtf.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 15 Aug 2016 11:31:16 +0200

On Mon 15/Aug/2016 03:22:08 +0200 John Levine wrote:
> 
> My form is [email-masked], but if wildcard MX records

[email-masked] would involve even
less work and worries.  IMHO, it is not so much its forcing recipients
to refurbish their wit in order to discern phishes, as its rendering the
From: field meaningless, which troubles this workaround's viability.

Ale
--

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 15 Aug 2016 07:44:08 -0400

On Sat, Aug 13, 2016 at 11:10:59AM -0400, John R Levine wrote:
> paypal.com.  It became much less fine when AOL and Yahoo started using it to
> force the costs of their own security failures on third parties.

Worth noting is that their deployment of DMARC has done *nothing*
to address those security failures and thus *nothing* to stop the
forgeries that were the alleged impetus for the deployment.  In fact,
it's arguably made the impact of those worse because they now arrive
with whatever degree of endorsement DMARC validation provides.

---rsk

---

From: Theodore Ts'o <[email-masked]>
Date: Mon, 15 Aug 2016 09:01:06 -0400

>From what John has said, he's actually made the from field work:

% dig -t mx dmarc.fail +nocomments

; <<>> DiG 9.10.3-P4-Debian <<>> -t mx dmarc.fail +nocomments
;; global options: +cmd
;dmarc.fail.			IN	MX
dmarc.fail.				3599	IN	MX	20 mail1.iecc.com.
;; Query time: 188 msec
;; SERVER: 192.168.86.1#53(192.168.86.1)
;; WHEN: Mon Aug 15 08:58:07 EDT 2016
;; MSG SIZE  rcvd: 69

I do wonder how he deals with the spam reputation problem of his
forwarding server if too many spammers try to send mail to
[email-masked] --- I assume he must do a lot of
anti-spam filtering and is refusing to forward stuff which is spam?

Hopefully he's using a more intelligent spam filter than Gmail is,
though.  :-)

	https://plus.google.com/+DavidMiller/posts/ifyNptbyxs1

Maybe spammers are starting to use patches as filler?  Who knows.  :-(

Next thing you know, maybe they'll start using excerpts from I-D's,
and then where will the IETF be?

						- Ted

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Aug 2016 10:53:24 -0400

John Levine <[email-masked]> wrote:
    >> That something could be to properly reject email with a DMARC policy
    >> that does not permit forwarding.  That would piss off an awful lot of
    >> IETF participants, but it would be simple, since it requires no
    >> protocol changes, just social changes.

    > Hmmn, the one approach that is unambiguously worse than doing nothing,

Good, we agree about this, but, I still think we need to lead with a carrot
(new DMARC spec to solve the problem), and a stick (date at which we will
comply to DMARC)

    > playing purity games than in getting work done.

That's one way to look at it, and I'm not saying it's wrong.

I think it shows that we actually care about the contents of our
specifications, and that we actually expect others to.

    >  * wrap messages sort of like one-message digests

Hah. So this is the same debate 6man has about IPv6 Extension Header
insertion :-)

    > Personally, I think those are all pretty bad, so we should do something
    > else.  (If I had to pick one, I'd pick the last one since it's the
    > easiest to undo on the way in.)

It's been like two years that I said the same thing.

    > bazillion forwarding addresses for I-D and RFC authors, so I'd think it
    > wouldn't be terribly hard to adapt that.  You don't have to change any
    > mailman code; you can do everything in a shim between the list manager
    > and the outgoing postfix submission program.

I call this NAT for email.
I'd rather do IPIP for email and wrap the messages.

---

From: "John R Levine" <[email-masked]>
Date: 15 Aug 2016 11:35:20 -0400

> (new DMARC spec to solve the problem), and a stick (date at which we will

I can promise you that the large mail providers will say "that's nice" and 
will not change the way they handle DMARC.  They have a large investment 
in it, and they see significant benefits rejecting actual forgery.  The 
number of bogus messages that DMARC rejects vastly outnumber the mistakes, 
but unfortunately the mistakes are painful to us.

We have no leverage here.  It's ARC or nothing.

> I call this NAT for email.

Kind of, but it's 1-1 NAT where you can look at the NAT address and know 
what the underlying address is, so you still see something useful in your 
MUA's message list.

Regards,

---

From: [email-masked]
Date: Mon, 15 Aug 2016 08:45:57 -0700 (PDT)

> what the underlying address is, so you still see something useful in your

And if you have the tools, you can undo the damage.

I regard being able to undo whatever is done as a "must have".

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Mon, 15 Aug 2016 09:41:00 -0700

Hi Alexey,

The thread about "DMARC and ietf.org" goes back to July 2014.  I took 
a quick look at the draft about Interoperability Issues Between DMARC 
and Indirect Email Flows.  It is odd that the non-IETF RFC is an 
Informational reference.  Anyway, that's not a matter I am interested in.

The issue with the "DMARC and ietf.org" discussion is that nobody is 
doing anything about messages from senders with DMARC policies which 
might be encounter delivery failures when the messages are sent to 
ietf.org mailing lists.  Some of the possible changes to address the 
issue can have an impact on a more than a decade-old IETF practice.

Could you please look into this matter?

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Aug 2016 08:22:42 +1200

> From: field meaningless, which troubles this workaround's viability.

Since the IETF already has a global white list of approved posters that
is already used by mailman, it shouldn' be hard to use the same white list
to admit traffic to the remailer and reject bogons.

   Brian

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2016 20:48:20 -0000

>with whatever degree of endorsement DMARC validation provides.

Acually, it's been quite effective for what Yahoo and AOL cared about.

Yahoo's problem was that crooks had stolen people's address books so
their users were getting spam with faked return addresses of people
they knew, sent from botnets outside of Yahoo, provoking many
expensive support calls.  Turning on DMARC stopped that cold.

Of course, it also stopped other stuff which is why we're here.

R's,
JOhn

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2016 20:54:08 -0000

>> [email-masked] would involve ...

>dmarc.fail.	3599	IN	MX	20 mail1.iecc.com.

Yup.  It's even DNSSEC signed.

$ dig yahoo.com.dmarc.fail mx +dnssec

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47725
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;yahoo.com.dmarc.fail. 		IN     	MX

;; ANSWER SECTION:
yahoo.com.dmarc.fail.  	3599   	IN     	MX     	20 mail1.iecc.com.
yahoo.com.dmarc.fail.  	3599   	IN     	RRSIG  	MX 8 2 3600 20161011000000 20160810041505 58563 dmarc.fail. J9UaHbKJPwu5vK/jxJKrv0pZH6bzI8TgDY78m4S8SWUiUoB/irnlur3Z SsowLaiOjekzhYqiPmT6KOq7dt2G0lD5Pil4Z8SA0MCFWHcYyyWNMT/D eka93UNGoFzVBzNCYLzTyduy/P01isqKelkC6BZaX7tTm2CWlLKD9Th6 avM=

>anti-spam filtering and is refusing to forward stuff which is spam?

I turn off the forward a day or so after the list message goes out.
The forwarder uses the usual Spamhaus BLs to block incoming mail.  So
far the amount of spam has been too low to notice.  Maybe I'm lucky,
but I think the time limited time addresses make scraping and spamming
unproductive.

As I noted in an earlier message, the IETF already has a bazillion
forwarders for I-D and RFC authors, so this problem is not a new one
for the IETF.

R's,
John