Ned Freed wrote:
Robert A. Rosenberg wrote:
> At 17:08 +0000 on 12/07/2006, Alexey Melnikov wrote about Re: line
> lengths for AUTH:
>> But I guess the document can specify an absolute minimum and allow
>> implementations to support bigger line lengths.
> How about defining a 220 Keyword to designate/supply the length that
> the SMTP Server is willing to accept?
I can add a new EHLO keyword (which would be "SHOULD be advertised by
SMTP servers"), if people think this is important.
I think it does much more harm than good. A server either supports an
or it doesn't. If it does support it it needs to support whatever line
limits or increases that extension requires. Announcing a line length
separately opens the door to all sorts of silly states.
Authentication mechanisms are awkward in that the documents specifying
won't necessarily specify the maximum data size they transfer
should) and hence the line length limit associated with a given
not be clear. But all an announcment of the limit from the server does
the problem from the server implementor to the client implementor, and
not-very-nice way: Now the server is free to say something like "I
fancy AUTH mechanism that transfers complex certs from the client to
but only if those certs fit in 1024 octers base64 encoded."
Indeed. That is what I've called "makes writing client implementations
So now a client has to check and see if all of its authentication
for a given authentication scheme will fit in the specified size. Not
this a somewhat nontrivial and hence error-prone activity, it may not
possible: The client may not have access to the data size prior to
authentication operation or the client's act of accessing a given type of
credential to find out its size may commit the client in some way to
using that information.
Additionally, operational experience has shown that while negotiating
non-use of an extension works pretty well, fallback to alternative
based on complex and dynamic criteria does not. And in many cases this
solution looking for a problem, since it is pretty commmon for the
server to share exactly one authentication scheme..
I personally think this is not important enough and would make writing
client implementations more difficult.
That assumes clients would actually pay attention to this extension.
is many if not most will not, which makes the case of a server that
given authentication mechanism but without the corresponding
length limit quite problematic.
An alternative would be to add a new enhanced response code for
"authentication exchange line is too long" case.
That would be an entirely reasonable thing to have. But it isn't really
an alternative: If this extension is implemented it follows pretty
that such a response code is going to be needed to dianose the problems
the extension is likely to cause.
I've added the following to the SMTP AUTH document:
X.5.6 Authentication Exchange line is too long
This enhanced status code SHOULD be returned when the server
fails the AUTH command due to the client sending a [BASE64] response
which is longer than the maximum buffer size available for the
currently selected SASL mechanism.