doc/hook-perl - response codes for authentication

[Julien ÉLIE]

Hi Alexander,

> The following paragraph in doc/hook-perl
>
>     The NNTP response code should probably be either 281 (authentication
>     successful) or 502 (authentication unsuccessful).  If the code returned
>     is anything other than 281, nnrpd will print an authentication error
>     message and drop the connection and exit.
>
> conflicts with RFC 4643:
>
>    Responses
>      281 Authentication accepted
>      381 Password required [1]
>      481 Authentication failed/rejected
>      482 Authentication commands issued out of sequence
>      502 Command unavailable [2]
>
>      [2] If authentication has already occurred, AUTHINFO USER/PASS are
>          not valid commands (see Section 2.2).
>
> So according to the specification code 481 should be returned instead of 502.
> However, my custom Perl hook has returned 502 for two years and that also
> seems to carry the message across.

Well, to explain a bit:

* CURRENT INN 2.5.0:

It returns either 281 or 481.  Never 502.
It cannot return anything else (if not 281, it returns 481).
Compliant with RFC 4643.


* STABLE INN 2.4.x:

It returns either 281 or 502.  Never 481.
It cannot return anything else (if not 281, it returns 502).
Compliant with RFC 2980.  Yup!

Extract from RFC 2980:

  3.1.1.1 Responses

      281 Authentication accepted
      381 More authentication information required
      480 Authentication required
      482 Authentication rejected
      502 No permission

    If the combination is not valid, the server will return a 502 response.



INN 2.4.x is not meant to comply with RFC 3977 and other new RFCs.  There is
too many changes to do and backport...

Documentation for doc/hook-python.pod is not the same for 2.4 and 2.5 for
this part.  INN 2.4.x complies with RFC 2980 here!

So I would tend not to change documentation for that in STABLE.  It is however
true that STABLE INN 2.4 closes the connection after that 502.  Maybe it
should send 400 according to RFC 977 (which does not explain a lot when to
send 400 or 502 and if we can close the connection after 502).
Perhaps we should not change anything for STABLE, but the documentation should
be accurate for it.

Clients may have been expecting 502 if they comply with RFC 2980.  It can explain
why you did not run into problems with that behaviour.



> Anyway, the reason I'm reading the RFC is because I search for an appropriate
> way to distinguish internal errors (e.g. "Can't connect to MY-SQL") from
> authentication errors. Any suggestions?

    reply (481, "Can't connect to MY-SQL");

will print it:

    481 Can't connect to MY-SQL


Or you can also return a bad thing:

    reply '';

It will reply:

    400 Internal error (2).  Goodbye!

and the connection will be closed.

-- 
Julien ÉLIE

« Certains hommes aiment tellement leur femme que, pour ne pas les user,
  ils usent celle des amis. »