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
extension
or it doesn't. If it does support it it needs to support whatever line
length
limits or increases that extension requires. Announcing a line length
limit
separately opens the door to all sorts of silly states.
Authentication mechanisms are awkward in that the documents specifying
them
won't necessarily specify the maximum data size they transfer
(although they
should) and hence the line length limit associated with a given
mechanism may
not be clear. But all an announcment of the limit from the server does
is push
the problem from the server implementor to the client implementor, and
in a
not-very-nice way: Now the server is free to say something like "I
support this
fancy AUTH mechanism that transfers complex certs from the client to
server,
but only if those certs fit in 1024 octers base64 encoded."
Indeed. That is what I've called "makes writing client implementations
more difficult"
So now a client has to check and see if all of its authentication
information
for a given authentication scheme will fit in the specified size. Not
only is
this a somewhat nontrivial and hence error-prone activity, it may not
even be
possible: The client may not have access to the data size prior to
starting the
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
actually
using that information.
Additionally, operational experience has shown that while negotiating
use or
non-use of an extension works pretty well, fallback to alternative
mechanisms
based on complex and dynamic criteria does not. And in many cases this
is a
solution looking for a problem, since it is pretty commmon for the
client and
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.
My guess
is many if not most will not, which makes the case of a server that
offers a
given authentication mechanism but without the corresponding
appropriate line
length limit quite problematic.
Ok.
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
directly
that such a response code is going to be needed to dianose the problems
the extension is likely to cause.
Ok.
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.