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-13 11:11:12

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.

<Prev in Thread] Current Thread [Next in Thread>