|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Time to check the rate limits on your mail servers
----- Original Message ----- From: "Edward B. Dreger" <[email protected]> HiTV> 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 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
|