Clients for AUTHINFO access/440 error on post

[Russ Allbery]

Jeffrey M Vinocur <jeff at litech.org> writes:

> (I'm actually very curious what existing clients do if the send AUTHINFO
> USER and don't get 381.  Possibly the only advantage of AUTHINFO
> USER/PASS over unencrypted SASL PLAIN.)

Yeah, that's a point; hopefully they wouldn't continue on at that point.

> I'd agree with that, provided we're careful not to expose information as 
> to what groups exist on the server.

The algorithm that I had in mind is that first one checks whether any of
the groups do not match the post pattern.  If they don't, then one sends
480 if authentication is possible and hasn't yet been done, and 441
otherwise.  If they do, then procede to processing the post and return 441
or 240 as appropriate.

The only worry I have about this is that I'm not sure that clients will
know what to do with a 480 response to sending the message, and we can't
return a 480 to the initial POST command since we, at that point, have no
idea if the POST would be allowed or not.

Now, I think this thread was actually originally about the specific case
where the post pattern is empty and PERMcanpost is false, in which case we
can respond directly after the POST command and not wait to see the actual
post.  That case is easier, and basically a trivial application of the
above strategy when the POST command is sent.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.