 |
|
Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
|
|
|
Custom Search
|
|
SMTP Security Issues
(Page 1 of 2)
If you've already read the sections describing other TCP/IP protocols such as DHCP, FTP and so forth, you probably already know how I am going to start this section. The theme is a common one in TCP/IP: a lack of security in how a protocol is implemented. And this all goes back to a common root cause: most of these protocols were developed when the “Internet” was just a small group of machines controlled by individuals who mostly knew and trusted each other, or who were able to use physical security means. Developers never imagined TCP/IP being used by millions of anonymous “average Joe” users around the world, which necessitates far more attention to security than a small research internetwork like the ARPAnet.
When it comes to SMTP, security matters are if anything worse than they are with the other protocols I mentioned above. Not only does SMTP not have any real security mechanism, the original relaying model of SMTP communication is entirely designed around the idea of “cooperation” and “trust” between servers. Since most SMTP servers would be asked to handle a certain number of intermediate transfers, each server was required to accept mail from any originator to be delivered to any destination.
The basic assumption in this model is that SMTP servers would all be “well-behaved”, and not abuse the system by flooding intermediate servers with lots of mail to be delivered, or sending bogus messages to cause problems. This all changed as the Internet exploded in popularity in the 1990s. Con artists, hackers, and disreputable salespeople all discovered that e-mail could be used for “free” delivery of messages simply by submitting them to an SMTP server for delivery. The result was overloaded servers, primarily due to the sending of large quantities of unwanted e-mail, which Internet users commonly call spam.
|
Note: The term “spam”, in this context, does not have anything directly to do with the Hormel processed meat product. Its use in reference to massive amounts of e-mail comes from a Monty Python comedy sketch where that word is repeated over and over again.It is actually very easy to “impersonate” an SMTP server. You can use the Telnet Protocol to connect directly to an SMTP server on port 25. SMTP commands are all sent as text, and so are SMTP replies, so you can have a “conversation” with a server and even manually perform a mail transaction. This is useful for debugging, but also makes abuse of a wide open SMTP server trivially easy. Since spammers often don't want to be identified, they employ spoofing techniques to make it more difficult to identify them, which makes matters even more difficult.
|
| |||||||||||||||||||
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.