Pavel Kankovsky wrote:
> 1. The host is dead => it does not send any datagrams =>
> it does not speak SMTP.
> 2. The host is alive but no process listens on SMTP port => it refuses
> TCP connections => it does not speak SMTP.
> 3. The host is alive, some process listens on SMTP port but something
> gets screwed up when a connection is open, and the connection is closed
> immediately (e.g. qmail-smtpd binary is corrupted and dies immediately)
> => it does not say SMTP hello => it does not speak SMTP.
Described another way, there are many failure scenarios where the actual
cause is not a misconfiguration of the mail:
1. The server is out of memory and is unable to copy a datagram containing
a SYN packet from the device interface layer to the IP network layer.
The packet is discarded and no ACK or RST is ever sent.
2. The server is out of memory and is unable to allocate structures for
completing a connection. A RST might be sent back to the source.
3. The server is out of memory and is unable to sbrk() more memory for the
process that accepted the incoming connection. The process faults
before conducting protocol, and a RST is sent to close the connection.
We may well fault the server for not having enough RAM, or enough swap space,
or having hosted an IRC bot and invited DoS attacks, or whatever. But
the mail implementation (it could be qmail) and configuration may well be
entirely correct.
In any such failure scenario, there may be reasons for a mail server to
chose some action, such as:
1. Immediately try the same server again.
2. Immediately try the next higher MX server. If all MX servers fail,
choose an action from 3 or 4.
3. Requeue the message to be tried again later. If a certain time
period has expired, return the message to the sender.
4. Return the message to the sender immediately even though the time
period for expiration has not lapsed.
Whatever the choice of action, why would that choice not be consistent
across the 3 failure modes? All 3 failure modes represent a situation
which may be corrected any time between the next delivery attempt, and
the final delivery attempt (hence making action #4 a bad choice, IMHO).
I can understand (but not entirely agree with) arguments against going to
the next higher MX. What I cannot understand is why some of the failure
scenarios would justify that choice while others would not.
> Summary: the server fails to speak SMTP in all cases.
>
> Ergo, if the server is listed as an MX record for some domain name, "I
> claimed it was speaking SMTP but upon examination, it isn't, therefore MX
> records are false." In ALL cases 1, 2, and 3. Why does qmail fall back to
> other MXes in cases 1 and 2 but not in case 3? Why does it fall back at
> all? It should always ignore the other MXes because the records are
> always incorrect according to your reasoning!?
The server may well be configured to speak SMTP in all 3 cases were it
not muffled by a transient error condition that could be corrected by
things between a sysadmin cleaning up runaway processes, or a netadmin
blocking a DoS attack at the router, or a nervous operator pushing the
reset button.
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
