Hi John,
At 13:39 31-05-2007, John C Klensin wrote:
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.
It may happen that two servers at the same preference level may not
support the same extensions. I'll assume that it's not the general
case and that if it happens, remedial action can be taken as the two
servers would most likely be under the same administrative control.
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?
If the client were to proceed to smtp1.foo.example because the EHLO
response for smtp2.foo.example does not contain FOOBAR, then we have
a strategy where the client may go looking at all hosts until it
finds one which supports FOOBAR. Section 2.2.3 mentions an overall
timeout only. I assume that the same sending strategy would apply
for 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.
The nature of the FOOBAR extension may determine the behavior.
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.
I discussed about a SMTP extension which allows the client to go to
backup.foo.example. I don't think that it should fall back to
backup.foo.example as the problem (SMTP extension not support) would
persist downstream.
There are two cases, one where the message is not affected and the
other where it is. In the first case, if FOOBAR is not present, the
message is either forwarded or rejected. In the second case, the
message can either be forwarded, downgraded or rejected.
Using the following example:
foo.example. IN MX 10 smtp1.foo.example.
IN MX 10 smtp2.foo.example.
IN MX 20 backup.foo.example.
Mail gets delivered to mail.foo.example.
In case one, the client uses its local policy to decide whether to
fall back to non-FOOBAR behavior or reject.
In case two, it's the final hop (mail.foo.example) which really
dictates whether the message will be downgraded or not. Going from
smtp1.foo.example to smtp2.foo.example won't change that.
Regards,
-sm