this is a german Web-Mirror of MHONARC.ORG powered by Domainunion AG

ietf-smtp
[Top] [All Lists]

Re: line lengths for AUTH

2006-12-12 13:04:41


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."

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.

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.

                                Ned