Re: [Ietf-dkim] replay clues
On 2/12/23 1:47 PM, Murray S. Kucherawy wrote: On Sun, Feb 12, 2023 at 11:19 AM Michael Thomas wrote: It's certainly possible to collect data that might correlate something like "Subject signed vs. not signed" with a spam score, and that could feed in to a best practices document. I don't know who might be up for investing the time into such a survey, however. OpenDKIM used to collect such summaries from volunteer participants; I can see if the data sitting around in those tables had enough information for such a survey, but it almost certainly won't be current data. What I'm starting to think is that if we can collect that into the problem statement that may well be all we need to do if we determine that there is no there there in the solution space (given the solutions on offer now, that seems to be the case). Also: we can't write a BCP if we can't know what they may be because of the proprietary nature of the filtering/reputation. If the clues we find are well known to them then, well, it's sort of like what are we supposed to do? I'm doubtful, but I'll see if the data I still have can reveal this sort of correlation given the participants I had and the data they submitted. If there are any large operators that could run such a survey, I'm sure the WG would appreciate it. And of course if operators start enforcing it fairly uniformly, spammers will just pursue other mechanisms. That's yet another reason why there probably isn't much we can do long term. FWIW, I've started collecting some of the clues I've seen along the way here. If I get enough of them, I'll write a short I-D about it. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On Sun, Feb 12, 2023 at 11:19 AM Michael Thomas wrote: > > It's certainly possible to collect data that might correlate something > like "Subject signed vs. not signed" with a spam score, and that could feed > in to a best practices document. I don't know who might be up for > investing the time into such a survey, however. OpenDKIM used to collect > such summaries from volunteer participants; I can see if the data sitting > around in those tables had enough information for such a survey, but it > almost certainly won't be current data. > > What I'm starting to think is that if we can collect that into the problem > statement that may well be all we need to do if we determine that there is > no there there in the solution space (given the solutions on offer now, > that seems to be the case). Also: we can't write a BCP if we can't know > what they may be because of the proprietary nature of the > filtering/reputation. If the clues we find are well known to them then, > well, it's sort of like what are we supposed to do? > I'm doubtful, but I'll see if the data I still have can reveal this sort of correlation given the participants I had and the data they submitted. If there are any large operators that could run such a survey, I'm sure the WG would appreciate it. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On 2/12/23 9:36 AM, Murray S. Kucherawy wrote: It's certainly possible to collect data that might correlate something like "Subject signed vs. not signed" with a spam score, and that could feed in to a best practices document. I don't know who might be up for investing the time into such a survey, however. OpenDKIM used to collect such summaries from volunteer participants; I can see if the data sitting around in those tables had enough information for such a survey, but it almost certainly won't be current data. What I'm starting to think is that if we can collect that into the problem statement that may well be all we need to do if we determine that there is no there there in the solution space (given the solutions on offer now, that seems to be the case). Also: we can't write a BCP if we can't know what they may be because of the proprietary nature of the filtering/reputation. If the clues we find are well known to them then, well, it's sort of like what are we supposed to do? Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On 12/02/2023 17:28, Murray S. Kucherawy wrote: Have they not been getting consideration? I know I've been replying to many of his comments. I didn't mean to imply he was being ignored, sorry if it sounded that way. Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On Sat, Feb 11, 2023 at 2:35 PM Michael Thomas wrote: > It's never been especially clear to me whether deployments do their > filtering up front, ie at the MX, or farther down the line. There are > certainly advantages to do it right at the MX with less burden on using AR > to signal all of what the filters consider the interesting bits that > standard A-R might not support. But there may be good architectural reasons > to postpone the filtering to later in the pipeline even if means that > you're holding the spam longer before discarding it > Yep; there's no "right" way. I've seen both kinds of architecture work, and A-R tries to anticipate all sorts of options (by not precluding any of them). > But regardless of A-R just cataloging what those interesting bits might be > could be useful in documenting how they can be used to detect replay spam. > Also: I think there is more to it than whether the signature verifies, per > say. The signature actually verifies, but it's the scrutiny that matters. > Saying it doesn't verify essentially decouples from any reputation of the > domain. But that is hardly the only way to look at it. Saying it verifies, > but has problems is another way to view it. For wetware investigators an > A-R that did that could be really confusing. > It's certainly possible to collect data that might correlate something like "Subject signed vs. not signed" with a spam score, and that could feed in to a best practices document. I don't know who might be up for investing the time into such a survey, however. OpenDKIM used to collect such summaries from volunteer participants; I can see if the data sitting around in those tables had enough information for such a survey, but it almost certainly won't be current data. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On Sat, Feb 11, 2023 at 4:48 PM Stephen Farrell wrote: > FWIW, as this discussion has a bit of a flavour of one person > arguing with a bigger bunch of people, I'd like to say that > Mike is asking good questions that deserve consideration. > Have they not been getting consideration? I know I've been replying to many of his comments. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On 2/11/2023 4:48 PM, Stephen Farrell wrote: asking good questions that deserve consideration. Steve, There is a draft problem statement that seeks to explore the problem space. Perhaps you can suggest specific additions to it that should be made and fleshed out? That is, after all, the usual way working groups try to work, even before being chartered. One of the challenges in considering email abuse 'clues' is distinguishing between ones that are inherent and of longer-term benefit to consider, versus those that might be of very transient benefit or, worse, appear in all sorts of different traffic, and possible good or bad traffic at that. Standards work is slow and expensive and therefore really ought to limit itself to things that will be of longer-term benefit. There is a very serious potential of chasing squirrels and/or trying to boil the ocean. It's easy to raise possibilities, and difficult to raise good ones. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
Hiya, FWIW, as this discussion has a bit of a flavour of one person arguing with a bigger bunch of people, I'd like to say that Mike is asking good questions that deserve consideration. I don't have a position as to what may or may not be worth doing in this space, but I figure I'll find it easier to arrive at my own position after Mike's questions are worked through. Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On 2/10/23 9:23 PM, Murray S. Kucherawy wrote: On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas wrote: I've always thought that the likelihood of a protocol level solution for this issue is pretty close to zero if not zero. The various proposed solutions in the problem draft haven't given me any reason to dissuade me of that notion. That said, I think that we might be able to catalog some clues that something is suspicious which taken with many other clues can be used to by a receiver to make an ultimate decision of spamminess. A good example is the unsigned To: and Subject: lines. Even if it's strictly allowed by the spec, that doesn't mean it's not suspect. It could be really useful to collect this clues as input signals to a larger preponderance of evidence. Authentication-Results already noted the idea that a signature, even a valid one, might still be considered not acceptable to the verifier and reported differently for one reason or another. An unsigned Subject was the classic example. Dealing with this in A-R nicely removes it from being dealt with at the protocol level, where I would argue this sort of logic doesn't belong. It's never been especially clear to me whether deployments do their filtering up front, ie at the MX, or farther down the line. There are certainly advantages to do it right at the MX with less burden on using AR to signal all of what the filters consider the interesting bits that standard A-R might not support. But there may be good architectural reasons to postpone the filtering to later in the pipeline even if means that you're holding the spam longer before discarding it. But regardless of A-R just cataloging what those interesting bits might be could be useful in documenting how they can be used to detect replay spam. Also: I think there is more to it than whether the signature verifies, per say. The signature actually verifies, but it's the scrutiny that matters. Saying it doesn't verify essentially decouples from any reputation of the domain. But that is hardly the only way to look at it. Saying it verifies, but has problems is another way to view it. For wetware investigators an A-R that did that could be really confusing. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On February 11, 2023 5:23:39 AM UTC, "Murray S. Kucherawy" wrote: >On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas wrote: > >> I've always thought that the likelihood of a protocol level solution for >> this issue is pretty close to zero if not zero. The various proposed >> solutions in the problem draft haven't given me any reason to dissuade >> me of that notion. >> >> That said, I think that we might be able to catalog some clues that >> something is suspicious which taken with many other clues can be used to >> by a receiver to make an ultimate decision of spamminess. A good example >> is the unsigned To: and Subject: lines. Even if it's strictly allowed by >> the spec, that doesn't mean it's not suspect. It could be really useful >> to collect this clues as input signals to a larger preponderance of >> evidence. >> > >Authentication-Results already noted the idea that a signature, even a >valid one, might still be considered not acceptable to the verifier and >reported differently for one reason or another. An unsigned Subject was >the classic example. > >Dealing with this in A-R nicely removes it from being dealt with at the >protocol level, where I would argue this sort of logic doesn't belong. This is pretty close to the example in RFC 8601, section 2.4 for a 'policy' ptype result. Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas wrote: > I've always thought that the likelihood of a protocol level solution for > this issue is pretty close to zero if not zero. The various proposed > solutions in the problem draft haven't given me any reason to dissuade > me of that notion. > > That said, I think that we might be able to catalog some clues that > something is suspicious which taken with many other clues can be used to > by a receiver to make an ultimate decision of spamminess. A good example > is the unsigned To: and Subject: lines. Even if it's strictly allowed by > the spec, that doesn't mean it's not suspect. It could be really useful > to collect this clues as input signals to a larger preponderance of > evidence. > Authentication-Results already noted the idea that a signature, even a valid one, might still be considered not acceptable to the verifier and reported differently for one reason or another. An unsigned Subject was the classic example. Dealing with this in A-R nicely removes it from being dealt with at the protocol level, where I would argue this sort of logic doesn't belong. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
