Re: Time to check the rate limits on your mail servers
From: Jørgen Hovland
Date: Sat Feb 05 14:20:49 2005
----- Original Message -----
From: "Edward B. Dreger" <email@example.com>
TV> Date: Fri, 4 Feb 2005 09:53:07 -0500 (EST)
TV> From: Todd Vierling
TV> The only way to be sure is via cryptographic signature. Barring that level
False. You imply that a crypto signature is a perfect guarantee, and
that nothing else can provide equal assurance.
A cryptographic signature would be a perfect guarantee as it can be used for direct identification and authorisation if you were
guaranteed that the only user of the signature was infact you and not the spyware on your machine. The implementation is everything.
To prevent spyware using your signature you can for example use some sort of local signature engine and a fingerprint reader. It
isn't possible to steal the private key because only the engine can decode it. Emails can only be signed with that signature by the
engine, and the engine needs your fingerprint first. But who really wants to stick your thumb in the reader for every email you
And I definatly don't want to start using rsa secureid for each email I send. By only having a signature engine you could atleast
limit the amount of signed emails permitted to pass through to something like 1 for every 5 minute etc.. If you dont pass the email
through the engine it won't be signed. So why would I want to use this engine then? Perhaps if Microsoft removed the existing way
of signing emails with outlook and replaced it with this one. So, my point is that a cryptographic signature/SMIME would in fact
work for the purpose it was made for on workstations depending on the implementation.
Now that you are identified and authorised - I can still send you spam! How can I stop you from doing it? I can remove your
authorisation. I can go visit you and beat you up. But its too late I already got your spam! If you have a default deny-all policy
on your mailbox you might loose that $10m contract because you didn't reply in time to that email since it wasn't authorised. Can we
afford the deny-all default policy then? It is your choice. If yes, then you really need something to send/receive authorisation
requests if the recipient does not have you on its accept list. And I am pretty sure some smart spammer will abuse this service to
send the actual spam with it if you permit text data from user-input.
If you want something to be used globally it should also be possible to implement globally. Newsletters and similar emails generated
by automated systems would be a problem. You just have to trust them to not spam you excessivly.