I agree that DKIM replay has been and still is very much a problem. While this issue peaked in 2022 where many senders were impacted, I still see current deliverability escalation issues with DKIM replay described as the root cause. Since 2022, we put in place several mitigation but those have limitations that would be better to replace with a purpose built solution such as DKIM2
The OP of this thread acknowledges that message signers bear some responsibility for signing "spam". And several Mail Box Providers acknowledge that problem and want to do something about this hence this effort. But blaming the signers misses out on the larger picture that domain based authentication method does not attribute very well how a message got to the receiver. We see this as deliverability problems mentioned above. Instead I think we need a better way that can describe the originator, when a message was forwarded and when a participant tries to spoof the forwarding description. DKIM2 does this. With that we can more easily see abusive scenarios like replay where some message intended for one recipient was sent to many others in an inauthentic way. We can see that backscatter is part of this replay problem where some malicious sender triggers an intentional error to generate a DSN bounce where the payload carries spam. DSN are often DKIM signed since authentication is effectively mandatory. The only alternative to not signing, is to drop the DSN which is harmful in the benign case. -Wei On Mon, Apr 14, 2025 at 8:25 AM Bron Gondwana <brong= 40fastmailteam....@dmarc.ietf.org> wrote: > On Sat, Apr 12, 2025, at 03:43, Dave Crocker wrote: > > On 4/11/2025 12:56 PM, Richard Clayton wrote: > > > So, really, this is a failure of internal regulation and > > accountability that is > > > being externalized here. > > > > Although that is strictly true, the recipients of the replayed email do > > not see it that way. > > That almost sounds like a reasonable point, except that a) it is a form > of victim blaming, and b) it really only serves to distract from the > point that was being made. > > I suppose it also might be taken to imply that that I was implying > nothing should be done. But, then, I never implied anything like that. > > When working on a problem, it is pretty much always important to > understand its nature. In this case, on possible benefit is to consider > modifications that might try to limit their scope of use, rather than > requiring a massive change to the entire global email infrastructure. > > > > > Those recipients tend to blame the mailbox provider who has deemed the > > email to be authentic enough to place in their inbox. > > Recipients are unhappy. So let us say that a mechanism not designed to > handle the scenario that is making them unhappy is 'broken'. And let us > make massive changes to the email infrastructure. And...? > > It might be worth considering offering a response that is a tad more > on-point? > > > > The mailbox provider's explanation that this is entirely legitimate > > email, that comes from where it says it does, has a DKIM1 signature that > > attests to it not being altered in any way cuts little ice. > > Looks like you are viewing my comments as meaning nothing should be done > about DKIM Replay. But I never said nor implied that. > > It is, however, curious that there is no interest in considering that > the relatively few platforms generating this problem, through a lack of > accountability, might maybe oughta be considered for making some changes > to -- and I am sure this will be a surprising suggestion -- their > controls on their users? > > > I do believe we have discussed this many times already. > > Regarding the "relatively few platforms generating this problem" > statement. This is an assertion without data. > > I know that Fastmail had a case of messages with our DKIM signatures on > them being replayed. We are reasonably careful about who we allow to sign > up to use our service, but we can't stop people having their login > credentials stolen. > > I don't know how many other services which allow their users to generate > emails were similarly affected; but I do know that even a perfectly > legitimate email to its intended recipient (e.g. an invoice for services > rendered) sent to one person can be very harmful when replayed to millions > of unrelated people. > > Bron. > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > br...@fastmailteam.com > > > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
