DMARC methods in mailman --- [LEDE-DEV] DMARC related mass bounces / disabled subscriptions (fwd) Jo-Philipp Wich: [LEDE-DEV] DMARC related mass bounces / disabled subscriptions

[Michael Richardson]

It is unfortunate that the IETF hasn't shown more leadership here.
Auto-learning address books are going to have a problem with From lines that
say:

First Last Name Via LISTNAME <***@example.com>

since this will hijack "First Last" to point to the list, which is going to
cause all manner of email leaks. Maybe we can do better there.

[Paul Wouters]

Hi, Michael
So what do you suggest we do?

On my mail reader that will show me a list of abbreviated senders who are all "IETF discussion list on behal"

This is already the case for me on the unbound mailing list and makes it basically unreadable for me.

Paul

[Paul Wouters]

Post by Paul Wouters
On my mail reader that will show me a list of abbreviated senders who
are all "IETF discussion list on behal"
This is already the case for me on the unbound mailing list and makes
it basically unreadable for me.

address.
But, the alternative is that some email that someone autocompletes
to Paul Wouters, auto-learnt from a post to "unbound" or some other list,
goes to the list rather than you.

False dichotomy.

Paul

[Theodore Ts'o]

The real problem with all of these schemes is as they make life easier
for the user, it also makes life user for the phishers. So for
example, if we start adding a mail header field "this is *really* the
sender", or there is a standard way to parse it out of the comments of
the from field, then it will also provide a better user experience and
a better user interface to display that as the summary line of the
e-mail, and in the mail headers that are displayed for the user.

And the moment you do that, the phishers will use that to exploit
stupid uesrs, and then there will be a DMARCv2 that will break that
field, and perhaps, break mailing lists again. :-(

- Ted

[Randy Bush]

dmarc is sorely broken and all the amielorations have not good side
effects. so the question to me is whether we can move the pain closer
to the cause?

randy

[Randy Bush]

yoav,

It’s hard to move the pain in a predictable way. If I send you an
email message and it’s not delivered or gets mangled or goes in your
spam folder, who feels the pain? That depends on which of us needs the
email more.

my mail fu is not deep. but seems to me that we're talking about
mailing lists here, not tina telling me where to pick up €1k. so
move the pain to the users at yahoo (they're getting used to high
levels of pain) and let them move off yahoo or not play.

randy

[Theodore Ts'o]

It’s hard to move the pain in a predictable way. If I send you an
email message and it’s not delivered or gets mangled or goes in your
spam folder, who feels the pain? That depends on which of us needs
the email more.

The primary problem is that DMARC is fundamentally flawed, and was not
enacted using a standards process that respected all of the
stakeholders. As a result, it fundamentally becomes a matter of power
politics.

If there are a bunch of people who need to participate in a particular
mailing list --- say, IETF mailing list or the Linux Kernel
development lists --- more than they need to stick with a particular
mail provider, it becomes possible to say to them, "you want to
participate in our community"? Change mail providers.

In the cases where a mailing list community badly needs the Yahoo
users, Yahoo can dictate to the mailing list --- change your mailing
list software and inflict pain all off your mailing list users, or you
don't get access to our e-mail user community.

The group you want to feel the pain are the administrators who add
DMARC records, but other than spamming them with error reports,
there’s not much we can do. I don’t think the administrators at
Yahoo care too much whether their users are able to use IETF mailing
lists or not.
As a proxy we can “punish" those senders who have a DMARC record for their domain.
If we do nothing, their messages sometimes get lost. They have real
problems participating effectively in the IETF unless they switch to
using gmail or hotmail accounts like many of us have already
done. But that gives us pain as well because we’re missing messages
as long as they keep using their own accounts.

Yeah, it's the "sometimes mail gets lost" problem which is the main
issue. So it might actually be better to have the mailing list
software refuse to accept a mailing list posting from a domain with a
DMARC record, and it can be bounced back to the sender immediately
with a "sorry, try again using some e-mail address that does not have
DMARC support".

But again, doing this fundamentally is a game of power politics ---
just as DMARC being inflicted on the entire e-mail ecosystem was a
matter of power politics.

Cheers,

- Ted

If we apply the mitigations only to such accounts, we solve the
bounce issue, but then depending on the solutions we poison some of
the other participants’ email addresses, or we make the UI show
weird unhelpful things. Seems like everybody else gets the pain.

[Brian E Carpenter]

Post by Theodore Ts'o
Yeah, it's the "sometimes mail gets lost" problem which is the main
issue. So it might actually be better to have the mailing list
software refuse to accept a mailing list posting from a domain with a
DMARC record, and it can be bounced back to the sender immediately
with a "sorry, try again using some e-mail address that does not have
DMARC support".

I really think that this is the right answer for our community.

I don't. Accept the posting but also send a friendly warning seems to do less damage.

The DMARC policy is not to forward, and we should respect it.

Why does DMARC, which is a broken solution, deserve that much respect?

When ARC gets standardized, we should implement it.

Assuming it solves the problem, sure. But if it doesn't, the problem will
get much worse.

Brian

[Dave Crocker]

Post by Brian E Carpenter
I don't. Accept the posting but also send a friendly warning seems to do less damage.

The DMARC policy is not to forward, and we should respect it.

Why does DMARC, which is a broken solution, deserve that much respect?

When ARC gets standardized, we should implement it.

Assuming it solves the problem, sure. But if it doesn't, the problem will
get much worse.

Folks,

I am probably more frustrated about the expanded use of DMARC than most
folk, since I participated in creating the DMARC spec. For the
constrained scenario that motivated its design -- let's call it b2c --
it works pretty well. The expanded use -- let's call that c2c -- was
initially the ad hoc choice of one service provider, but it turns that
quite a few others also like it: there is a broad-based belief in that
community that aggressive requirements for author authentication will
alleviate many abuse problems. On the average, the downsides of that
view do not resonate in that community.

At any rate, the expanded use is what's causing the problems.

There are some realities that folk should note, when forming their
opinions about this problem:

1. There is nothing 'broken' about DMARC. There is a problem with a
particular use of it, but the mechanism, itself, works as designed.

2. Mailing lists have always been an odd architectural wrinkle. (I
commend RFC 5598 to anyone interested in the formalities.) An author
sends a message to the list address. The message gets /fully/
delivered; that is, it goes into the mailbox specified by the mailing
list address. The mailing list posts a new message. Whether the mailing
list retains all, or only almost all, of the original message, and even
all of the original envelope (except a new envelope addressee list) it
is a new message: And this is worth repeating: if the message undergoes
any changes beyond classic, minimal MTA addition of tracing information,
the message being sent is a new message. But the user-level experience
is of an author sending to a collection of end recipients. The users
don't really experience this as a re-posting. But the reason it's
important to understand that it is, indeed, a different message than
what the author posted is that mailing lists can and do do all sorts of
damage to the original. The essential challenge in trying to
accommodate a mechanism, like DMARC, that is designed to work within one
posting/delivery sequence, when there is more than one, is that we don't
currently know how to make it fully seamless.

3. The folk using DMARC are not violating any rules. Some are
causing problems for some of their users and some of the folk that their
users interact with, but that's different than saying they are violating
a protocol, or the like.

4. The folk using DMARC for c2c are not seeing a significant problem
from that use and they do report significant benefit. Sitting here in
the IETF, we might not like their assessment, but it's their business,
not yours or mine.

5. The IETF has no meaningful leverage over those service providers.
Any thoughts about what to do should keep that in mind.

6. Any thoughts about what to do should pay very close attention to
who has to take action, how considerable that action is, how long it is
likely to take for that action to happen, and what their incentives are
for taking that action. And remember that all of this has to satisfy
business concerns, not good-neighbor appeals.

7. The providers' affected users have no leverage on their
providers. None.

8. It is easy to tell those providers' users that they should go to
a different provider, but take a look around for choices of consumer
email providers: there are precious few choices on the Internet today.
And for the affected consumers, they need a free, well-run provider who
operates at scale.

9. ARC is expected to help this situation, but I suspect it won't be
as much help as anyone would like. At the least, it requires adoption
by both the mailing lists and the receiving MTAs, and that's a lot of
adoption to require.

d/

[Theodore Ts'o]

4. The folk using DMARC for c2c are not seeing a significant problem from
that use and they do report significant benefit. Sitting here in the IETF,
we might not like their assessment, but it's their business, not yours or
mine.

Right, the problem is not with c2c, where the affected mail might be
0.5%. But for d2d (developers to developers), it's much more serious.

5. The IETF has no meaningful leverage over those service providers. Any
thoughts about what to do should keep that in mind.

That's been clear. To the extent that though that some service
providers might want to have developers stay on their platform because
they might be powerful influencers, there might be *some* influence,
but it is admittedly very little.

7. The providers' affected users have no leverage on their providers.
None.

Well, it *might* be that Google might not appreciate headlines of the
form, "Linus Torvalds is leaving gmail because Gmail has become
fundamentally incompatible mailing lists", but it is again,
admittedly, very small.

8. It is easy to tell those providers' users that they should go to a
different provider, but take a look around for choices of consumer email
providers: there are precious few choices on the Internet today. And for
the affected consumers, they need a free, well-run provider who operates at
scale.

So what we might end up with, in the long run, is mailing lists will
only work with developers who switch to mail services such as, for
example, fastmail.fm. But there might not be mail services for
consumers that are compatible with mailing lists. That would be sad,
in that it would involve a partial fork of the Internet mail system,
one for Eloi and one for the Morlocks, using Neal Stephenson's analogy
from "In the Beginning Was the Command Line".

But again, as you have said (and I agree) we have no control over the
big mail providers. The only thing we have control over is any
mailing list servers we might happen to have administrative control
over, and what kind of pain we want to inflict on our particular
developer community (whether it is standards development or open
source development).

9. ARC is expected to help this situation, but I suspect it won't be as
much help as anyone would like. At the least, it requires adoption by both
the mailing lists and the receiving MTAs, and that's a lot of adoption to
require.

I have the same worry that ARC may not do as much to help as has been
hoped. Certainly not in the short term. That's because it won't just
be mailing list servers that will need to adopt ARC, but also mail
forwarding services such as those used by alum.mit.edu,
alumni.stanford.edu, linux.com, etc.

Basically, DMARC is a classic tragedy. It's playing out in a fairly
inevitable fashion, and there's nothing we can do to change the basis
of the tragedy; only how we react to it.

I suspect the best in the DMARC world where ARC turns out not to be
completely successful is a setting where mailing list recipients can
specify whether their mail service honors DMARC requests, and if it
does, *and* if the sender is one that has a DMARC policy, the From
field will have to get mangled, and if that screws up the recipient's
Yahoo or GMail contacts database, it will be up to that mail provider
to decide how to deal with it.

- Ted

[Ted Lemon]

The group you want to feel the pain are the administrators who add DMARC records, but other than spamming them with error reports, there’s not much we can do. I don’t think the administrators at Yahoo care too much whether their users are able to use IETF mailing lists or not.

Strictly speaking, what causes these providers pain is their customers leaving. However, given that Yahoo recently had a billion accounts hacked, I suspect that the IETF’s DMARC settings are not going to provide any comparatively strong motivation for leaving. And unfortunately one of the big DMARC sites is google.com <http://google.com/>; I really doubt anyone is going to quit their job at Google so they can participate in the IETF, and while we can certainly make it impossible for them to participate without using a different mail provider, the question is, is this the right way to spread the pain?

It’s certainly one of the options we discussed when this came up earlier.

BTW, speaking of obnoxious header munging, it would be a kindness, Randy Bush, if you would stop munging the headers on your replies to the IETF mailing list to say "IETF Disgust." I find this really offensive, and consequently I have to go in and re-edit the name back to "IETF Discussion List" to undo your vandalism. If the list so disgusts you, why not unsubscribe?

[Rich Kulawiec]

When it is more difficult to forge an email from a Yahoo user, it
is more convenient for the phisher to fake an address from some
other domain, and then Yahoo deals with fewer complaints.

I don't think it's difficult at all to forge an email from a Yahoo user.
And it'll even dutifully be marked as valid courtesy of Yahoo itself:

Yahoo Says 1 Billion User Accounts Were Hacked
http://www.nytimes.com/2016/12/14/technology/yahoo-hack.html

Please note that this is in addition to the earlier announcement
of 500M hacked accounts.

But hey, at least they got to do this:

Yahoo breaks every mailing list in the world including the IETF's
http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html

Yeah. That was worth it. Definitely.

---rsk

[Dave Crocker]

IETF discussion list on behalf of Michael Richardson

I'd guess that that would not improve things all that much. The best I
can suggest, to get the address book entry into a more reasonable place,
would be something like


Mailing list name (on behalf of author) <list-***@list-hostname>

eg,

IETF Discussion List (Author - Michael Richardson) <***@ietf.org>
This at least moves the variable information (author-related) into a
comment string...

d/

[Ted Lemon]

Post by Michael Richardson
since this will hijack "First Last" to point to the list, which is going to
cause all manner of email leaks. Maybe we can do better there.

The above format is already being used by at least one non-IETF mailing list.

Yes. And changing it to the mailing list also has problems in terms of readability. How about:

For First Last via Listname <***@example.com <mailto:***@example.com>>

This is brief, avoids the autocomplete fail, and gets the job done.

[John Levine]

I really think that this is the right answer for our community.
The DMARC policy is not to forward, and we should respect it.

How many IETF participants are we willing to lose over this
principled position?

R's,
John