Re: [dmarc-ietf] THIS IS ABUSE (it might be)
On Wed, 12 Apr 2023, Eric D. Williams wrote: No, it's a DMARC problem. DKIM didn't cause any problems for mailing lists ... mailing lists the real answer is ARC not DMARC, that's what I'm saying. It's a failure with DKIM signature invalidation as a result of relaying via mailing lists. My mailing lists put their own DKIM signature on the outgoing mail, and the DKIN spec says to ignore signatures that don't validate, so as far as DKIM is concerned, that mail is fully authenticated. As RFC 6376 says: INFORMATIVE RATIONALE: The signing identity specified by a DKIM signature is not required to match an address in any particular header field because of the broad methods of interpretation by recipient mail systems, including MUAs. It's only DMARC that adds a new and in this case unfortunate rule that requires a DKIM signature that matches the domain in the From header. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
On Mon, Apr 10, 2023 at 9:30 AM John R Levine wrote: > On Mon, 10 Apr 2023, Alessandro Vesely wrote: > > On Sat 08/Apr/2023 15:59:30 +0200 John Levine wrote: > >> It appears that Eric D. Williams said: > >>> -=-=-=-=-=- > >>> > >>> I think the reliance upon list operators is properly placed on that > role. > >>> It's not a DMARC problem, it's a DKIM problem, I think. > >> > >> No, it's a DMARC problem. DKIM didn't cause any problems for mailing > lists > >> (ignoring ill-advised and never used ADSP) until DMARC was layered on > top > >> of it, and AOL and Yahoo abused it to foist the support costs on the > rest > >> of the world after they let crooks steal their users' address books. > > > I disagree. Despite the failure of adoption of ADSP, which is not a new thing by any stretch - we've seen that before, if we are talking about mailing lists the real answer is ARC not DMARC, that's what I'm saying. It's a failure with DKIM signature invalidation as a result of relaying via mailing lists. > > That's how it happened. Can we now accept their push? After so many > email > > addresses became public, how about accepting that email addresses being > > public doesn't have to imply that anyone can impersonate them? > > No, that's not what happened. People had been faking AOL and Yahoo > addresses forever and the providers dealt with it. The problem was that > spammers used the stolen address books to send spam from the addresses of > people the recipients knew, and they were flooded with complaints "why are > my friends spamming me." It's entirely the fault of those providers' > poor security. > > Re impersonating, until DMARC can tell the difference between > impersonation and the kinds of ordinary forwarding we've been doing since > the 1980s, nope. > Now, perhaps I misunderstood the original thread, so I'll cop to that, but I will assert that although DMARC can certainly provide some legitimacy assurances it certainly does have a gap with impersonation, particularly manifested with maillist relaying in many common configurations. > > R's, > John > /r/ -e -- Eric D. Williams PGP Public Key http://new.infobro.com/KeyServ/EricDWilliams.asc Finger Print: 1055 8AED 9783 2378 73EF 7B19 0544 A590 FF65 B789 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
On Mon, 10 Apr 2023, Alessandro Vesely wrote: On Sat 08/Apr/2023 15:59:30 +0200 John Levine wrote: It appears that Eric D. Williams said: -=-=-=-=-=- I think the reliance upon list operators is properly placed on that role. It's not a DMARC problem, it's a DKIM problem, I think. No, it's a DMARC problem. DKIM didn't cause any problems for mailing lists (ignoring ill-advised and never used ADSP) until DMARC was layered on top of it, and AOL and Yahoo abused it to foist the support costs on the rest of the world after they let crooks steal their users' address books. That's how it happened. Can we now accept their push? After so many email addresses became public, how about accepting that email addresses being public doesn't have to imply that anyone can impersonate them? No, that's not what happened. People had been faking AOL and Yahoo addresses forever and the providers dealt with it. The problem was that spammers used the stolen address books to send spam from the addresses of people the recipients knew, and they were flooded with complaints "why are my friends spamming me." It's entirely the fault of those providers' poor security. Re impersonating, until DMARC can tell the difference between impersonation and the kinds of ordinary forwarding we've been doing since the 1980s, nope. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
On Sat 08/Apr/2023 15:59:30 +0200 John Levine wrote: It appears that Eric D. Williams said: -=-=-=-=-=- I think the reliance upon list operators is properly placed on that role. It's not a DMARC problem, it's a DKIM problem, I think. No, it's a DMARC problem. DKIM didn't cause any problems for mailing lists (ignoring ill-advised and never used ADSP) until DMARC was layered on top of it, and AOL and Yahoo abused it to foist the support costs on the rest of the world after they let crooks steal their users' address books. That's how it happened. Can we now accept their push? After so many email addresses became public, how about accepting that email addresses being public doesn't have to imply that anyone can impersonate them? Their move forced DMARC into a role that it wasn't design to play, but perhaps it's not so bad after all...? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
It appears that Eric D. Williams said: >-=-=-=-=-=- > >I think the reliance upon list operators is properly placed on that role. >It's not a DMARC problem, it's a DKIM problem, I think. No, it's a DMARC problem. DKIM didn't cause any problems for mailing lists (ignoring ill-advised and never used ADSP) until DMARC was layered on top of it, and AOL and Yahoo abused it to foist the support costs on the rest of the world after they let crooks steal their users' address books. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
I think you have gotten yourself side tracked. The problem with DMARC and mailing lists is that receivers doing DMARC checks can't (absent a list of mailing lists) reliably distinguish DMARC fail due to normal mailing list processing and DMARC fail due to abusive behavior. To mitigate this issue, a number of mailing lists (this one included) have taken measures so that list mail will pass DMARC checks at the receiver. These measures have been a net negative for mailing list usability. Mailing list managers can (and probably should) include DMARC in how they manage abusive postings to their lists, but that's not any kind of a special case for DMARC. Scott K On Saturday, April 8, 2023 7:16:05 AM EDT Alessandro Vesely wrote: > Identifier rewrite affects the leg from MLM to subscriber. Email security > in the leg from poster to MLM is completely ignored by the draft, although > MLMs constitutes a major concern. > > We joyfully rely on traditional techniques to counter potential attacks, > estimating that there is no reason to adopt cryptographic stuff to secure > email. > > Water we talking about? > > > Best > Ale > > On Sat 08/Apr/2023 01:54:21 +0200 Douglas Foster wrote: > > Scott's approach solves our longest-running argument, but not in the way > > that I expected.We can embrace his approach with a single Security > > Consideration to this effect: > > > > "Mailing lists are frequently characterized by operating practices that > > depend on security through obscurity rather than Sender Authentication. > > > > Identifier rewrite may be used as necessary to evade detection of weak > > > > Sender Authentication practices. While exceptions doubtless exist, > > determining the trustworthiness of messages from any particular mailing > > list is difficult, and beyond the scope of this document. Participation > > risk should be taken into account when subscribing to a mailing list and > > accepting incoming messages from a list." > > > > However, this type of truthfulness does not seem to be what the charter > > document intended. > > > > Doug Foster > > > > On Fri, Apr 7, 2023 at 4:24 PM Scott Kitterman wrote: > >> On April 7, 2023 6:43:33 PM UTC, Alessandro Vesely wrote: > >> >It is going to be problematic to kick off someone who impersonates > >> > >> different users. What do you do, block IP numbers? > >> > >> >We keep on saying that mailing list have worked this way for decades. > >> > >> Sure. And email in general has been working for decades before the need > >> to > >> use authentication arose. So we can bet that people using MLs is highly > >> selected and well behaved... but is that true? Wouldn't a jester be able > >> to completely disrupt our work by heavily repeating impersonations to the > >> point that we'll be forced to restrict to Github tools to discuss our > >> drafts? I wouldn't bet... > >> > >> >Some time ago I proposed a p=mlm-validate[*] telling receivers to reject > >> > >> on failure only if they are a mailing list or similar forwarder. I > >> thought > >> that would cause minimal disruption since such kind of posts most of the > >> times reach destination in one hop —akin to transactional stuff— and a > >> poster who gets a bounce can quickly retry. Such kind of tool would > >> eliminate impersonation chances. > >> > >> >An obvious truth is that we cannot publish a successful protocol if we > >> > >> ourselves see no reason to make any use of it. > >> > >> To the extent managing mailing list subscriber abuse is a problem, it's > >> not a DMARC problem. > >> > >> The IETF has had problems with sock puppets before and managed to address > >> them. > >> > >> Scott K > >> > >> ___ > >> dmarc mailing list > >> dmarc@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmarc > > > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
Identifier rewrite affects the leg from MLM to subscriber. Email security in the leg from poster to MLM is completely ignored by the draft, although MLMs constitutes a major concern. We joyfully rely on traditional techniques to counter potential attacks, estimating that there is no reason to adopt cryptographic stuff to secure email. Water we talking about? Best Ale On Sat 08/Apr/2023 01:54:21 +0200 Douglas Foster wrote: Scott's approach solves our longest-running argument, but not in the way that I expected.We can embrace his approach with a single Security Consideration to this effect: "Mailing lists are frequently characterized by operating practices that depend on security through obscurity rather than Sender Authentication. Identifier rewrite may be used as necessary to evade detection of weak Sender Authentication practices. While exceptions doubtless exist, determining the trustworthiness of messages from any particular mailing list is difficult, and beyond the scope of this document. Participation risk should be taken into account when subscribing to a mailing list and accepting incoming messages from a list." However, this type of truthfulness does not seem to be what the charter document intended. Doug Foster On Fri, Apr 7, 2023 at 4:24 PM Scott Kitterman wrote: On April 7, 2023 6:43:33 PM UTC, Alessandro Vesely wrote: >It is going to be problematic to kick off someone who impersonates different users. What do you do, block IP numbers? > >We keep on saying that mailing list have worked this way for decades. Sure. And email in general has been working for decades before the need to use authentication arose. So we can bet that people using MLs is highly selected and well behaved... but is that true? Wouldn't a jester be able to completely disrupt our work by heavily repeating impersonations to the point that we'll be forced to restrict to Github tools to discuss our drafts? I wouldn't bet... > >Some time ago I proposed a p=mlm-validate[*] telling receivers to reject on failure only if they are a mailing list or similar forwarder. I thought that would cause minimal disruption since such kind of posts most of the times reach destination in one hop —akin to transactional stuff— and a poster who gets a bounce can quickly retry. Such kind of tool would eliminate impersonation chances. > >An obvious truth is that we cannot publish a successful protocol if we ourselves see no reason to make any use of it. To the extent managing mailing list subscriber abuse is a problem, it's not a DMARC problem. The IETF has had problems with sock puppets before and managed to address them. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
Scott's approach solves our longest-running argument, but not in the way that I expected.We can embrace his approach with a single Security Consideration to this effect: "Mailing lists are frequently characterized by operating practices that depend on security through obscurity rather than Sender Authentication. Identifier rewrite may be used as necessary to evade detection of weak Sender Authentication practices. While exceptions doubtless exist, determining the trustworthiness of messages from any particular mailing list is difficult, and beyond the scope of this document. Participation risk should be taken into account when subscribing to a mailing list and accepting incoming messages from a list." However, this type of truthfulness does not seem to be what the charter document intended. Doug Foster On Fri, Apr 7, 2023 at 4:24 PM Scott Kitterman wrote: > > > On April 7, 2023 6:43:33 PM UTC, Alessandro Vesely wrote: > >It is going to be problematic to kick off someone who impersonates > different users. What do you do, block IP numbers? > > > >We keep on saying that mailing list have worked this way for decades. > Sure. And email in general has been working for decades before the need to > use authentication arose. So we can bet that people using MLs is highly > selected and well behaved... but is that true? Wouldn't a jester be able > to completely disrupt our work by heavily repeating impersonations to the > point that we'll be forced to restrict to Github tools to discuss our > drafts? I wouldn't bet... > > > >Some time ago I proposed a p=mlm-validate[*] telling receivers to reject > on failure only if they are a mailing list or similar forwarder. I thought > that would cause minimal disruption since such kind of posts most of the > times reach destination in one hop —akin to transactional stuff— and a > poster who gets a bounce can quickly retry. Such kind of tool would > eliminate impersonation chances. > > > >An obvious truth is that we cannot publish a successful protocol if we > ourselves see no reason to make any use of it. > > To the extent managing mailing list subscriber abuse is a problem, it's > not a DMARC problem. > > The IETF has had problems with sock puppets before and managed to address > them. > > Scott K > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
I think the reliance upon list operators is properly placed on that role. It's not a DMARC problem, it's a DKIM problem, I think. Eric D. Williams PGP Public Key http://new.infobro.com/KeyServ/EricDWilliams.asc Finger Print: 1055 8AED 9783 2378 73EF 7B19 0544 A590 FF65 B789 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
On April 7, 2023 6:43:33 PM UTC, Alessandro Vesely wrote: >It is going to be problematic to kick off someone who impersonates different >users. What do you do, block IP numbers? > >We keep on saying that mailing list have worked this way for decades. Sure. >And email in general has been working for decades before the need to use >authentication arose. So we can bet that people using MLs is highly selected >and well behaved... but is that true? Wouldn't a jester be able to completely >disrupt our work by heavily repeating impersonations to the point that we'll >be forced to restrict to Github tools to discuss our drafts? I wouldn't bet... > >Some time ago I proposed a p=mlm-validate[*] telling receivers to reject on >failure only if they are a mailing list or similar forwarder. I thought that >would cause minimal disruption since such kind of posts most of the times >reach destination in one hop —akin to transactional stuff— and a poster who >gets a bounce can quickly retry. Such kind of tool would eliminate >impersonation chances. > >An obvious truth is that we cannot publish a successful protocol if we >ourselves see no reason to make any use of it. To the extent managing mailing list subscriber abuse is a problem, it's not a DMARC problem. The IETF has had problems with sock puppets before and managed to address them. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
It is going to be problematic to kick off someone who impersonates different users. What do you do, block IP numbers? We keep on saying that mailing list have worked this way for decades. Sure. And email in general has been working for decades before the need to use authentication arose. So we can bet that people using MLs is highly selected and well behaved... but is that true? Wouldn't a jester be able to completely disrupt our work by heavily repeating impersonations to the point that we'll be forced to restrict to Github tools to discuss our drafts? I wouldn't bet... Some time ago I proposed a p=mlm-validate[*] telling receivers to reject on failure only if they are a mailing list or similar forwarder. I thought that would cause minimal disruption since such kind of posts most of the times reach destination in one hop —akin to transactional stuff— and a poster who gets a bounce can quickly retry. Such kind of tool would eliminate impersonation chances. An obvious truth is that we cannot publish a successful protocol if we ourselves see no reason to make any use of it. Best Ale [*] https://mailarchive.ietf.org/arch/msg/dmarc/QL8fi1YHtFz0Z1qxcJyGmpR_Q-g On Thu 06/Apr/2023 22:39:55 +0200 Scott Kitterman wrote: This is not a significant problem in my experience. To the extent this is a problem I think it's primarily a list owner problem, not an Internet protocol problem. Not kidding that if I ran this list I'd probably kick you off the list for awhile to give you a chance to ponder the error of your ways. Don't do this. Scott K On April 6, 2023 8:53:46 PM UTC, someone wrote: I hope Alex won't get offended by this innocent DMARC test. Are we sure that it is all right for mailing lists to allow spoofs and impersonation? I don't think Comcast has p=reject to safeguard Alex's contribution to this list, but what if he can't stand being impersonated? What else is he supposed to do besides setting p=reject? THIS LIST TAKES ALL OF THE BAD OF DMARC, NONE OF THE GOOD. Best Ale ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
