SMTP woes

Sometime last week I was complaining to Eric J. about how much the SMTP protocol sucks. My primary reason for this was because I was beginning to write an Email Address Validator Control for ASP.NET. Ok, there are a few out there, but I just figured that I'd write one on my own and save some money. The concept of such a control is real simple... someone enters in an email address, the validator will validate the following:

  1. Email RegEx
  2. DNS MX lookup to verify the domain
  3. Verify the user at the domain

Well, the first two are simple to do. The last is a bit tricky because of how the SMTP protocol was written. There should of been something in the protocol authenticating a user and a means of verifying whether or not a user exists at a domain name. Quite simple concepts if you just think about it. Of course, neither of these exist, otherwise we wouldn't all be getting the tons of spam that we all get daily. The first of these two simple ideas would allow for SMTP servers to be open when not connected to their network (ie. I can't send mail using OptOnline's SMTP server from a dailup to MSN). The second simple idea would also help in preventing spam... if a user didn't exist at a domain then the mail wouldn't be sent. Period. Now wouldn't that be nice? Of course I wouldn't of expected that the original SMTP protocol be this way back when it was written, but heck, it could have been added to over the years. To my delight (of sorts) CNET just wrote an article about the "end of SMTP" pointing out some the shortcomings of SMTP.

Comments (6)

  1. Hmm.. Methinks that you should look back at the good ol’ UNIX days. Several of these things that you complain about actually were addressed.

    Your complaint about verifying an SMTP address isn’t really valid, because a service existed that performed the ‘verify a user’ task – this was the "Finger" service. Most places that ran Finger later turned it off, at least to the external internet, for privacy and security reasons. It’s not SMTP’s fault that no-one runs finger anymore.

    Also, SMTP is designed to be able to queue mail even if the user’s MX server cannot be located – it simply isn’t possible with the current design to always find out immediately if the user exists or not. Remember, it wasn’t so long ago that email could take days, not seconds, to deliver.

    The CNET article you refer to complains that SMTP was not designed for a hostile envirment – this isn’t true. It was designed for a network in which the dangers were in attempting to contact possibly unreachable or semi-connected servers, and not designed for hostile acts from users.

    SMTP was intended for mail delivery, and mail delivery only, that’s why these ‘extra’ services aren’t there. The KISS method, hmm?

  2. Yes, but there seem to be some "issues" with that one. It doesn’t resolve DNS MX records correctly for all my email addresses (even though in nslookup (and set type=MX) works perfectly fine.

  3. Mr. X says:

    What the heck are you smoking??

    "Of course, neither of these exist, otherwise we wouldn’t all be getting the tons of spam that we all get daily."

    Do you honestly believe that being able to verify that someone EXISTS at a site is going to REDUCE your spam level?? I would figure that the amount of crap emails that ends up in your in-box would be many multiples of what it is now, since they could easily determine which people exist. This would allow them to FOCUS their efforts only on those accounts that do exist. They would not have to waste their time blanketing millions of possibly alive email addresses.

  4. Hmm, I suppose that you’re right. I think what I was figuring was something along the lines where I can connect to my SMTP server and interrogate it as to whether a user existed or not only after I’ve authenticated myself against the server. This would be find for all users on one SMTP server, but fails if I need to determine whether or not a user existed on another SMTP server. Oh well, back to the drawing board…

Skip to main content