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

["Douglas E. Foster" <[e-mail]>]

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 [e-mail].   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.