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 protected]> Sent: 9/11/20 8:05 AM To: "Douglas E. Foster" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> 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 <[email protected]> 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. 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 protected]. 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. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
