Sandy: I did. If tests are correct, it seems like Imail doesn't lookup for
the next IP in the MX record when various IPs are registered in the MX
Record. Instead it goes to the next MX record.
The MX algorithm says all MX records at a given preference must be tried
before moving to the next lower preference MX.
The MTA resolves an MX hostname to an A record, and tries it. The A record
selected to be tired is usually only the first physical A record in the
answer packet, if a record-set of A records in an an DNS answer packer.
here's the example of a domain having a record-set of MX records:
%dig aol.com mx
; <<>> DiG 9.2.3 <<>> aol.com mx
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45549
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 18
;; QUESTION SECTION:
;aol.com. IN MX
;; ANSWER SECTION:
aol.com. 3534 IN MX 15 mailin-03.mx.aol.com.
aol.com. 3534 IN MX 15 mailin-04.mx.aol.com.
aol.com. 3534 IN MX 15 mailin-01.mx.aol.com.
aol.com. 3534 IN MX 15 mailin-02.mx.aol.com.
all MX records of equal value, so all MX hostnames are to be tried, usually
in the physical order of the DNS answer packet above.
The MX algorithm doesn't address the case of a A record-set for an MX, such
as this:
%dig mailin-03.mx.aol.com.
; <<>> DiG 9.2.3 <<>> mailin-03.mx.aol.com.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18764
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;mailin-03.mx.aol.com. IN A
;; ANSWER SECTION:
mailin-03.mx.aol.com. 288 IN A 64.12.137.249
mailin-03.mx.aol.com. 288 IN A 64.12.138.120
mailin-03.mx.aol.com. 288 IN A 205.188.158.121
mailin-03.mx.aol.com. 288 IN A 64.12.137.152
The order of the A records is determined by the DNS answering the query,
NOT by AOL's DNS. The order should be considered effectvely random and
uncontrollable.
It's the MTA's implementation to decide to use only 64.12.137.249, before
trying:
mailin-04.mx.aol.com.
... or to try all the elements in the A record-set for mailin-03.mx.aol.com.
1. if the A record is not deliverable, then
2. the MTA tries the "next physical" MX record (-04 above, its A record) at
the same preference level
or
3. tries the MX at lower preference.
4. if no MX at lower preference, the MTA defers delivery for retry
(re-starting the MX algorithm from the top at the next retry)
I just want to confirm this is a behavior by design, a problem or just miss
configuration from my side -probably it may be fixed by changing something
in the registry-.
You're worrying about something that is buried in the implementation of the
MTA's MX algorithm, which itself is extremely well-known and ancient. There
is NO controversy. There are certainly variations in MTA implementation of
the MX algorithm, but at this point, all the well-established MTAs have
"got it right" for all intensive porpoises.
I personally have never had to get involved in an MTA's setting at this
level in 6+ years of SMTP admin, so I'm not sure you're barking up the
right tree, or if there is a tree.
Len
_____________________________________________________________________
http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
