Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a short question about the topic of MX records.

Let's say, we have multiple mail servers in DNS records. If someone is sending a mail, the outgoing mail server will check the MX and contact the first server with the lowest cost.

Let's say that is an exchange server. If this server doesn't have the requested mail address, what happens then? Does the outgoing mailserver send the message to the second mailserver in the MX record? Or does that depends on the error message by the first mailserver?

And how does exchange handle messages to "unknown addresses"?

share|improve this question

closed as off-topic by bahamat, jasonwryan, slm, Anthon, rahmu Sep 14 '13 at 11:04

  • This question does not appear to be about Unix or Linux within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

    
+1 with minor nit: the number associated with an MX entry is a preference not a "cost" where lower numbers have higher preference (so it kinda looks like a cost). –  msw Sep 14 '13 at 0:45
4  
This question appears to be off-topic because it is about Microsoft Exchange. –  bahamat Sep 14 '13 at 1:08

2 Answers 2

All mail servers listed in a domain's MX record are assumed to be fully able to deliver mail to any user in the domain. If one server responds with an "unknown address" message Exchange [or any other mail server] will consider that message undeliverable and handle it according to its settings.

IIRC by default Exchange generates a bounce back to the sender, but may also be configured to discard the message.

Note: the only time that a sending mail server will attempt to contact alternate servers in the MX records for a domain is in the case that the server its chosen is unresponsive.

share|improve this answer
1  
one obvious conclusion to make from this is that if an MX server does not know about a valid/legitimate recipient address, then it should not be an MX server for that domain. –  cas Sep 14 '13 at 0:22
1  
The server can return a transient failure code ( like mailbox full ) and the other server will try again later, possibly trying a different MX. –  psusi Sep 14 '13 at 0:52
    
Or the user simply does not exist, or the sending user of the email in question typo'ed the email address - these are all valid cases in which you would generally expect a 5xx code and a return of your email in an NDR (see my post for more explainations of these terminologies). –  Drav Sloan Sep 14 '13 at 4:43

SMTP and ESMTP (the underlying protocols) that handle mail delivery have extensive RFCs (the original being RFC822, and more modern update RFC2822 and a Internet standards track protocol in RFC5322).

How mail servers deal with errors during delivery varies from mail server to mail server. Adding to the complication is the fact that a lot of them are configurable and easy to change the default behavior outlined in the RFCs.

The general rule of thumb, given the above caveats is:

Pick the highest preference MX record, or one at random if several records of the same preference exist (some times the random behavior is instead a round-robin algorithm). If the chosen host is "unreachable" (no route to host, connection refused or similar), try the next MX record of same preference or lower. As msw has mentioned, these are some what counter intuitive - the highest preference is 0 and records of a higher number are considered less preferential.

This is repeated until a connection is established, OR all hosts fail to respond, in which case the email is re-queued for later attempt at redelivery. Most mail servers will attempt this for a certain amount of time (usually something like 1 to 2 days), before it gives up and returns the email in a Non-Delivery Report (NDR).

If the connection is successful, the various steps of the RFC protocol dictate the general behavior of connecting MTAs. From the initial banner sent by the remote mail server, to each of the various command issued to it (from EHLO/HELO, through MAIL FROM, RCPT TO and DATA statements), the general rule of thumb is:

4xx transient error, try again later

With this code, the email is re-queued by the local mail server and delivery attempted at a later time (configured in the settings of that local mail server)

5xx fatal error, mail undeliverable

With this code, the email is considered undeliverable and the local sending mail server will (not always, but on most servers) generate an NDR (Non-delivery Report).

In terms of your question "If this server doesn't have the requested mail address", at RCPT TO stage, most servers would respond with a 5xx code and your local mail server would generate an NDR.

Not all email servers are created equal

There are some caveats to this. MS Exchange for the longest time, would accept ALL emails regardless of incorrect recipients, unroutable domains and so forth, and then generate an NDR after the fact. Certain ISPs due to issues with spam and phenomenon known as Back Scatter, do not even generate NDRs and your mail "silently fail" (you never receive any notification of failed delivery).

You also have to take into consideration that the MTA (Mail Transport Agent, or mail server) is not always the end-point of delivery and MDAs (mail delivery agents - such as procmail) and MUAs (Mail User Agents) or "mail clients" such as thunderbird/outlook etc can be configured to "return" those emails with their own NDR-like responses. There are also such mechanisms as .forward files which can get the MTA to redirect the email to another address after acceptance of the email. Certain mail servers (I know this is the case for Exim), will attempt to expand the .forward at the point of the RCPT TO stage of the SMTP conversation and if that expands to an unroutable address reply with the 5xx series of error codes mentioned above.

For a much more accurate and in-depth explanation read the RFCs mentioned above and the documentation of the MTA you are using (remembering that how it is configured may play a part in it's behavior).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.