On 12/11/22 1:16 PM, Murray S. Kucherawy wrote:
On Sun, Dec 11, 2022 at 1:11 PM Michael Thomas <[email protected]> wrote:
As for resolution: the first obvious one is to not send spam
in the first place. That is the root of the problem. The
second is that Bcc's can be treated with more suspicion.
Neither of these needs the working group to do anything.
I think this is easier said than done. In the example I gave,
"don't send spam in the first place" reduces to "make sure your
users are 100% trustworthy or that your outbound spam filters are
100% accurate", which strikes me as an impossible bar to meet.
I'm going to assume that the attackers will need to iterate to
find a piece of mail that passes their filters. That is signal
right there that abuse is likely. Perhaps an exponential backoff
could be employed when outbound spam is detected. Sort of like a
4xx "try later".
That's easy to evade: Come from a rotating pool of IP addresses, using
a new free account each time.
Sure. I guess the question is how much effort would spammers be willing
to expend before trying some other tactics? Can we even quantize what
the value of, say, a signed gmail piece of email is? I think that's a
basic question that needs to be answered before we declare this a
problem. I for one am all ears as "DKIM gives you better deliverability"
has always been a sort of squishy statement.
But the BCC aspect is interesting too. Don't providers already
view things with massive rcpt-to (bcc's) suspiciously?
That's easy to evade: Send a spam message to yourself only. That has
the signature. Now capture that from your inbox and replay it from a
different server to any number of recipients, using any number of
envelopes, to your heart's content. Won't pass SPF, but it passes
DKIM. If the receiver values DKIM more, or only cares if one passes,
you win.
No, I mean that the if number of RCPT-TO's is large, it's suspicious.
Even if they do individual SMTP transactions it will have the same
(signed) Message-Id so that's not evadeable either in theory.
Mike
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
