What accounts for the length of the delay between sending an email, and getting a rejection?

Question

In a couple of examples, I've got two email addresses I'm sending to, let's say "111@abc.com" and "999@xyz.com" (two different recipients, on two different domains). In this case, the sending side is Exchange 2007, which then goes through a content filtering system (think MessageLabs-esque).

In the first example, I try to send an email, and after 2 days I get a rejection saying that

Diagnostic-Code: smtp;550 4.4.7 QUEUE.Expired; message expired

In the second example, I try to send an email, and after 6 days I get a rejection with the following diagnostic code:

Diagnostic-Code: smtp; 5.4.7 - Delivery expired (message too old) '[Errno 61] Connection refused' (delivery attempts: 0)

My question is essentially this: regardless of the specific message returned, what things, on a large scale, account for (a) when a message is rejected - i.e. how long it tries before failing, (b) and what role does the sending vs. receiving end play in determining these delays/timeouts/failures?

I'm guessing that if there's a problem sending, that the sending server's retry policy applies, whereas if SMTP connects, answers, but it doesn't get received that in that sort of situation the receiving server plays a larger role.

Thanks!

Answer 1

Depends on the sender and the error of the receiver.

if the receiver error is final (i.e. an error that means fuirther tries are not possible, for example "account does not exist", which has a specific SMTP code) then it will fail THEN.

If it is the server just disconnecting / not reachable, it is configured on the sender (how long it tries to drop the message somewhere).

if it is via relay (final server offline, backup server accepts) then it is configured on the backup server... as your server actually took the email and is rid of it.

In your case the receiver wants nothing to do with you / your server, so it refuses connections (server exists, tcp connect fails - could be one of a number of easons, anti spam module, firewall among them), so your server does not know (no final no) and retries as long as it is configured to do so.

Answer 2

Many people expect email to work like Instant Messaging. However, it is a much different mechanism using a store and forward mechanism. Substantial delays are possible, allowing more reliable delivery, but less instantaneous notification of problems.

How quickly an email waits before being bounced is configured on the server which is bouncing it. This could you your server, one of the servers on the client system, or a server in between. Typically, email will be retried for close to a week. The retry mechanism and suggestions on retry schedule are contained in the RFCs. (Don't remember the specific one.) Normally every hour or so for a few hours, then at longer intervals for longer delays.

Some servers will send a one or two messages informing the sender their message is delayed. This is optional, and usually the last delay message will be sent within a day or two.

Messages can also be bounce immediately for reasons considered permanent. I apply some policies which I won't vary, which cause emails to be bounced. These are generally applied to server configuration that indicate the email has a nearly 100% chance of being Spam. Sending email to an account which is not local here is also considered permanent (incoming mail only). Size limits are also usually considered a permanent problem. Messages with a permanent will bounce immediately unless they have already been deferred for a temporary problem.

If I refuse delivery for other reasons, then the message is deferred. This tells the calling server that the condition is temporary, and may be repaired. A properly configured server will retry for several days. some probable Spam conditions are treated this way here. If I notice a legitimate server is incorrectly configured, I adjust my configuration and allow it to deliver the message, and try to notify the manager of the other server to correct their configuration. This works well for a some Spam, as it does not retry properly.

Answer 3

I would think this is a configurable preference on either side. Once you've handed off the mail, you've got no control over when you get a notification of delivery from the handler on the other end. These are all up to the owners of the MTAs, yourself included.