Hi.
A discussion elsewhere has brought this up and I want to note it
here. I don't think, given the rules, that there is much that
can be said in 2821bis other than give a little advice and there
may be about as much of that as possible in there already).
The problem goes like this:
In RFC 974 and 1123, and the text that was picked up in 2821,
the assumption was that all SMTP servers were pretty much the
same: if one found a server at a given preference level, its
capabilities were the same as any other server at that
preference level and, even if one went to a less-preferred
server, the capabilities were equivalent. In all of these cases
the "capability" was simply ability to move mail to its
destination.
While I have no recollection that we ever thought of or
discussed it, the situation changed when we adopted the
extension mechanism. Suddenly, we could have two servers at the
same preference level, one of which supported a given extension
and one which did not. There is a case to be made that this
would be a dumb way to configure things, but I don't think we
say that anywhere, much less make equivalent configurations a
requirement. The situation is similar, but arguably worse, for
systems with less-desirable preference levels: again, there is
no requirement that they support all of the extension
capabilities of the destination server.
Suppose we have a client that would really prefer to send mail
to user(_at_)foo(_dot_)example using the FOOBAR extension. An MX query on
foo.example yields
foo.example. IN MX 10 smtp1.foo.example.
IN MX 10 smtp2.foo.example.
IN MX 20 backup.foo.example.
Suppose it tries smtp2.foo.example, gets the SMTP connection
open, but the EHLO response does not contain FOOBAR. Is it
required to proceed using the non-FOOBAR behavior, or may it
(should it?) close the connection to smtp2, open one to
smtp1.foo.example, and see if *it* supports FOOBAR? If a
connection to smtp1 cannot be opened immediately, how long
should it wait (for a timeout) before giving up and going back
to smtp2?
Before answering, see if the answer changes if the nature of the
FOOBAR extension is such that, if that service is not available,
the message will be rejected or returned, not forwarded with
some restricted capabilities.
Note that, if they client believes that it needs both the FOOBAR
and BARFOO extensions, and smtp2 offers only BARFOO while smtp1
offers only FOOBAR, things get even more interesting.
I believe that, with the way the text in 2821 is written, a
client that is successful in opening an SMTP session (getting
the 220 greeting, sending an EHLO command, and getting a
response) to at least one of smtp1 or smtp2 is not permitted to
fall back to backup.foo.example under any circumstances. But,
even there, odd cases exist if the message is queued.
Anyone want to argue for a discussion of this in 2821bis and, if
so, what should be said?
john