You should ALWAYS be able to tell if someone is abusing your system by doing a somewhat regular log analysis, at least in my opinion.
If I were to implement SSL, I would do this log analysis regularly anyway. This is the only way I know of that many system attacks can be discovered - vigilance on the part of a human and overall system-awareness. Many admins scan the logs only after the fact - I think this is inadequate. So it doesn't seem to me that using SSL in a general way would provide any real extra security, just extra processing time. It's best use is to make certain that an email is encrypted so that it can't be read by intermediary servers, not to prevent spammers from getting a hold of account passwords. In the case you mention, I consider it far more likely that a user would reveal their password inadvertently to a would-be hacker/spammer who would then use it to gain access, or that a user would use a simple to crack password, or some other entry point - SSL of would not help with any of this. I tell all my users not to send any email they aren't comfortable being public knowledge. SSL would correct this. It is a good service to offer for those who need it, though! For those who need to send email with industry secrets, credit card numbers, drug deals, spy vs. spy, radical anarchist viewpoints, and so on! I can't tell you what the overhead is exactly for SSL, although on a fast system it wouldn't be anywhere near 5 seconds for any but extremely large messages. However, if you are processing a lot of email, and especially allowing large attachments and the like, overall you may feel the burn! Jeff Ross Gohlke wrote: >Jeff Buehler wrote: > > >>By the way, while it is possible, I think the likelihood of spammers >> >> >going to the effort to retrieve packets to use your server for spamming >is extremely low. I have never heard of anyone going to the effort to >sniff packets simply to spam on commercial servers - none of the big >commercial servers use SSL for regular email transactions - Comcast, >SBC, and so on - and they have a lot more at risk than most of us. >Also, it is a potentially pretty big bust these days since once they use > > > >>an ill-gained password they have stepped over the law, so if they manage >> >> > > > >>to cause damage with it they might be tracked down like dogs (with your >> >> >help, of course!) > >It's hard to find the balance between paranoid and exposed... > > > >>Lastly, SSL is not very efficient since it takes time to encrypt and >> >> >then decrypt. Personally I would only use it for transactions that are >required to be secure, not for daily emailing. > >So if SSL is used, does it encrypt the ENTIRE MESSAGE, not just >authentication? Does it hog the processor or just make the user wait? For >how long? 5 or 50 extra seconds on an average email? What about >attachments? > >Encrypted email is definitely a service I want to offer. > >I think the stakes for email are only going to get higher, especially if >SPF or similar takes hold. ISPs will have to get increasingly vigilant >about how they do email. > >Here's a googled list of clients that support SSL. >http://www.uni.edu/its/us/document/unimail/ssl/ > > > >>Anyway, if you still want to use it, I would try updating your openssl >> >> >either to the newest version or to 0.9.7e (which I know works on my >system). > >Should I just download the patch from the same place in your website? > > > > > >- >To unsubscribe from this list: send the line "unsubscribe xmail" in >the body of a message to [EMAIL PROTECTED] >For general help: send the line "help" in the body of a message to >[EMAIL PROTECTED] > > > > - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
