Time to check the rate limits on your mail servers

Sat Feb 5 19:18:53 UTC 2005

----- Original Message ----- 
From: "Edward B. Dreger" <eddy+public+spam at noc.everquick.net>

>
> 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.
>

Hi
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 
send?
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.

Joergen Hovland