On 12/14/22 3:06 PM, Murray S. Kucherawy wrote:
On Tue, Dec 13, 2022 at 5:00 PM Michael Thomas <[email protected]> wrote:
On 12/13/22 6:35 AM, Murray S. Kucherawy wrote:
This tactic appears to me to have three problems: (1) negative
reputations are of little value to receivers, because attackers
can easily shed them; (2) if I have to remember everything with a
negative reputation for some undetermined period of time, I now
have a resource problem; (3) I can just not sign my mail, because
maybe no reputation is better than a negative one.
I don't understand #1. As in they can move to another service? Or
what?
Right. IP address gets a bad reputation? Move to another one.
Domain blocklisted? Register another one. etc. Any bad reputation is
trivially exchanged for a neutral one. That leaves us in a world
where only positive reputations are meaningful, and presumably once
you have one you'll work to protect it.
Unless they're running ipv6, that's getting harder and harder to do, of
course. And don't DNSBL's also blacklist subnets too? That's certainly
not optimal for whoever is hosting them. ipv4 space costs money these days.
As for 3, it's pretty easy to cons up a new domain with fresh
neutral reputation and still enjoy the supposed benefit of mail
being signed for awhile. If you factor SPF in though it probably
gets harder because now you need not only a new domain, but the
underlying network connectivity to avoid detection.
Yep, but if a receiver values DKIM more than SPF, for instance, then
maybe they're willing to forgive that lack of support. Maybe the
forwarding problem bugs you enough that you're forced into such a
position, for instance.
Which brings up a question: even though they pass on DKIM they
should fail on SPF, right? For transactional email that seems like
a big old red flag, right?
Yes, but that doesn't work for all applications or flows. It depends
on what tolerances work for your use case and your users.
It seems to me that the attack is a pretty narrow use case. That is,
spam disguised as marketing email. That seems like a use case that SPF
covers well. And it would be really suspicious to have a mile long set
of RCPT-TO's for that kind of use case where SPF fails, right? And I'm
not sure why they would prefer one or the other -- they are just inputs
to a larger data set. But if something with good reputation that
normally passes SPF too starts sending mail where SPF fails, that's like
a red flag, right? Again the ESP use case should be pretty predictable.
Mike
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
