Re: [Ietf-dkim] What makes this posting different from the original posting?
On Fri, Sep 8, 2023 at 7:17 AM Jesse Thompson wrote: > > Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in > control of the signer, as opposed to the attacker. > > > Has anyone (else) implemented it? > > > That's what I want to understand. Or, more specifically, if no one > implemented it, why? And have those blockers changed due to the changed > landscape with dkim replay, etc. > When DKIM was young, a mechanism like the one defined in RFC 6651 was enormously valuable to me when two implementations were trying to debug interoperability problems. It allowed us to see why signatures were failing. Once all the bugs were worked out and things like canonicalization and common MTA mutations were well understood, the need for this sort of thing faded away. Thus, I never heard of any implementations besides the first one. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Thu, Sep 7, 2023, at 11:42 PM, Murray S. Kucherawy wrote: > On Thu, Sep 7, 2023 at 9:38 PM Jesse Thompson wrote: >> __ >> Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in >> control of the signer, as opposed to the attacker. > > Has anyone (else) implemented it? That's what I want to understand. Or, more specifically, if no one implemented it, why? And have those blockers changed due to the changed landscape with dkim replay, etc. Jesse ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Thu, Sep 7, 2023 at 9:38 PM Jesse Thompson wrote: > Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in > control of the signer, as opposed to the attacker. > Has anyone (else) implemented it? -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Thu, Sep 7, 2023, at 12:02 PM, Dave Crocker wrote: > On 9/2/2023 7:29 AM, Jesse Thompson wrote: >> On Tue, Aug 29, 2023, at 9:02 PM, Dave Crocker wrote: >>> DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and >>> receivers opt in to use them. Both sides are necessary. So I'm wondering >>> about looking for something the furthers the collaboration. >> >> The lack of reporting to the originating DKIM signers about Replay and other >> kinds of DKIM failure modes is an example of "limitations at the sending >> side [...] trying to detect". Alex and I are starting to draft a proposal >> for receivers to report to signers using rfc5965 and rfc7489 semantics. > Since a Replay Attack has the act of replaying being done by an attacker, it > would not help to have a reporting mechanism for DKIM, because the attacker > would not use it. > > If you are thinking of reporting by the later receiving platform, how would > this get used? > Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in control of the signer, as opposed to the attacker. Jesse ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Thu, Sep 7, 2023 at 3:15 PM Evan Burke wrote: > To be clear, for us x= was one of the most effective defenses against > large-scale replay attacks. Not perfect, obviously, but applied carefully > and in conjunction with header oversigning, it created a significantly > narrower window for attacks, and reduced the potential financial return to > attackers from replay spam. I would note that the effectiveness of x= for > reducing replay risk will likely vary considerably from signer to signer, > depending on a number of factors; we may be better positioned than many > signers in that respect. > So this is interesting, in the sense that: (1) RFC 7489 warns against using "x=" for this purpose, so if that turns out to have been the wrong advice and there's evidence to back that up, then this is an opportunity for us to say so; and (2) If such a combined (e.g., with oversigning) technique isn't terribly IPR-encumbered, you're free to put forward a description of what you did as a mitigation strategy, which this WG was hoping to produce; even if DKIM itself isn't modified, this could be an Applicability Statement. -MSK, participating ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Sep 7, 2023, at 6:15 PM, Evan Burke wrote: On Thu, Sep 7, 2023 at 10:17 AM Murray S. Kucherawy mailto:superu...@gmail.com>> wrote: On Thu, Sep 7, 2023 at 10:03 AM Dave Crocker mailto:d...@dcrocker.net>> wrote: Keys cannot be rotated fast enough to be useful within the time frame that attackers work in. Key rotation works in a timeframe of days or weeks. Attackers work in the timeframe of minutes. I think we disqualified use of "x=" as a mitigation on the same basis. To be clear, for us x= was one of the most effective defenses against large-scale replay attacks. Not perfect, obviously, but applied carefully and in conjunction with header oversigning, it created a significantly narrower window for attacks, and reduced the potential financial return to attackers from replay spam. I would note that the effectiveness of x= for reducing replay risk will likely vary considerably from signer to signer, depending on a number of factors; we may be better positioned than many signers in that respect. +1 Signature expiration seemed to be a very helpful deterrent for us too. While a very limited dataset, the replay attacks that I’ve seen over the last few months mostly seem to focus on domains that don’t expire signatures. Brian ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Thu, Sep 7, 2023 at 10:17 AM Murray S. Kucherawy wrote: > On Thu, Sep 7, 2023 at 10:03 AM Dave Crocker wrote: > >> Keys cannot be rotated fast enough to be useful within the time frame >> that attackers work in. >> >> Key rotation works in a timeframe of days or weeks. Attackers work in >> the timeframe of minutes. >> > > I think we disqualified use of "x=" as a mitigation on the same basis. > To be clear, for us x= was one of the most effective defenses against large-scale replay attacks. Not perfect, obviously, but applied carefully and in conjunction with header oversigning, it created a significantly narrower window for attacks, and reduced the potential financial return to attackers from replay spam. I would note that the effectiveness of x= for reducing replay risk will likely vary considerably from signer to signer, depending on a number of factors; we may be better positioned than many signers in that respect. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Thu, Sep 7, 2023 at 10:03 AM Dave Crocker wrote: > > The "new header field" (or similar) approach alone would not open any > doors for revocation/invalidation of the fact that the signature was > applied on that first single message. Relying solely on fast key > rotation/invalidation would mean TTLs would need to be very low to have any > effect. > > Keys cannot be rotated fast enough to be useful within the time frame that > attackers work in. > > Key rotation works in a timeframe of days or weeks. Attackers work in the > timeframe of minutes. > I think we disqualified use of "x=" as a mitigation on the same basis. -MSK, participating ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On 9/2/2023 7:29 AM, Jesse Thompson wrote: On Tue, Aug 29, 2023, at 9:02 PM, Dave Crocker wrote: DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and receivers opt in to use them. Both sides are necessary. So I'm wondering about looking for something the furthers the collaboration. The lack of reporting to the originating DKIM signers about Replay and other kinds of DKIM failure modes is an example of "limitations at the sending side [...] trying to detect". Alex and I are starting to draft a proposal for receivers to report to signers using rfc5965 and rfc7489 semantics. Since a Replay Attack has the act of replaying being done by an attacker, it would not help to have a reporting mechanism for DKIM, because the attacker would not use it. If you are thinking of reporting by the later receiving platform, how would this get used? And the attacker can't bypass it, if the signature covers enough (or all) of the message. The "new header field" (or similar) approach alone would not open any doors for revocation/invalidation of the fact that the signature was applied on that first single message. Relying solely on fast key rotation/invalidation would mean TTLs would need to be very low to have any effect. Keys cannot be rotated fast enough to be useful within the time frame that attackers work in. Key rotation works in a timeframe of days or weeks. Attackers work in the timeframe of minutes. 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] What makes this posting different from the original posting?
On Tue, Aug 29, 2023, at 9:02 PM, Dave Crocker wrote: > DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and > receivers opt in to use them. Both sides are necessary. So I'm wondering > about looking for something the furthers the collaboration. The lack of reporting to the originating DKIM signers about Replay and other kinds of DKIM failure modes is an example of "limitations at the sending side [...] trying to detect". Alex and I are starting to draft a proposal for receivers to report to signers using rfc5965 and rfc7489 semantics. Even with the best FBLs, it is too reactionary to prevent the "single message" from slipping through, not to mention all of the other scenarios discussed in this conversation. The originator has to make a boolean decision, based on limited and untimely information, about whether to send the message. So, we need a mechanism for receivers/evaluators to look up additional information about the context in which the message was originally signed (i.e. Ale's "Use segmented signature domains") Does it make sense to address the evaluator-->signer and signer-->evaluator feedback problem in a unified document, or keep them separate? I have thoughts that an out of band lookup mechanism (i.e. via signer-hosted DNS policy/intent records and signer-hosted DNSxL hash tables keyed on d= domains) is needed for evaluators to understand the meaning of the different d= subdomain signatures that a signer has applied to a message. > And the attacker can't bypass it, if the signature covers enough (or all) of > the message. > The "new header field" (or similar) approach alone would not open any doors for revocation/invalidation of the fact that the signature was applied on that first single message. Relying solely on fast key rotation/invalidation would mean TTLs would need to be very low to have any effect. Jesse___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
> On 1 Sep 2023, at 18:31, Grant Taylor > wrote: > > On 9/1/23 3:32 AM, Laura Atkins wrote: >> You don’t know that they don’t do spamfiltering on outbound messages. You >> don’t see what they catch and don’t send. What you do see is when that spam >> filtering fails. > > I do know that a small number of operators don't do any outbound spam > filtering because it has come up in conversations comparing systems / > configurations. Are those operators being targeted with replay attacks? if they’re not, I don’t think this discussion is really relevant to the group. laura (participating) > >> Many ESPs are doing that, and doing blocklist checking on URLs. > > I'm glad for the ESP's efforts. > > I wish more people would do so. > >> But all it takes is for one message to slip through and amplified. > > I'm not talking about the false positives / false negatives. > > I'm talking about the lack of any outbound filtering period. Not what slips > through said filtering. > >> I don’t understand how this is going to address the problem. > > It won't solve the problem. No single thing will solve the problem. > > But it's another simple test that can be done between the MSA and the MTA to > reject things early in the flow. > >> As Bron said: the inbound system has a lot more information about the mail >> than the outbound system. > > Having more or less information doesn't have anything to do with acting on > the information that you do have, especially if it's verifiable and reliable. > >> I’ll also point out that if it’s one-to-one or one-to-few there are >> legitimate reasons to send spam. Say, mail to an abuse address reporting >> spam. I’m sure we can agree that MTAs shouldn’t be blocking abuse reports, >> yes? What you’re asking for means a lot of spam reports will be blocked (or >> incomplete). > > I'm trusting that's not a "but think of the children" knee jerk response > along the lines of "we can't filter outbound spam because we want to not > block spam reports." > > There's reasonable basic filtering and then there's deep filtering. > > I'm sure that we all know what we need to do t in order to get spam reports > through our respective systems. > > 1) Try forwarding spam as a message/rfc822 attachment. > 2) Try forwarding spam headers as a text/rfc822-headers attachment. > 3) Try putting #1 in a zip file. > 4) Try putting #2 in a zip file. > 5) Try password protecting #3. > 6) Try password protecting #4. > ... > n) Ask your postmaster how you are supposed to report spam. > > I maintain that basic spam and virus filtering should be done on outbound > email. > >> You’re asserting there are no basic checks being done. Do you have any >> evidence other than sometimes mail evades the outbound filters? > > I have had conversations with multiple small email operators over the years > that have told me that they only do any spam and virus filtering on inbound > email and that they do not do any such filtering on outbound email. > > > > -- > Grant. . . . > unix || die > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On 9/1/23 3:32 AM, Laura Atkins wrote: You don’t know that they don’t do spamfiltering on outbound messages. You don’t see what they catch and don’t send. What you do see is when that spam filtering fails. I do know that a small number of operators don't do any outbound spam filtering because it has come up in conversations comparing systems / configurations. Many ESPs are doing that, and doing blocklist checking on URLs. I'm glad for the ESP's efforts. I wish more people would do so. But all it takes is for one message to slip through and amplified. I'm not talking about the false positives / false negatives. I'm talking about the lack of any outbound filtering period. Not what slips through said filtering. I don’t understand how this is going to address the problem. It won't solve the problem. No single thing will solve the problem. But it's another simple test that can be done between the MSA and the MTA to reject things early in the flow. As Bron said: the inbound system has a lot more information about the mail than the outbound system. Having more or less information doesn't have anything to do with acting on the information that you do have, especially if it's verifiable and reliable. I’ll also point out that if it’s one-to-one or one-to-few there are legitimate reasons to send spam. Say, mail to an abuse address reporting spam. I’m sure we can agree that MTAs shouldn’t be blocking abuse reports, yes? What you’re asking for means a lot of spam reports will be blocked (or incomplete). I'm trusting that's not a "but think of the children" knee jerk response along the lines of "we can't filter outbound spam because we want to not block spam reports." There's reasonable basic filtering and then there's deep filtering. I'm sure that we all know what we need to do t in order to get spam reports through our respective systems. 1) Try forwarding spam as a message/rfc822 attachment. 2) Try forwarding spam headers as a text/rfc822-headers attachment. 3) Try putting #1 in a zip file. 4) Try putting #2 in a zip file. 5) Try password protecting #3. 6) Try password protecting #4. ... n) Ask your postmaster how you are supposed to report spam. I maintain that basic spam and virus filtering should be done on outbound email. You’re asserting there are no basic checks being done. Do you have any evidence other than sometimes mail evades the outbound filters? I have had conversations with multiple small email operators over the years that have told me that they only do any spam and virus filtering on inbound email and that they do not do any such filtering on outbound email. -- Grant. . . . unix || die ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
> On 1 Sep 2023, at 03:49, Grant Taylor > wrote: > > On 8/31/23 8:02 PM, Bron Gondwana wrote: >> The classic case was that spam about V*gra was very common, but blocking >> that word in every anti-spam filter would create something that was really >> not fit for purpose for Pfizer to use for their email system. The sender >> and recipient really make a difference about what is spam - and as the >> sender you don't know who the end recipient is, because there are plenty of >> recipients. > > I've seen -- what I consider to be -- too many systems -- read more than zero > -- that apply some amount of spam filtering to inbound message and no spam > filtering on outbound messages. You don’t know that they don’t do spamfiltering on outbound messages. You don’t see what they catch and don’t send. What you do see is when that spam filtering fails. > I've also seen many of these systems wonder why they ended up black listed > when an account was compromised and someone was sending spam through said > system. > > I feel like there should be basic spam filtering on outbound messages. Even > if it's as simple as logistical checks; making sure the from makes sense, > probably running the message through something like a default configuration > of SpamAssassin (without Bayes), and probably through something like ClamAV. > Just basic sanity checking on messages. Many ESPs are doing that, and doing blocklist checking on URLs. But all it takes is for one message to slip through and amplified. > Dare I say, I'd add SPF between the MSA and MTA. I don’t understand how this is going to address the problem. > Things to prevent blatant spam / viruses much closer to the -- likely to be > authenticated -- sender. > > I'll say it this way, if there's a 90% chance that your inbound system would > block it, then why should your outbound system send it? As Bron said: the inbound system has a lot more information about the mail than the outbound system. I’ll also point out that if it’s one-to-one or one-to-few there are legitimate reasons to send spam. Say, mail to an abuse address reporting spam. I’m sure we can agree that MTAs shouldn’t be blocking abuse reports, yes? What you’re asking for means a lot of spam reports will be blocked (or incomplete). >> Fact: recipient spam filter has more information than sender spam filter >> Result: recipient spam filter can be more restrictive without causing excess >> damage. > > Yes, there is different data. > > But there is still data on the sending side that can be used to perform basic > checks. You’re asserting there are no basic checks being done. Do you have any evidence other than sometimes mail evades the outbound filters? >> There's no hypocrisy in recognising the asymmetry, and designing with that >> in mind. > > I still think that it's hypocritical to have zero spam filtering on outbound > email while having any spam filtering on inbound email. laura (participating) -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Fri, Sep 1, 2023, at 12:49, Grant Taylor wrote: > On 8/31/23 8:02 PM, Bron Gondwana wrote: > > The classic case was that spam about V*gra was very common, but blocking > > that word in every anti-spam filter would create something that was > > really not fit for purpose for Pfizer to use for their email system. > > The sender and recipient really make a difference about what is spam - > > and as the sender you don't know who the end recipient is, because there > > are plenty of recipients. > > I've seen -- what I consider to be -- too many systems -- read more than > zero -- that apply some amount of spam filtering to inbound message and > no spam filtering on outbound messages. > > I've also seen many of these systems wonder why they ended up black > listed when an account was compromised and someone was sending spam > through said system. > > I feel like there should be basic spam filtering on outbound messages. > Even if it's as simple as logistical checks; making sure the from makes > sense, probably running the message through something like a default > configuration of SpamAssassin (without Bayes), and probably through > something like ClamAV. Just basic sanity checking on messages. > > Dare I say, I'd add SPF between the MSA and MTA. > > Things to prevent blatant spam / viruses much closer to the -- likely to > be authenticated -- sender. > > I'll say it this way, if there's a 90% chance that your inbound system > would block it, then why should your outbound system send it? We do all that, we still have messages go out sometimes that are unwanted by the recipient, side effect of having hundreds of thousands of users, some of which get their accounts stolen, even before you have to deal with the other problem, bad actors signing up. So replay of a single one of them and there goes the domain reputation. I've already posted in this thread examples of things that could be phishing or a legit business email, not enough detail for us to tell. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On 8/31/2023 7:23 PM, Bron Gondwana wrote: Now - there is a fact known to my system that's not known to yours (my signed-in identity, which isn't br...@fastmailteam.com, and may not appear at all other than an opaque header that other systems can't parse). So that's a fair call, there's asymmetric information both ways. To the extent it can help the receiver, a hashed version of the address might be useful without divulging too much ( though yes, I know that approach can be problematic.) 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] What makes this posting different from the original posting?
On 8/31/23 8:02 PM, Bron Gondwana wrote: The classic case was that spam about V*gra was very common, but blocking that word in every anti-spam filter would create something that was really not fit for purpose for Pfizer to use for their email system. The sender and recipient really make a difference about what is spam - and as the sender you don't know who the end recipient is, because there are plenty of recipients. I've seen -- what I consider to be -- too many systems -- read more than zero -- that apply some amount of spam filtering to inbound message and no spam filtering on outbound messages. I've also seen many of these systems wonder why they ended up black listed when an account was compromised and someone was sending spam through said system. I feel like there should be basic spam filtering on outbound messages. Even if it's as simple as logistical checks; making sure the from makes sense, probably running the message through something like a default configuration of SpamAssassin (without Bayes), and probably through something like ClamAV. Just basic sanity checking on messages. Dare I say, I'd add SPF between the MSA and MTA. Things to prevent blatant spam / viruses much closer to the -- likely to be authenticated -- sender. I'll say it this way, if there's a 90% chance that your inbound system would block it, then why should your outbound system send it? Fact: recipient spam filter has more information than sender spam filter Result: recipient spam filter can be more restrictive without causing excess damage. Yes, there is different data. But there is still data on the sending side that can be used to perform basic checks. There's no hypocrisy in recognising the asymmetry, and designing with that in mind. I still think that it's hypocritical to have zero spam filtering on outbound email while having any spam filtering on inbound email. -- Grant. . . . unix || die ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Fri, Sep 1, 2023, at 11:33, Stephen Farrell wrote: > > Hi Bron, > > On 01/09/2023 02:02, Bron Gondwana wrote: > > Fact: recipient spam filter has more information than sender spam filter > > I've no axe to grind here, but wondered - is there e.g. a > peer-reviewed publication that conclusively demonstrates > that? Probably not, because it's blindingly obvious - as you can see from the raw copy of this very message when your read it. Fastmail's outbound spam scanner doesn't know that you'll receive this message, since the recipient address is "ietf-dkim@ietf.org", and it doesn't know for sure that you're a member of that list. > Not saying that that's necessary, but I wondered. Reason > to ask is that I'm not sure I understand how to compare the > sender's (filter's) information vs. the receiver's in a > partial order. As I see Dave has already replied - there's all the extra headers showing the path it took, and if there were any mailing lists or alias expansions along the way, the receiving system knows the actual recipient mailbox where this may be not known at all by the sending system. Strictly - there's a fact that's known to your system and not to mine. Now - there is a fact known to my system that's not known to yours (my signed-in identity, which isn't br...@fastmailteam.com, and may not appear at all other than an opaque header that other systems can't parse). So that's a fair call, there's asymmetric information both ways. But - spam is in the eyes of the recipient, and for sure your system will have more information about whether you might want an email than my system will. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On 8/31/2023 6:02 PM, Bron Gondwana wrote: Fact: recipient spam filter has more information than sender spam filter The key bit, I think, is that more has happened, by the time of receiving. Namely more copies sent through bots, etc. Anyhow, the limitations at the sending side is why I am now wondering about the sending side providing more information to the receiver, rather than just trying to detect and stop on their own. 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] What makes this posting different from the original posting?
Hi Bron, On 01/09/2023 02:02, Bron Gondwana wrote: Fact: recipient spam filter has more information than sender spam filter I've no axe to grind here, but wondered - is there e.g. a peer-reviewed publication that conclusively demonstrates that? Not saying that that's necessary, but I wondered. Reason to ask is that I'm not sure I understand how to compare the sender's (filter's) information vs. the receiver's in a partial order. Ta, 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] What makes this posting different from the original posting?
On Wed, Aug 30, 2023, at 12:38, Grant Taylor wrote: > On 8/29/23 3:15 PM, Steve Atkins wrote: > > Any attempt by senders to filter outbound emails based solely on > > content is going to have a lot of false negatives and positives, > > wherever you decide to draw the line. > > I find the idea of using different, probably less stringent, filtering > on outbound than on inbound to be hypocritical. > > I find it tantamount to someone saying they only accept the most > pristine message while sending less pristine, and sometimes really > tarnished, email. > > Sure, there are some differences, e.g. lack of user preferences. > > Why the asymmetry? > > Why not apply the same filtering for outbound messages as applied to > inbound messages? The classic case was that spam about V*gra was very common, but blocking that word in every anti-spam filter would create something that was really not fit for purpose for Pfizer to use for their email system. The sender and recipient really make a difference about what is spam - and as the sender you don't know who the end recipient is, because there are plenty of recipients. Fact: recipient spam filter has more information than sender spam filter Result: recipient spam filter can be more restrictive without causing excess damage. There's no hypocrisy in recognising the asymmetry, and designing with that in mind. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Wed 30/Aug/2023 14:14:41 +0200 Dave Crocker wrote: On 8/30/2023 1:21 AM, Alessandro Vesely wrote: On Wed 30/Aug/2023 07:35:08 +0200 Murray S. Kucherawy wrote: On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote: On 8/29/2023 7:46 PM, Grant Taylor wrote: On 8/29/23 9:02 PM, Dave Crocker wrote: Why not re-use the existing DKIM solution, just with a different domain / set of keys? Because it does not provide the affirmative information that I am postulating/guessing the originating platform can supply. I have to agree. It's compelling to consider that a high-trust domain might flag something for my extra consideration. This could be done per-message, rather than per-key, which was Grant's counterproposal; the equivalent is to generate a selector per message, which appears at least on the surface to suffer problems of scale. The affirmative information can be provided by using semantic subdomain names, whose purpose and meaning has been registered. See the strawman here: https://mailarchive.ietf.org/arch/msg/ietf-dkim/ez0PYqMdCDoR4-sN2toPGObMMFI Except that there are no semantics to the domain naming components in DKIM, beyond the ones already defined. That was defined in the strawman linked above, from last Friday. Please have a look at it. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Wed, Aug 30, 2023 at 1:18 AM Laura Atkins wrote: > > > On 29 Aug 2023, at 19:07, Dave Crocker wrote: > > Not that this is all that new a question, but I think it might be worthy > of more (and maybe different focus)... > > When a message is used in a DKIM Replay Attack: > >1. It originates from a domain name having good reputation >2. It passes quality checks from that sending domain >3. It goes to a collaborating receiving site, which presumably means >that site is not conducting quality assessments >4. It is re-posted, preserving the original DKIM signature, but now >becomes an attack > > Two thoughts: > >1. If the substance of the message should fail a quality assessment, >why does it pass at the outbound (sending) site? > > Spam isn’t really about substance, though, it’s about being unwanted and > volume. A lot of things outbound folks use to identify spam require volume > - like ‘is this audience similar to the audience we’ve seen report high > levels of spam in the past’ or ‘does this send to addresses we know receive > a lot of spam’ or ‘is this account sending to a lot of bad addresses’. > There are other checks, like ‘does this email contain a link pointing to a > hostname on any of these DNSBLs’ - but that’s trivially solved by just > pulling out a link that isn’t on a DNSBL. The professional spam gangs, who > are likely behind the attacks, have a deep bench of domains that they pull > in and out of circulation on a regular basis. > > This also doesn’t address the problem that Google mentioned where they saw > Youtube alerts / welcome messages replayed, possibly as a way to create a > good IP reputation. > +1 to the points above, especially about professional spam gangs that have the resources to bypass the outbound spam protections. > >1. If the problem is reasonable content, but sent to many unintended >(or, rather, undeclared) recipients, then the only characteristic of note >is the fact of multiple transmissions. So I'd guess it is only a real-time >network of receivers, working in /very/ close coordination, to detect and >deal with the attack. (it's not difficult to imagine scattered >retransmissions, over time, to hide the coordination. Sort of a spread >spectrum transmission style...) > > My understanding is that one of the primary ways to ID a replay is using > Google postmaster tools and seeing increases in their graphs without a > corresponding increase in volume from their systems. > +1. Also getting at Dave's point about creating meaningful signals out of the replay spam amplification, yes, the magnitude and shape might be helpful. The Yahoo signature counting certainly represents using magnitude as a signal and presumably in their distributed system they have some framework that effectively evaluates these thresholds. But a caveat, at a certain threshold, large mailing-lists broadcasts are going to look similar to spam attacks. A different tack is the notion of getting spammers to declare and sign their recipients (DARA). If they do, then it provides a forwarding identity to associate with the amplified traffic pattern. And if they don't, then block that traffic. -Wei laura > > -- > The Delivery Expert > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > > Delivery hints and commentary: http://wordtothewise.com/blog > > > > > > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim > ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On 8/30/2023 9:58 AM, Laura Atkins wrote: On 30 Aug 2023, at 14:52, Grant Taylor wrote: On 8/30/23 12:35 AM, Murray S. Kucherawy wrote: And I've never understood why people get enamored of the idea of relying on bad reputations to spot bad actors. I think of it as the other way around; good reputation to spot good actors. Much like a brand new domain is effectively neutral immediately after it's created. Said domain earns a reputation either good or bad over time. In reality “new” domains are actually treated more negatively than neutral in many circumstances. -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com There are several F500 companies I know of that bounce mail from domains <30~60 days old as a spam and security precaution from newly registered lookalike domains. Granted, that only affects external mail to their users specifically, but for these companies, they've decided the benefits outweigh the risks in terms of any legitimate mail blocked. - Mark Alley ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
> On 30 Aug 2023, at 14:52, Grant Taylor > wrote: > > On 8/30/23 12:35 AM, Murray S. Kucherawy wrote: >> And I've never understood why people get enamored of the idea of relying on >> bad reputations to spot bad actors. > > I think of it as the other way around; good reputation to spot good actors. > > Much like a brand new domain is effectively neutral immediately after it's > created. Said domain earns a reputation either good or bad over time. In reality “new” domains are actually treated more negatively than neutral in many circumstances. -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On 8/30/23 12:35 AM, Murray S. Kucherawy wrote: And I've never understood why people get enamored of the idea of relying on bad reputations to spot bad actors. I think of it as the other way around; good reputation to spot good actors. Much like a brand new domain is effectively neutral immediately after it's created. Said domain earns a reputation either good or bad over time. -- Grant. . . . unix || die ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On 8/30/2023 1:21 AM, Alessandro Vesely wrote: On Wed 30/Aug/2023 07:35:08 +0200 Murray S. Kucherawy wrote: On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote: On 8/29/2023 7:46 PM, Grant Taylor wrote: On 8/29/23 9:02 PM, Dave Crocker wrote: Why not re-use the existing DKIM solution, just with a different domain / set of keys? Because it does not provide the affirmative information that I am postulating/guessing the originating platform can supply. I have to agree. It's compelling to consider that a high-trust domain might flag something for my extra consideration. This could be done per-message, rather than per-key, which was Grant's counterproposal; the equivalent is to generate a selector per message, which appears at least on the surface to suffer problems of scale. The affirmative information can be provided by using semantic subdomain names, whose purpose and meaning has been registered. See the strawman here: https://mailarchive.ietf.org/arch/msg/ietf-dkim/ez0PYqMdCDoR4-sN2toPGObMMFI Except that there are no semantics to the domain naming components in DKIM, beyond the ones already defined. Whatever naming choices a signer might make, the validator has no access to their meaning. It's a bit like the www convention for domain naming. Humans associate an intention to it, but computers don't. 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] What makes this posting different from the original posting?
On 8/29/2023 10:35 PM, Murray S. Kucherawy wrote: On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote: On 8/29/2023 7:46 PM, Grant Taylor wrote: > On 8/29/23 9:02 PM, Dave Crocker wrote: > Rather than doing it in a header field, though, could it be done simply with a new tag? In terms of semantics, that would work too. In terms of overall design approach, it is essentially the difference between CISC and RISC. The feature under discussion has nothing to do with core DKIM functionality. Even better, it is likely to be used by a limited set of signers. So keep it out of the core specification and make it an add-on. In practical terms, putting something into a core specification say that everyone has to implement it. Even if the text says or implies otherwise. > Let a domain establish a bad reputation. Especially if it's being > used for sending messages that are considered to be questionable. Establishing a reputation takes time. The likely behavior of a bad actor is within a very short time-frame. And it is a single account, not the entire domain, that is the problem. Or even a single message. Indeed. And I've never understood why people get enamored of the idea of relying on bad reputations to spot bad actors. A bad actor who thinks it has attracted a negative reputation need only move to a new name in an otherwise gigantic public namespace (domain name or IP address) to start over from zero. > Just use different domains / keys to indicate different things. > > No new standards. No new code. No new config. And no new information. Hence, current mechanisms only, which are not all that successful for this problem. This also presumes that operators currently develop reputation based on (d=, s=) pairs. Is that so? I thought it was mostly just the d= that matters. For the current DKIM spec, d= was specified as /the/ domain that DKIM was offering as an identifier. Further, s= does not have precise, reliable semantics. It is, in essence, a cookie that might be delivered back to the signer. 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] What makes this posting different from the original posting?
> On 30 Aug 2023, at 09:21, Alessandro Vesely wrote: > > On Wed 30/Aug/2023 06:20:47 +0200 Steve Atkins wrote: >>> On 30 Aug 2023, at 03:38, Grant Taylor >>> wrote: >>> On 8/29/23 3:15 PM, Steve Atkins wrote: Any attempt by senders to filter outbound emails based solely on content is going to have a lot of false negatives and positives, wherever you decide to draw the line. >>> I find the idea of using different, probably less stringent, filtering on >>> outbound than on inbound to be hypocritical. >> You have much more data for inbound email, and access to a much wider range >> of reactions. That’s not “hypocritical”. >> The only information a sender has that a receiver doesn’t is a broader view >> of who the recipients of messages being sent are - and that’s exactly the >> information that DKIM replay hides from the sender. > > > Large sites should exchange reputation information on each other's accounts. > Murray already proposed a standard for doing so. That doesn’t seem like something that would have any effect on someone sending a single message to themselves, which is the perspective a sender is likely to have of a DKIM replay. Cheers, Steve ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Wed 30/Aug/2023 06:20:47 +0200 Steve Atkins wrote: On 30 Aug 2023, at 03:38, Grant Taylor wrote: On 8/29/23 3:15 PM, Steve Atkins wrote: Any attempt by senders to filter outbound emails based solely on content is going to have a lot of false negatives and positives, wherever you decide to draw the line. I find the idea of using different, probably less stringent, filtering on outbound than on inbound to be hypocritical. You have much more data for inbound email, and access to a much wider range of reactions. That’s not “hypocritical”. The only information a sender has that a receiver doesn’t is a broader view of who the recipients of messages being sent are - and that’s exactly the information that DKIM replay hides from the sender. Large sites should exchange reputation information on each other's accounts. Murray already proposed a standard for doing so. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Wed 30/Aug/2023 07:35:08 +0200 Murray S. Kucherawy wrote: On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote: On 8/29/2023 7:46 PM, Grant Taylor wrote: On 8/29/23 9:02 PM, Dave Crocker wrote: Why not re-use the existing DKIM solution, just with a different domain / set of keys? Because it does not provide the affirmative information that I am postulating/guessing the originating platform can supply. I have to agree. It's compelling to consider that a high-trust domain might flag something for my extra consideration. This could be done per-message, rather than per-key, which was Grant's counterproposal; the equivalent is to generate a selector per message, which appears at least on the surface to suffer problems of scale. The affirmative information can be provided by using semantic subdomain names, whose purpose and meaning has been registered. See the strawman here: https://mailarchive.ietf.org/arch/msg/ietf-dkim/ez0PYqMdCDoR4-sN2toPGObMMFI Rather than doing it in a header field, though, could it be done simply with a new tag? The advantage of a subdomain w.r.t. a tag is that many receivers can operate on it natively, assigning reputation as normal, like Grant said, whereas a new tag would be ignored. Let a domain establish a bad reputation. Especially if it's being used for sending messages that are considered to be questionable. Establishing a reputation takes time. The likely behavior of a bad actor is within a very short time-frame. And it is a single account, not the entire domain, that is the problem. Or even a single message. Or the ellipsis in Dave's "deemed spammy by the originating platform, or for new users who do not yet have an established quality record, or..." And I've never understood why people get enamored of the idea of relying on bad reputations to spot bad actors. A bad actor who thinks it has attracted a negative reputation need only move to a new name in an otherwise gigantic public namespace (domain name or IP address) to start over from zero. I reject messages from domains newer than 30 days. What is the time frame everybody else uses? Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
> On 29 Aug 2023, at 19:07, Dave Crocker wrote: > > Not that this is all that new a question, but I think it might be worthy of > more (and maybe different focus)... > > When a message is used in a DKIM Replay Attack: > > It originates from a domain name having good reputation > It passes quality checks from that sending domain > It goes to a collaborating receiving site, which presumably means that site > is not conducting quality assessments > It is re-posted, preserving the original DKIM signature, but now becomes an > attack > Two thoughts: > > If the substance of the message should fail a quality assessment, why does it > pass at the outbound (sending) site? Spam isn’t really about substance, though, it’s about being unwanted and volume. A lot of things outbound folks use to identify spam require volume - like ‘is this audience similar to the audience we’ve seen report high levels of spam in the past’ or ‘does this send to addresses we know receive a lot of spam’ or ‘is this account sending to a lot of bad addresses’. There are other checks, like ‘does this email contain a link pointing to a hostname on any of these DNSBLs’ - but that’s trivially solved by just pulling out a link that isn’t on a DNSBL. The professional spam gangs, who are likely behind the attacks, have a deep bench of domains that they pull in and out of circulation on a regular basis. This also doesn’t address the problem that Google mentioned where they saw Youtube alerts / welcome messages replayed, possibly as a way to create a good IP reputation. > If the problem is reasonable content, but sent to many unintended (or, > rather, undeclared) recipients, then the only characteristic of note is the > fact of multiple transmissions. So I'd guess it is only a real-time network > of receivers, working in /very/ close coordination, to detect and deal with > the attack. (it's not difficult to imagine scattered retransmissions, over > time, to hide the coordination. Sort of a spread spectrum transmission > style...) My understanding is that one of the primary ways to ID a replay is using Google postmaster tools and seeing increases in their graphs without a corresponding increase in volume from their systems. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
> On 30 Aug 2023, at 06:35, Murray S. Kucherawy wrote: >> > > This also presumes that operators currently develop reputation based on (d=, > s=) pairs. Is that so? I thought it was mostly just the d= that matters. That some major consumer mailbox providers use s= to track reputation is one of the reasons nobody wants to rotate their keys. I’m not sure whether that’s still true but I wouldn’t want to do anything that would dissuade people from doing sensible key management still further. Cheers, Steve ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote: > On 8/29/2023 7:46 PM, Grant Taylor wrote: > > On 8/29/23 9:02 PM, Dave Crocker wrote: > > > > Why not re-use the existing DKIM solution, just with a different > > domain / set of keys? > > Because it does not provide the affirmative information that I am > postulating/guessing the originating platform can supply. > I have to agree. It's compelling to consider that a high-trust domain might flag something for my extra consideration. This could be done per-message, rather than per-key, which was Grant's counterproposal; the equivalent is to generate a selector per message, which appears at least on the surface to suffer problems of scale. Rather than doing it in a header field, though, could it be done simply with a new tag? > Let a domain establish a bad reputation. Especially if it's being > > used for sending messages that are considered to be questionable. > > Establishing a reputation takes time. The likely behavior of a bad > actor is within a very short time-frame. > > And it is a single account, not the entire domain, that is the problem. > Or even a single message. And I've never understood why people get enamored of the idea of relying on bad reputations to spot bad actors. A bad actor who thinks it has attracted a negative reputation need only move to a new name in an otherwise gigantic public namespace (domain name or IP address) to start over from zero. > > Just use different domains / keys to indicate different things. > > > > No new standards. No new code. No new config. > > And no new information. Hence, current mechanisms only, which are not > all that successful for this problem. > This also presumes that operators currently develop reputation based on (d=, s=) pairs. Is that so? I thought it was mostly just the d= that matters. -MSK, participating ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
Sent from my iPhone > On 30 Aug 2023, at 03:38, Grant Taylor > wrote: > > On 8/29/23 3:15 PM, Steve Atkins wrote: >> Any attempt by senders to filter outbound emails based solely on content is >> going to have a lot of false negatives and positives, wherever you decide to >> draw the line. > > I find the idea of using different, probably less stringent, filtering on > outbound than on inbound to be hypocritical. You have much more data for inbound email, and access to a much wider range of reactions. That’s not “hypocritical”. The only information a sender has that a receiver doesn’t is a broader view of who the recipients of messages being sent are - and that’s exactly the information that DKIM replay hides from the sender. > > I find it tantamount to someone saying they only accept the most pristine > message while sending less pristine, and sometimes really tarnished, email. > > Sure, there are some differences, e.g. lack of user preferences. > > Why the asymmetry? > > Why not apply the same filtering for outbound messages as applied to inbound > messages? Because they’re quite different environments. > >> Inbound content-based filtering is much easier to get right - not least >> because the fallback is “just deliver it to the spam folder” - and we’re not >> great at that. > > I guess I'm coming from a different place. I always was more worried about > what I send and not upsetting the rest of the Internet than I am about what I > accept in. That’s not the issue. It’s much easier to filter inbound mail accurately than it is outbound mail. And we’re not great at filtering inbound mail. Cheers, Steve ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On 8/29/2023 7:46 PM, Grant Taylor wrote: On 8/29/23 9:02 PM, Dave Crocker wrote: Why not re-use the existing DKIM solution, just with a different domain / set of keys? Because it does not provide the affirmative information that I am postulating/guessing the originating platform can supply. Let a domain establish a bad reputation. Especially if it's being used for sending messages that are considered to be questionable. Establishing a reputation takes time. The likely behavior of a bad actor is within a very short time-frame. And it is a single account, not the entire domain, that is the problem. Plumbing historically has had clean water and waste water. The behavior of spammers is not as discrete or as stable as your example requires. 3. Receiving hosts can take this as a flag for extra caution. The damn thing still gets to victim platforms, but those platform have a bit more information to factor in. I feel like this falls back to a priming problem of who sends the flag because not enough people are checking for it and not enough people will check for it because not enough people are sending it. What's more is that this is going to be viewed as some as tantamount to $SO_AND_SO is sending $SPAM, see they even tag it as such. The nature of a collaborative mechanism is that, yes, both sides have to adopt it. Adoption takes time. The upside of the model I'm suggesting is that a) it's pretty cheap, and b) it's likely to be useful to a relatively, small set of very, very valuable domains. So it does not have to gain widespread adoption on the origination side, to be useful. DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and receivers opt in to use them. Both sides are necessary. So I'm wondering about looking for something the furthers the collaboration. Or re-use the existing systems that are already in place and being used by much of the email community. Just use different domains / keys to indicate different things. No new standards. No new code. No new config. And no new information. Hence, current mechanisms only, which are not all that successful for this problem. Maybe I'm too salty for the end of a long day, but I feel like this is in some ways "nothing new to see here, move along". That view has been constantly asserted here, by some folk. Why anyone believing that continues to participate in this effort is a mystery. 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] What makes this posting different from the original posting?
On 8/29/23 9:02 PM, Dave Crocker wrote: A possible way to think about how to approach this: 1. Use the mechanism for messages deemed spammy by the originating platform, or for new users who do not yet have an established quality record, or... 2. Add a header field that has semantics along the lines of "Yes I signed this and yes I sent it, but I'm not happy about it." Why not re-use the existing DKIM solution, just with a different domain / set of keys? Let a domain establish a bad reputation. Especially if it's being used for sending messages that are considered to be questionable. Plumbing historically has had clean water and waste water. Now -- what is called -- grey water is being used in some places in parallel to the other two. There is no false pretense that grey water is new nor waste. Grey water is it's own thing and it is treated as such. 3. Receiving hosts can take this as a flag for extra caution. The damn thing still gets to victim platforms, but those platform have a bit more information to factor in. I feel like this falls back to a priming problem of who sends the flag because not enough people are checking for it and not enough people will check for it because not enough people are sending it. What's more is that this is going to be viewed as some as tantamount to $SO_AND_SO is sending $SPAM, see they even tag it as such. DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and receivers opt in to use them. Both sides are necessary. So I'm wondering about looking for something the furthers the collaboration. Or re-use the existing systems that are already in place and being used by much of the email community. Just use different domains / keys to indicate different things. No new standards. No new code. No new config. Just a new domain / set of keys that need to establish a reputation, whatever that is. That's something that already happens day in and day out. And the attacker can't bypass it, if the signature covers enough (or all) of the message. Maybe I'm too salty for the end of a long day, but I feel like this is in some ways "nothing new to see here, move along". -- Grant. . . . unix || die ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On 8/29/23 3:15 PM, Steve Atkins wrote: Any attempt by senders to filter outbound emails based solely on content is going to have a lot of false negatives and positives, wherever you decide to draw the line. I find the idea of using different, probably less stringent, filtering on outbound than on inbound to be hypocritical. I find it tantamount to someone saying they only accept the most pristine message while sending less pristine, and sometimes really tarnished, email. Sure, there are some differences, e.g. lack of user preferences. Why the asymmetry? Why not apply the same filtering for outbound messages as applied to inbound messages? Inbound content-based filtering is much easier to get right - not least because the fallback is “just deliver it to the spam folder” - and we’re not great at that. I guess I'm coming from a different place. I always was more worried about what I send and not upsetting the rest of the Internet than I am about what I accept in. -- Grant. . . . unix || die ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On 8/29/2023 1:15 PM, Steve Atkins wrote: Many, many people sign up to receive content that is, by any objective content-filtering standard, as spammy as an incredibly spammy thing. Seriously, people sign up for things you would not believe. Any attempt by senders to filter outbound emails based solely on content is going to have a lot of false negatives and positives, wherever you decide to draw the line. So, what you say makes complete sense, of course. And yet, I suspect that this problem nonetheless requires active measures at that point in the handling sequence. The question, then, is what might help, without causing too much problem. My immediate thought is an overlay to DKIM. That is, an added mechanism that is protected by the DKIM signature. A possible way to think about how to approach this: 1. Use the mechanism for messages deemed spammy by the originating platform, or for new users who do not yet have an established quality record, or... 2. Add a header field that has semantics along the lines of "Yes I signed this and yes I sent it, but I'm not happy about it." 3. Receiving hosts can take this as a flag for extra caution. The damn thing still gets to victim platforms, but those platform have a bit more information to factor in. DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and receivers opt in to use them. Both sides are necessary. So I'm wondering about looking for something the furthers the collaboration. And the attacker can't bypass it, if the signature covers enough (or all) of the message. d/ 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] What makes this posting different from the original posting?
Sent from my iPhone > On 29 Aug 2023, at 20:54, Dave Crocker wrote: > > On 8/29/2023 12:30 PM, Murray S. Kucherawy wrote: >> For (1), I presume the outbound site did not make a quality assessment that >> identified the message as "likely to be replayed". Does this reduce to the >> "don't sign spam" argument? > > I have no idea what the current levels of outbound filtering are, among major > platforms. If it ain't already very high, yeah, seems like it should be and > that this is an added incentive why. Many, many people sign up to receive content that is, by any objective content-filtering standard, as spammy as an incredibly spammy thing. Seriously, people sign up for things you would not believe. Any attempt by senders to filter outbound emails based solely on content is going to have a lot of false negatives and positives, wherever you decide to draw the line. Inbound content-based filtering is much easier to get right - not least because the fallback is “just deliver it to the spam folder” - and we’re not great at that. Cheers, Steve ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On 8/29/2023 12:30 PM, Murray S. Kucherawy wrote: For (1), I presume the outbound site did not make a quality assessment that identified the message as "likely to be replayed". Does this reduce to the "don't sign spam" argument? I have no idea what the current levels of outbound filtering are, among major platforms. If it ain't already very high, yeah, seems like it should be and that this is an added incentive why. 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] What makes this posting different from the original posting?
On Tue, Aug 29, 2023 at 11:10 AM Dave Crocker wrote: > Two thoughts: > >1. If the substance of the message should fail a quality assessment, >why does it pass at the outbound (sending) site? >2. If the problem is reasonable content, but sent to many unintended >(or, rather, undeclared) recipients, then the only characteristic of note >is the fact of multiple transmissions. So I'd guess it is only a real-time >network of receivers, working in /very/ close coordination, to detect and >deal with the attack. (it's not difficult to imagine scattered >retransmissions, over time, to hide the coordination. Sort of a spread >spectrum transmission style...) > > For (1), I presume the outbound site did not make a quality assessment that identified the message as "likely to be replayed". Does this reduce to the "don't sign spam" argument? -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] What makes this posting different from the original posting?
Not that this is all that new a question, but I think it might be worthy of more (and maybe different focus)... When a message is used in a DKIM Replay Attack: 1. It originates from a domain name having good reputation 2. It passes quality checks from that sending domain 3. It goes to a collaborating receiving site, which presumably means that site is not conducting quality assessments 4. It is re-posted, preserving the original DKIM signature, but now becomes an attack Two thoughts: 1. If the substance of the message should fail a quality assessment, why does it pass at the outbound (sending) site? 2. If the problem is reasonable content, but sent to many unintended (or, rather, undeclared) recipients, then the only characteristic of note is the fact of multiple transmissions. So I'd guess it is only a real-time network of receivers, working in /very/ close coordination, to detect and deal with the attack. (it's not difficult to imagine scattered retransmissions, over time, to hide the coordination. Sort of a spread spectrum transmission style...) 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
