Surprisingly, given the lofty expectations above, current email does deliver reasonably well. But the system, which was designed long before the onslaught of spam or active "robot based" hacking, is creaking and breaking. And everywhere people are coming up with patches and fixes to try to make the system work better in today's environment. In some cases, the tools are there, and are just not used. Ignorance on the part of admins (in many cases) or reluctance on the part of ISP's drives some, if not most of this. I thought this would be a good opportunity to list some of my top "peeves" with today's email. Some are contentious, and are already being debated, others are downright obvious, and if people just followed the rules, they would not even be issues. In most cases, these issues are problems because they support the spread of spam, and/or handicap other mail admins from effectively dealing with the spam and virus attacks. When large ISP are responsible for problems like this, that is indefensible.

Reverse DNS: This is right up there on my list. RFC's clearly state that mail servers MUST have reverse dns records. That is; they must have PTR records in the in-addr.arpa domain. While it is easy to understand that not everyone has the knowledge or experience to properly administrate authoritative DNS servers, it is nevertheless the responsibility of any competent email admin to make sure the ip addresses they are using for their servers have proper reverse lookup. Why is this a problem? Well, to begin with, many dynamic ip's issued to residential or dialup clients have no reverse lookup. It is trivial to configure a mail transport agent (receiving server) to reject mail from other servers which do not have proper PTR records in place. Yet - you cannot do that today, as many legitimate servers do not have correct DNS settings. It is a shame.... and if everyone simply rejected mail from the offending servers, it would take little time for those admins to "get with it" and fix the issue.

I give great credit to AOL and some others who have proactively begun to block the mail from non-conforming servers. It is the right direction to go.

Block outbound port 25: This one is so obvious that it makes me seriously wonder who is setting policy at the larger ISP's out there. And yet -- this remains a very contentious subject. In a nutshell, ISP's should, without any doubt, block outbound port 25 (mail services) from their dynamic/residential user base. Those IP's (as opposed to the static and business IP customers) have absolutely no legitimate reason to be directly delivering mail to MTA's. But to this day - it remains one of the primary sources of spam (and viruses) being delivered to0 mail servers. Yes, it is true that RBL's have become a little better at listing the dynamic and dialup ranges for those ISP's, and then can list them for blocking.

But it would be so very easy and so much more effective and efficient to have it blocked by the ISP themselves at the source! Why don't they do this? It would force outbound mail through their mail servers where they could scan it for spaminess. It would also immediately stop the flood of outbound spam being directly delivered by (often hijacked) home computers.

Virus Scan Outbound Mail: When viruses arrive from the proper MTA's of large ISP's - it is clear they are not virus scanning their outbound mail. While they do tend to make a big deal of their incoming virus scanning (marketing purposes mostly), their other very real responsibility lies in preventing outbound viruses. Any ISP not virus scanning outbound mail from their user base is, without question, thoroughly irresponsible.

Silly spam "patches": So what do some of these ISP's do? They put in place "trusted sender" types of patches. You all know this one right? You send an email to someone and you get a response back from the ISP's mail server that your mail was not a known sender, so you have to go to a web site and confirm that you are the person

sending the mail. Then the receiver may subsequently authorize you to send future mails without going through all of this again... VERY inefficient! These are not sustainable, well thought out mail processes. If the above three items were properly handled by ISP's, then putting in place sender reply/confirms/authorizations would be entirely unnecessary.
Those are my top "pet peeves" of the day. There are other smaller "peeves", but nothing that threatens the state of our email more than the above do. I am hopeful for upcoming frameworks such as SPF -- assuming they can agree to an RFC to cover it! Competing protocols (SenderID etc.) have made that difficult, but whatever protocol ends up being widely adopted (SPF in the lead right now!), it will be a great benefit to mail admins.

Back>>