On Thu, Sep 10, 2020 at 3:51 PM Douglas E. Foster <fosterd= [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. > 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
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
