On Thu November 18 2004 16:02, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
MUA was apparently either sending an AUTH even though the server didn't say
AUTH,
or trying an AUTH type not advertised.. and the server requires AUTH based on
source IP, and the client was a migratory machine... can you see a headache
coming? ;)
To make life *really* interesting, the server software was (near as I can
tell)
quite likely just sending back a '250 What evverrrrrrr..' and ignoring
the AUTH, so things Just Kept Sort Of Working (until the phase of the moon
changed.. (Either that, or the server was sending back a '5xx yeah, right'
that the client was ignoring.. ;)
AUTH is an interesting case; 2821 forbids a server from offering an
extension not beginning with X- unless the extension is registered
by IANA [RFC 2821 sect. 2.2.2]:
Conversely, keyword values
presented in the EHLO response that do not begin with "X" MUST
correspond to a standard, standards-track, or IESG-approved
experimental SMTP service extension registered with IANA.
and IANA has not seen fit to register (
http://www.iana.org/assignments/mail-parameters
) the Standards Track RFC 2554 (issued March 1999) AUTH
extension (probably because Myers neglected to include an IANA
considerations section). So until IANA gets around to registering
the 5+ year old AUTH extension, an RFC 2821 compliant server
isn't allowed to advertise AUTH.
This isn't an ordinary headache; it's a migraine. [not sure what
you mean by "AUTH based on source IP"; AUTH uses a SASL
mechanism based on a shared secret]
Incidentally, if you had initially stated that the extension in
question was AUTH, we could have pointed to RFC 2821 section
4.1.1 which specifically addresses command parameters such
as the one used with MAIL FROM when the AUTH extension is
in effect.
Right - my point was that requiring each extension to include its own
"thou shalt not send FOO unless..." wasn't a great way to be doing it,
because if an extension *failed* to say it, you could conceivably send
the extension's X-FOO verb because nobody else said it wasn't OK...
An explicit requirement such as the one in RFC 3030 is appropriate
for BDAT because of the unusual potential for confusion. Likewise
for any specific extension with similar potential. But it's not
necessary in general because of the server's ability to send a
negative response. And the AUTH IANA snafu is an example of
the sort of problems that such a generic prohibition would lead to.