SMTP Mail Timeout Issue

Question

When I'm creating a user for my web application, an SMTP email (using ASP.NET's SmtpClient) is sent to the user with the automatically generated password. However, sometimes what I notice is that it times out and the new user simply won't receive the email with the password.

Alright, so I'll display a message indicating that the mail did not go through but the user is created.

Therefore, the sys admin has 2 options so far:

a) Reset the password for the user and hope another SMTP mail is sent with the auto-generated password. b) Delete and recreate the user.

I could rollback the user creation if the smtp is not sent but what is the best practice to tackle this problem?

I'm thinking that I should retry sending the email 3 times with a timeout period of 5 seconds each. So 15 seconds would be the worse case scenario.

Is this the way to go?

Answer 1

Well, depending on your platform, if you can just hand off your mail to a local MTA, it should handle the retries and such. Your program can just queue the mail and move on, not worry about dealing with timeouts and graylists etc.

If the message still can't be delivered, you could always try resending it (via a password reset feature). If that fails as well, most likely there was a mistake in the email address, and I would suggest deleting the account, causing the user to re-register.

This, of course, might not be possible on some systems, depending what can be done with an unconfirmed user - that really depends on what you allow people to do before their email is validated.

Answer 2

IMHO you should notify the user, asking him to verify the email, without retries.

If the user does not verify the email and leaves the page, you better roll back the account since the user can not access it anyway.

Most cases of timeout would be caused by invalid email accounts. Users either made a mistake or gave you a non existent email addressto avoid being spammed.

If at all possible, do not ask for your users emails. Yhe number one rule of programming should be: DO NOT annoy the user.

Answer 3

It sounds like your web app is speaking SMTP directly to your user's mail server. [Your web app is a MUA (Mail User Agent) talking to the user's MTA (Mail Transfer Agent).] Nothing says that the user's MTA must be reachable or working at the moment. You need to run your own MTA so you ensure that somebody is providing queueing, retries, etc.

If you really want to bend over backwards, you could do what you're doing (only one attempt though), fallback to queueing the message and continuing to retry on a slower schedule for at least 24 hours, and expose that unfinished state to the user.

The official answer on how your app is supposed to behave can be found in RFC1123 (Requirements for Internet Hosts - Application and Support):

5.3.1.1 Sending Strategy

The general model of a sender-SMTP is one or more processes that periodically attempt to transmit outgoing mail. In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information.

The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the sender-SMTP can determine the reason for non- delivery.

Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. The parameters to the retry algorithm MUST be configurable.

Answer 4

If you are using ASP.NET and the System.Net.Mail classes, you are probably sending the mail via the IIS instance on the web server machine (I'm not sure since you didn't specify). There's not a good way to know what's going on with your Mail Transfer Agent (IIS SMTP). It has its own retry logic, and by default, it could take a long time for the message to be delivered.

How are you detecting that the mail was not delivered? What's the "timeout" coming from?

You should have a background process that handles the sending of mail. If delivery to the MTA succeeds, you should assume all is well. Unless you are blacklisted for SPAM, most MTAs will keep retrying until they get through. If you actually get an error dropping the message off with you MTA, then definitely retry it, or figure out what's causing the failure and fix the bug. Honestly, this part should never fail.

You might want to monitor the return address for NDR messages so you can take some sort of action when you know for sure when the email wasn't delivered. But if the user cannot yet log in to the system, there's no good way to let them know what happened. Maybe you could set a cookie with a value that you associate with the email, and put something up on the login/registration page if you were unable to deliver the mail.