Alan DeKok wrote:
The keys don't have to be that secret if they can change
periodically.
This sounds to be a lot of overhead and very error-prone.
How often do you want to change them? Every day?
Reduce the DNS TTL to 24 hours? How would you cope
with the latency? I don't think you can do it often enough
to defend against stolen key and slow enough to not
cause false rejections at the same time. Maybe you'd need
a sliding window of several keys,e.g. you generate one
key per week and, with respect to the delay cause by
DNS propagation, the last three keys are considered valid.
You need this, because MTAs can delay mails up to 10 days.
So once a spammer got your key he has about three weeks
time to use it for spamming.
The same people who wrote this software would immediately
start to write routines to collect the keys to generate
false records.
How?
Exactly the same way they do steal PINs, TANs, passwords, codes
etc. today. Worms already contain elaborated procedures to collect
and reveal secrets kept on the hard disk. Looking for such a
anti-spam-key is just one more key.
People already control access to their MTA's. I don't see this as
much of a problem.
Not really. If they did, we would not have open relays.
Even if 99,9% of MTAs were secure enough. (And that's a
far too high estimation!) How many domains exist? A billion?
How many MTAs? How many stolen keys are 0,1 % of them?
That's enough for spamming.
And how would you do the synchronous update of the
DNS zone and the MTA? I do not see how this could be easily
and automatedly be done in all cases.
The message is not the SMTP transation.
Fully agreed. But if you use secret keys anyway, wouldn't it
be better to sign the message? Getting rid of all those
forwarding problems?
regards
Hadmut