--On Friday, 15 July, 2005 06:36 -0700 SM <sm(_at_)resistor(_dot_)net>
wrote:
Hi Michael,
At 10:04 14-07-2005, Michael Kenny wrote:
We use the Tumbleweed EMF as our outward facing mail relay.
It does anti-virus scanning and spam filtering for us and
then relays to one of three Domino R5 servers for further
inbound delivery. The Tumbleweed server maintains an internal
list of the inbound mail relay servers to try, in order, as
listed in their Relays options setup.
...
The answer from Tumbleweed was this: "The EMF server detected
the server was up, so it never retried the others."
The SMTP service was not up. The server should have retried
delivery to the other relay servers according to your
description in paragraph one. This relay strategy is a local
implementation by the vendor and is not covered by RFC 2821.
To put that a little more strongly, it is a member of the family
of local strategies that 2821 intends to permit. That
permission comes, essentially by assuming that final delivery
_from the SMTP transport environment_ is made to your server and
that anything after that is an internal matter. But the
behavior is not conformant to the standard, it is just, from the
standard's point of view, local processing.
This is one of the reasons why there are actual advantages to
the slightly fuzzy mail model of 2821 as compared to more
rigorous models of the Internet mail system that identify
particular roles and than assume that, having identified them,
many specific attributes can be attached to the identification.
In the real world, a receiving mail server for an organization
can behave like a relay to "internal" SMTP hosts, as a gateway
to an entirely different mail format and transport environment,
as a host that delivers, directly or indirectly, to a final mail
store, etc. All of these cases have uses in the real world, and
all of them can be made to "work" reasonably well. The mail
server sending traffic into one of these environments can't tell
what happens in the hop or function at occurs after it delivers
to the server it delivers to. That is actually an advantage
from both security and operations standpoints.
Two questions: Is that assumption correct? That is, should an
SMTP client rely solely on correct SMTP responses and not
some other machine state to determine if a server is up and
whether to try the next server in line?
The client should rely on the SMTP response. It should retry
the next server in line if that implementation is like MX
records.
And: Is delivery failure definition and the resulting
behavior clearly outlined in an RFC somewhere? I've seen the
rules about how to handle MX record requests and how to order
them and the resulting deliveries. But I guess I missed
something that clearly defines when an SMTP server is
supposed to be considered "Down"
This is discussed in RFC 2821. See the "Sending Strategy"
section. If you connect to a SMTP service and you don't get
an initial reply (Section 4.5.3.2), you consider that service
as down.
I thought that text was about as specific as it needed to be,
maybe a bit more so. If it is not, please cite specific
ambiguities or, better, suggest text for 2821bis.
john