On Thu, 21 Sep 2006, John Peacock wrote:
Charlie Brady wrote:
If found no explanation for this "extension" of the protocol.
RFC-2554 discusses AUTH=<address> as a _parameter_ of the MAIL FROM command,
Sure, but I don't see any relevance there.
and apparently Postfix (among others) added that to the list of AUTH values
because some ESMTP clients broke otherwise.
Whoever did it first did so foolishly. The ESMTP clients which broke
unless capabilities included AUTH= would have worked with *no* servers.
See
http://www.fehcom.de/qmail/smtpauth.html
for some commentary...
Thanks. Looks to be just handwaving there ("broke the parsing of several
ESMTP client implementations").
Here, RFC 2554 uses multiple values for the keyword AUTH as ESMTP
command, which is allow by RFC 1869,
I think what is being discussed here is an EHLO response (not ESMTP
command), and the syntax from RFC 1869 is:
ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF
/ ( "250-" domain [ SP greeting ] CR LF
*( "250-" ehlo-line CR LF )
"250" SP ehlo-line CR LF )
; the usual HELO chit-chat
greeting ::= 1*<any character other than CR or LF>
ehlo-line ::= ehlo-keyword *( SP ehlo-param )
ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; syntax and values depend on ehlo-keyword
ehlo-param ::= 1*<any CHAR excluding SP and all
control characters (US ASCII 0-31
inclusive)>
By my reading, that clearly allows multiple (or none) space separated
"ehlo-param" per ehlo-line.
... however broke the parsing of several ESMTP client implementations.
One work around is, to add artificially a "=" (equal sign) between the AUTH
keyword and the value, eg. AUTH=LOGIN.
The clients with parsing problems were broken. They would have been fixed.
By catering to them, now all servers much be RFC non-complient -
"AUTH=xxx" is not a valid ehlo-line.
