Bounce action notifications - NANOG mailing list changes yahoo.com users

Hello Colleagues,

The NANOG mailing list had a discussion several months back regarding
changes that Yahoo made to their DMARC settings. Over the past day,
the NANOG mailing list has received a number of posts from yahoo.com
mail users. This triggered bounce action on nearly 300 NANOG mailing
list subscriptions as the receiving mail systems were complying with the
DMARC settings that Yahoo has set. All subscriptions that had been
disabled have been re-enabled at this time.

To correct this moving forward, selective rewriting of the from header
has been recommended, but requires an upgrade to the Mailman software.
While we would like to have no impact to our subscribers, the selective
rewrite and upgrade are not immediately available. An expeditious
implementation of the upgrade is being worked on.

As a temporary measure, the NANOG mailing list will be holding posts
that come from yahoo.com users. We are not wishing to restrict posting,
however posts from yahoo.com accounts are causing operational issues
with the mailing list.

Once a final timeline for the upgrade procedure and selective rewrite
are available, we will let you know.

Best Regards,
Andrew Koch
NANOG Communications Committee

To correct this moving forward, selective rewriting of the from header
has been recommended, but requires an upgrade to the Mailman software.

If the admins have settled on a best practice, it could help other
Mailman operators like myself. Two questions spring to mind:

1. With the planned method, how will reply behavior be affected?

2. Will this be an upgrade to 2.1.16, or a pre-release version of
2.1.18, or something else?

From DEV/DMARC - Mailman Wiki :

In 2.1 16 a from_is_list feature was implemented which if enabled by a
site configuration option would offer a list admin the ability to
either:

* Rewrite (Munge) the From: header with the posters name 'via the
list' and the list's address and merge the poster's address into

* Wrap the message as a message/rfc822 sub-part in a MIME format outer
message with From: and Reply-To: as above.

Implemented now for release in 2.1.18 are the following:

* The from_is_list feature from 2.1.16 is always available.

* There are new settings in Privacy options - Sender filters:

** dmarc_moderaction_action is a five valued setting with values

*** Accept - accept the post without rewriting From: or wrapping the message
*** Munge From - rewrite the From: and Reply-To: as in from_is_list
*** Wrap Message - wrap the message as in from_is_list
*** Reject - reject the post
*** Discard - Discard the post

** dmarc_moderaction_notice is a custom reject message to replace the
default Reject message.

* The above options other than Accept override the from_is_list
setting for messages whose original From: domain publishes a DMARC
policy of p=reject or p=quarantine. A per-list option is available to
limit this to just p=reject or to apply it to either p=reject or
p=quarantine. If the option is Accept, the from_is_list setting
applies.

* There is a site option to set the default for
dmarc_moderaction_action and list admins may not set the action to a
setting which is above the site default in the above list. E.g., if
the site default is Reject, list admins can only set Reject or
Discard; if the site default is Munge From, list admins can select
anything but Accept.

Royce

FYI, I migrated to Mailman 2.1.18-1 shortly after Yahoo decided to break
every mailing list on the Internet for no good reason. (It certainly
has done nothing to mitigate the ongoing flow of spam, phishing and
other abuse coming from Yahoo, which continues pretty much as it has
for many years.)

I can't recommend it, and I don't say that to denigrate the work of
the Mailman developers, which has been (as usual) outstanding, even
under duress. The problems I've encountered are that the changes
in headers are confusing to lot of subscribers and I still see [some]
rejections based on DMARC failures despite using the appropriate settings
(supported by dnspython-1.11.1, which is required for 2.1.18-1 to work).
I suppose I'd describe it in operational practice as "rickety" or
"unreliable", at best.

Yahoo has inflicted this on themselves by making an abrupt, ill-advised,
unilateral decision without consulting with their peers and considering
the large-scale implications of said decision. I don't see a good reason
for NANOG's mailing list admins to go through a *lot* of work (including
what will likely be user confusion/questions, if my experience is any
guide) in order to accomodate this. I think a better approach would
be to recommend that mailing list participants who want to actually
participate should utilize a mail service appropriate for the purpose.

---rsk

a better approach would be to recommend that mailing list participants
who want to actually participate should utilize a mail service
appropriate for the purpose.

support

to be fair, this means EITHER one which does not DMARC mark messages
OR one which disrespects DMARC. Right?

-chris

a better approach would be to recommend that mailing list participants
who want to actually participate should utilize a mail service
appropriate for the purpose.

support

to be fair, this means EITHER one which does not DMARC mark messages
OR one which disrespects DMARC. Right?

to one which respects both mailing list subscribers and admins

randy

a better approach would be to recommend that mailing list participants
who want to actually participate should utilize a mail service
appropriate for the purpose.

support

+1

to be fair, this means EITHER one which does not DMARC mark messages
OR one which disrespects DMARC. Right?

One which does not publish DMARC p=reject.

If any recipient honors published DMARC records then every
participant using a domain that publishes DMARC p=reject will
break things.

If your domain publishes p=reject it should not have any users
that participate in mailing lists.

Cheers,
  Steve

What surprises me is that the dmarc crowd (nee ADSP) surely knows all about this as it's been
known for going on 10 years that this is what would happen. isn't one of the wg chairs a Y!'er too?

Mike

Call it triage. When a minuscule amount of mailing list traffic is weighed
against huge volumes of forged spam and phish...

Like many, I was pretty unhappy (and busy) with the unilateral changes
made by Yahoo and AOL. But this understandable stance may change.
Neither of these domains is known for being heavily saturated with
geeks. If Gmail started using p=reject, that might shake the tree a
little more.

But other than providing more warning, what would have been a better
way to start eliminating forged senders? Everything I've read
indicates that both Yahoo and AOL did this with eyes wide open.

Assuming that eliminating forged senders is the end goal, maybe
forcing the issue was the only way to move forward? What other theory
about their motivation makes sense?

Royce

Most of the DMARC backers offer one or more services that compete with
traditional mailinglists.

-Jim P.

If your domain publishes p=reject it should not have any users
that participate in mailing lists.

Like many, I was pretty unhappy (and busy) with the unilateral changes
made by Yahoo and AOL. But this understandable stance may change.
Neither of these domains is known for being heavily saturated with
geeks. If Gmail started using p=reject, that might shake the tree a
little more.

But other than providing more warning, what would have been a better
way to start eliminating forged senders? Everything I've read
indicates that both Yahoo and AOL did this with eyes wide open.

Assuming that eliminating forged senders is the end goal, maybe
forcing the issue was the only way to move forward? What other theory
about their motivation makes sense?

I'm fairly sure that their motivation wasn't anything like that clearly
thought through - but their motivation doesn't really matter.

Mailing list operators are stuck in the middle, and they have three
reasonable choices. One is to rework their mail systems to selectively
(or unselectively) replace the From: field. That's a lot of work, and
makes the mailing list less usable for all users.

(There's discussion in the DMARC IETF groups about redefining
5322 so as to put what is currently in the Sender: field into the
the user, to contain what is currently in the From: field).

Another is to be very, very careful about not breaking DKIM
signatures on list mail. That's difficult because the
things you have to do or not do change depending on how the
submitted mail is signed (and Yahoo in particular have made
some signing choices that make it particularly hard).

The third option is to reject submissions from domains that publish
p=reject (or, probably, p=quarantine), pushing the customer support
costs onto those who are publishing p=reject records for users
that participate in mailing lists.

Cheers,
  Steve

But other than providing more warning, what would have been a better
way to start eliminating forged senders? Everything I've read
indicates that both Yahoo and AOL did this with eyes wide open.

A good move would have been to improve their security so that AOL and
Yahoo didn't have massive thefts of their customers' address book data
(two separate times for one of them.) This meant that their users
were getting large amounts of spam "from" people they knew, sent from
outside of their networks.

AOL and Yahoo made narrowly rational decisions to push the cost of
their security failures onto the rest of the world. I understand why
they did it, but that doesn't mean we have to like it, or to cut them
any slack about it.

R's,
John

Triage as an abuse mitigation tactic is fine. But where that triage
needs to be applied, and where it can be most effective, is at the *source*
of the abuse. Which is not here or any other of the myriad mailing lists
where most of the heavy lifting is done WRT to networking, security,
software and all the other things that make the 'net work.

Yahoo itself is a major source of abuse, it has been for many years, and
there is absolutely no visible sign that they've done anything about it,
that they're doing anything about it, or that they intend to do anything
about it. Spam/phishes show up all day, every day, and yes they really
*are* from Yahoo, so there's not much need at the moment for anyone
to bother forging an @yahoo address. (That's kind of like creating an
exquisitely detailed fake replica of a Mercedes-Benz sedan and then slapping
a Yugo logo on it. Why would any forger good enough to pull that off
devalue their own effort by deliberately associating it with junk?)

So please, let's not pretend that Yahoo has suddenly had a come-to-Jebus
moment and is interested in stopping abuse. They're not. If they were,
they would have invested resources into their own operation many years ago,
they would deal with their abuse@ email promptly and professionally,
and Yahoo-sourced abuse would be an isolated/transient problem, rather
than a systemic/persistent one. What they *are* interested in, given
the floundering state of their company, is anything they can do to
retain users -- and screwing up others' mailing lists (for which the
operators are being blamed, through no fault of their own) in favor of
their own offerings is one way to achieve that.

---rsk