Subject: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC

From: "Douglas E. Foster" <[email-masked]>
Date: Thu, 10 Sep 2020 18:50:41 -0400

Recently, I have become worried about the risks associated with using my regular email on this list, especially since everything goes into a long-term archive.   I am wishing that I had subscribed using a disposable account.       A general safety principle is to limit how and when one's email address is released, because once it is released, it cannot be taken back.     There are a number of potential problems associated with releasing actual email addresses onto a mailing list.
Address Harvesting

Any subscriber could potentially be harvesting email addresses from the list, and forwarding them to a spam source.   The spammer can tune his attacks more closely using other information gathered from list posts, including the list area of interest and other information disclosed in the course of list discussions.   If the harvesting is occurring, list participants and list operators have no method for identifying and closing the leak.

Badly Behaved Subscriber / Stalking

If a subscriber starts behaving badly toward another member, particularly in some form of cyber-stalking, the list operator can discharge the perpetrator from the list.   Unfortunately, the discharge action does not cut off access to the victim, because the victim's personal email address has already been disclosed.

Malicious Content filtering

A well-run list will implement a variety of techniques to prevent hostile content from being distributed.    However, once personal addresses have been disclosed, a bad actor can bypass those filters by sending the same prohibited traffic directly to any subscribers who have posted to the list.    Consequently, the burden of defense remains on the recipient organization, because the list defenses are too easily evaded.

List Spoofing

A well-run mailing list is likely to breed an elevated level of trust among the participants.   As a result, a successful spoof of the mailing list is that much more likely to be successful.    To the recipient, the DMARC list is primarily identified by the subject tag and the IETF footer.   The absence of attachments and the text-only format are additional clues.   These are arguably "trust indicators", and we have discussed that trust indicators have limited effectiveness.    For example, many MUAs will make URLs in a text-only message into a clickable link, blurring the visual distinctiveness between text and html messages.    An attacker could potentially replicate the subject tag and footer, apply a non-DMARC address, and send it from his own server.    The incoming email filter is unlikely to have the sophistication to recognize that this format is only supposed to come from IETF, so the message is likely to be allowed and the users are at risk of being duped.

The Alternative

All of these problems can be avoided if the subscriber is given an alias at enrollment, and the alias is used for all messages relayed on the subscriber's behalf.    For this list, my alias could be [email-masked].   Messages sent to an alias address must be submitted through the list operator, and the list manager should have logic to reject messages from a non-subscriber that are targeting a subscriber alias.

Because the personal email address is only known to the list operator, harvesting is impossible.   Any aliases that are harvested from the list will be unusable by a spammer operating outside the list.

For the same reason, if a misbehaving subscriber is ejected from the list, he immediately loses access to the people who were the victims of his actions.

List spoofing becomes less effective as well.   Legitimate list messages can be validated using DMARC with p=reject on the list domain.    Spoofed messages that reach the user will not have a From address in the list domain and will not follow the pattern of list aliases.

Overall, I conclude that mailing lists have much to benefit from intelligent use of DMARCv1 as previously specified.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 11 Sep 2020 08:53:58 +0200

On Fri 11/Sep/2020 00:50:41 +0200 Douglas E. Foster wrote:
> The Alternative
> 
> All of these problems can be avoided if the subscriber is given an alias at 
> enrollment, and the alias is used for all messages relayed on the subscriber's 
> behalf.    For this list, my alias could be [email-masked].   Messages 
> sent to an alias address must be submitted through the list operator, and the 
> list manager should have logic to reject messages from a non-subscriber that 
> are targeting a subscriber alias.
> 
> Because the personal email address is only known to the list operator, 
> harvesting is impossible.   Any aliases that are harvested from the list will 
> be unusable by a spammer operating outside the list.
> 
> For the same reason, if a misbehaving subscriber is ejected from the list, he 
> immediately loses access to the people who were the victims of his actions.
> 
> List spoofing becomes less effective as well.   Legitimate list messages can be 
> validated using DMARC with p=reject on the list domain.    Spoofed messages 
> that reach the user will not have a From address in the list domain and will 
> not follow the pattern of list aliases.
> 

That alternative to fosterd=[email-masked] (and 
original From: copied to Reply-To:) has some point.  I agree it should be 
mentioned among the set of solutions to the MLM problem that this WG is collecting.

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Fri, 11 Sep 2020 08:04:54 -0400

This proposal is way outside the scope of DMARC and the scope of the effort
for this group. Let's not try to boil the ocean.

Michael Hammer

On Thu, Sep 10, 2020 at 6:51 PM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> Recently, I have become worried about the risks associated with using my
> regular email on this list, especially since everything goes into a
> long-term archive.   I am wishing that I had subscribed using a disposable
> account.       A general safety principle is to limit how and when one's
> email address is released, because once it is released, it cannot be taken
> back.     There are a number of potential problems associated with
> releasing actual email addresses onto a mailing list.
>
> Address Harvesting
>
> Any subscriber could potentially be harvesting email addresses from the
> list, and forwarding them to a spam source.   The spammer can tune his
> attacks more closely using other information gathered from list posts,
> including the list area of interest and other information disclosed in the
> course of list discussions.   If the harvesting is occurring, list
> participants and list operators have no method for identifying and closing
> the leak.
>
> If a subscriber starts behaving badly toward another member, particularly
> in some form of cyber-stalking, the list operator can discharge the
> perpetrator from the list.   Unfortunately, the discharge action does not
> cut off access to the victim, because the victim's personal email address
> has already been disclosed.
>
> A well-run list will implement a variety of techniques to prevent hostile
> content from being distributed.    However, once personal addresses have
> been disclosed, a bad actor can bypass those filters by sending the same
> prohibited traffic directly to any subscribers who have posted to the list.
>    Consequently, the burden of defense remains on the recipient
> organization, because the list defenses are too easily evaded.
>
> List Spoofing
>
> A well-run mailing list is likely to breed an elevated level of trust
> among the participants.   As a result, a successful spoof of the mailing
> list is that much more likely to be successful.    To the recipient, the
> DMARC list is primarily identified by the subject tag and the IETF footer.
>   The absence of attachments and the text-only format are additional clues.
>   These are arguably "trust indicators", and we have discussed that trust
> indicators have limited effectiveness.    For example, many MUAs will make
> URLs in a text-only message into a clickable link, blurring the visual
> distinctiveness between text and html messages.    An attacker could
> potentially replicate the subject tag and footer, apply a non-DMARC
> address, and send it from his own server.    The incoming email filter is
> unlikely to have the sophistication to recognize that this format is only
> supposed to come from IETF, so the message is likely to be allowed and the
> users are at risk of being duped.
>
> The Alternative
>
> All of these problems can be avoided if the subscriber is given an alias
> at enrollment, and the alias is used for all messages relayed on the
> subscriber's behalf.    For this list, my alias could be
> [email-masked].   Messages sent to an alias address must be
> submitted through the list operator, and the list manager should have logic
> to reject messages from a non-subscriber that are targeting a subscriber
> alias.
>
> harvesting is impossible.   Any aliases that are harvested from the list
> will be unusable by a spammer operating outside the list.
>
> For the same reason, if a misbehaving subscriber is ejected from the list,
> he immediately loses access to the people who were the victims of his
> actions.
>
> List spoofing becomes less effective as well.   Legitimate list messages
> can be validated using DMARC with p=reject on the list domain.    Spoofed
> messages that reach the user will not have a From address in the list
> domain and will not follow the pattern of list aliases.
>
> Overall, I conclude that mailing lists have much to benefit from
> intelligent use of DMARCv1 as previously specified.
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 12 Sep 2020 12:07:00 -0400

This is very much in scope.

Sometime back, I argued that the difference between "user@domain" and "user=domain@listdomain" was a matter of mailing list user preferences, and user preferences were not a relevant concern of IETF.   I also noted that I had additional user preference topics that I could propose if we were going to head down that path.    I had two people oppose my comment, and no supporters.    One of those responses said that we could discuss additional mailing list user preference issues as long as they were registered with the chairs.   We have spent months talking about the equal sign in the From address.   I am introducing a user preference issue that has much greater importance than an equal sign.

Additionally, the chairs have told us that we must address RFC 7960, particularly as it affects mailing lists, or we will never reach standards track.   So there is no reason to "move on to other topics", because we have nowhere to go.

At the beginning of this discussion, mailing lists had these options:

- Reject subscriptions from domains that enforce DMARC.
- Ignore DMARC and accept the impact on delivery to some destinations.
- Rewrite the From address for the sole and distasteful purpose of accommodating DMARC.

Based on the premise that a mailing list's only real problem was DMARC-imposed delivery obstacles, we have spent months trying to find a way to give them what we want.   All of those approaches involved asking the entire Internet to implement new code and new configurations to please the mailing lists.   I believe the group has reluctantly concluded that none of those proposals have any useful potential.    We started from incompatible requirements:   DMARC prohibits impersonation that is not authorized by the domain owner, while mailing lists require impersonation on single-user authorization, an authorization given via unverifiable mechanisms.   So failure was not surprising.

But every solution is constrained by the way that the problem is framed, and this exercise has been constrained by the assumption that the equal sign was the whole problem.   Asking the larger question of "what other problems might be important to mailing list users?" allows us to rethink our solution strategies.    The alias-based private list approach which I have suggested addresses those other problems while incidentally making the DMARC problem unimportant.   The From address is still rewritten, but it is rewritten for reasons that are in the interest of the subscribers.   It is an OPTION for the mailing list, and therefore it complies with the charter requirement to give the mailing list operators a better option.

But the OPTION is not possible unless somebody provides MLM software that can implement that OPTION.   If the software vendors have not implemented this idea in the last 40 years, then an IETF specification might be the necessary incentive to create both demand and supply.

I will be loudly objecting if this option is excluded as out of scope, and then subsequent reviewers object to our product because we did not respond to RFC 7960.

To finish the RFC 7960 response, we also need to address technology gateways and Sieve engines.  Then we need to decide whether the responses go into the main specification or a standalone document.

Doug Foster

----------------------------------------

From: Dotzero <[email-masked]>
Sent: 9/11/20 8:05 AM
To: "Douglas E. Foster" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC

This proposal is way outside the scope of DMARC and the scope of the effort for this group. Let's not try to boil the ocean.

Michael Hammer

On Thu, Sep 10, 2020 at 6:51 PM Douglas E. Foster <fosterd=[email-masked]> wrote:

List Spoofing

The Alternative

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Sep 2020 18:11:57 -0700

> intelligent use of DMARCv1 as previously specified.
There's a large amount of stuff to tease out here because it covers a lot
of ground.  I'll tackle them in no particular order.  All of this is, once
again, as a participant only.

At first I thought this was a complaint about how the IETF runs its lists.
I was inclined to agree with Michael that all of this is off topic for this
working group, and instead propose that you reach out to the IETF Tools
Team to suggest they build the sort of aliasing mechanism you're talking
about or address your privacy concerns some other way.

I was also inclined to suggest that address harvesting from lists is
something I've never encountered in over a dozen years working with the
IETF, except for that one guy that time who got banned from participation
and so took it upon himself to clone the entire list membership and try to
start his own IETF.  But that happened only once and it was long ago, so
again I was going to say this is not a concern for us.

The argument in a subsequent message that we are compelled to respond to
everything we enumerated in RFC 7960 doesn't comport with the charter as I
read it, though I agree that we really shouldn't bother sending something
to the IESG that doesn't at least make a dent in the problems caused by
DMARC today.  (That is to say, perhaps, we don't need to deal with ALL of
RFC 7960.)

Then I finally got to your "The Alternative" section.  Now I'm torn.

A key advantage to DKIM, ARC, DMARC, etc., is that they operate at a layer
different from the composition and transport layers (between them,
really).  You can install a DKIM signer, and begin using SPF and/or DMARC,
without MLMs knowing they're even there.  That incremental nature has been
a key to their relative successes and easy deployment.

To the contrary, what you're proposing is, on its face, a fundamental
change in how MLMs operate.  It requires MLMs to select an alias that has a
domain name identical to the domain name under which it operates at the
time you register, rewrite your messages through the list with that From
field (and perhaps Reply-To field), and install an alias so that any
private direct replies to that alias are relayed to you without
modification (lest they fail authentication and thus become part of the
problem).  Your own mail server would need to be sure to accept that
alias.  If we expect MLMs to do this, it would take weeks or months to
specify, and years to get implemented and widely deployed.

Then I started thinking about implementation.  It might be possible, using
something like the milter API (which sendmail and posfix have, among
others, and through which all of my implementations have been done), to
write a plugin that implements all of these things.  Since milter
intercepts and modifies things at the SMTP layer, it could handle the
rewrites in both directions; software downstream of that would never even
know the changes were made.  Again, it could be totally incremental; no
change to MLMs or other protocol modules would be needed.

If we're willing to argue that DMARC implementations should at least
consider Sender, which seems (and this is NOT an official consensus
reading) to have support to at least try, then we're willing to accept that
implementation changes are on the table.  If so, I suggest this might also
be worth consideration.  I might even give it a try myself, and/or
contribute to a draft describing it, if there's no holes shot in the idea.

There are those who assert that this shouldn't be necessary; it's only
necessary because DMARC.  I firmly agree.  But perhaps this is a way out of
this hole we're in.  So now it seems interesting.  What am I missing?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Sep 2020 18:43:07 -0700

While I'm thinking of it:

>> to reject messages from a non-subscriber that are targeting a subscriber
How does this compare to what's done here already (if enabled)?

https://wiki.list.org/DEV/DMARC

-MSK

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2020 22:58:42 -0400

In article <CAL0qLwZEDNT+LZDMrzecSuTD794jn0CoXRA5FG=[email-masked]> you write:
>-=-=-=-=-=-
>> On Thu, Sep 10, 2020 at 3:51 PM Douglas E. Foster <fosterd=[email-masked]> wrote:
>>> [email-masked]. ...

>https://wiki.list.org/DEV/DMARC

As far as I know, no widely available list software does that.

Several years ago I came up with a per user rewrite hack for DMARC-ed
addresses so a From header like:

 [email-masked]

turns into:

 [email-masked]

Henrik did something similar for the IETF lists:

 marissa=[email-masked]

(You can see that in the copy of Doug's address above.)

In both cases we set up a temporary forward from the rewritten address
to the real one. This works pretty well. The problem is that it
requires that the list software can stick its fingers into the MTA and
manage aliases on the fly which isn't usually the case.

By the way, all of the anti-DMARC hacks I'm aware of are listed here:

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

Look at the history, you'll see most of them have been there at least since 2016.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Joseph Brennan <[email-masked]>
Date: Tue, 15 Sep 2020 09:34:11 -0400

It must be unusual for an authentication protocol to specify in the
RFC how to work around its own authentication mechanism.

"Domain administrators must not apply dmarc authentication to domains
from which end users send mail that may be re-sent via lists or
automatic forwarding."  -- done. Then dmarc will be simple and
reliable, and bank statements and similar messages are protected as
intended. Building in a standard workaround significantly weakens the
whole concept, doesn't it?

-- 
Joseph Brennan
Lead, Email and Systems Applications
Columbia University Information Technology

---

From: "John Levine" <[email-masked]>
Date: 15 Sep 2020 15:55:10 -0000

In article <CAMSGcLDKRMbJ_30jZdKE_6hkKaktwBxU6_E=E=[email-masked]>,
>whole concept, doesn't it?

Unfortunately, we have ample evidence that domain operators will
ignore that advice.

According to someone who was in the room when Yahoo flipped the
switch, the person in charge said words to the effect that I know this
will screw up everyone's mailing lists and I don't care.

R's,
John

---

From: Joseph Brennan <[email-masked]>
Date: Tue, 15 Sep 2020 12:02:01 -0400

> will screw up everyone's mailing lists and I don't care.
The irony is, the result being to diminish the effectiveness of dmarc for
everybody.

Joseph Brennan

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 16 Sep 2020 09:23:24 +0200

On Tue 15/Sep/2020 18:02:01 +0200 Joseph Brennan wrote:
>> In article <CAMSGcLDKRMbJ_30jZdKE_6hkKaktwBxU6_E=[email-masked]>, Joseph Brennan  <[email-masked]> wrote:

On the other hand, it was a tremendous push for DMARC adoption.

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Wed, 16 Sep 2020 10:46:09 -0400

> Columbia University Information Technology
Can you support your assertion with data? There was zero change
post-yahoo/AOL implementation vs pre-yahoo/AOL implementation for the
organization I worked for at the time.

Michael Hammer

---

From: Joseph Brennan <[email-masked]>
Date: Wed, 16 Sep 2020 11:03:15 -0400

What I mean is that mailing list software developers were obliged to
find a variety of ways to evade dmarc enforcement, for the sake of
delivering legitimate mail, and mailbox server developers learned to
allow mangled mail for the same reason. Widespread acceptance of email
that evades an authentication method diminishes its effectiveness.

On Wed, Sep 16, 2020 at 10:46 AM Dotzero <[email-masked]> wrote:
>
>
>
> On Tue, Sep 15, 2020 at 12:02 PM Joseph Brennan <[email-masked]> wrote:
>>
>>
>>
>> The irony is, the result being to diminish the effectiveness of dmarc for everybody.
>>
>>
>> Joseph Brennan
> Can you support your assertion with data? There was zero change post-yahoo/AOL implementation vs pre-yahoo/AOL implementation for the organization I worked for at the time.
>
> Michael Hammer

---

From: "Doug Foster" <[email-masked]>
Date: Wed, 16 Sep 2020 13:15:48 -0400

I cannot agree with your logic.

Assuming that you want your email gateway to accept this message, it is
because the list and the organization behind it have a positive reputation
with you.   Your trust in this message is not because you have a prior
relationship or reputation data each individual list member.   Indeed, we do
not even know the complete list of members from whom reputation data would
need to be assembled.

DMARC requires one of two actions:
- either the list confirms its identity to your email gateway by altering
the From Address, or 
- your email gateway is configured to confirm the list identity using other
parameters such as the an SPF-verified SMTP From Address.   

There is no evasion of identity.   By either method, there is formal
verification of identity where there was previously no verification.

I understand the disruption when From-Rewrite was not available and AOL was
not willing to create exceptions.   
I understand the perceived inconvenience of a rewritten From address.   
But I see the network of trust only enhanced, not diminished, by the DMARC
mechanism.

Doug Foster

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Joseph Brennan
Sent: Wednesday, September 16, 2020 11:03 AM
To: IETF DMARC WG
Subject: Re: [dmarc-ietf] Issue submission - Mailing list security and
potential solutions using DMARC

What I mean is that mailing list software developers were obliged to find a
variety of ways to evade dmarc enforcement, for the sake of delivering
legitimate mail, and mailbox server developers learned to allow mangled mail
for the same reason. Widespread acceptance of email that evades an
authentication method diminishes its effectiveness.

wrote:
>>> In article 
>>> <CAMSGcLDKRMbJ_30jZdKE_6hkKaktwBxU6_E=E=[email-masked]>
>>> , Joseph Brennan  <[email-masked]> wrote:
>>> >"Domain administrators must not apply dmarc authentication to 
>>> >domains from which end users send mail that may be re-sent via 
>>> >lists or automatic forwarding."  -- done. Then dmarc will be simple 
>>> >and reliable, and bank statements and similar messages are 
>>> >protected as intended. Building in a standard workaround 
>>> >significantly weakens the whole concept, doesn't it?
>>>
>>> switch, the person in charge said words to the effect that I know 
>>> this will screw up everyone's mailing lists and I don't care.
>>>
>>
everybody.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 29 Sep 2020 19:09:14 +0200

On Sun 13/Sep/2020 03:43:07 +0200 Murray S. Kucherawy wrote:
> On Sat, Sep 12, 2020 at 6:11 PM Murray S. Kucherawy wrote:
>> On Thu, Sep 10, 2020 at 3:51 PM Douglas E. Foster wrote:
>>
>>> The Alternative
>>>

Mailman has an anonymous_list[*] configuration variable that, if enabled, removes or replaces the From:, Sender:, and Reply-To: fields of any message posted to the list.  It can be consider an (overkill) alternative to From: munging.

Best
Ale
-- 

[*] https://mailman.readthedocs.io/en/latest/src/mailman/handlers/docs/cleanse.html#anonymous-lists