Common NNTP Extensions


Be sure to read the "RKT couplings" below for additional information, comments, and links.

NNTP-Ext:[Previous][Up to Table of Contents] [Next]

NNTP-Ext 3.1.3 AUTHINFO GENERIC

    AUTHINFO GENERIC authenticator arguments...

    AUTHINFO GENERIC is used to identify a specific entity to the
    server using arbitrary authentication  or identification
    protocols. The desired protocol is indicated by the
    authenticator parameter, and any number of parameters can
    be passed to the authenticator.

    When authorization is required, the server will send a 480
    response requesting authorization from the client. The
    client should enter AUTHINFO GENERIC followed by the
    authenticator name, and the arguments if any.  The authenticator
    and arguments must not contain the sequence "..".

    The server will attempt to engage the server end authenticator,
    similarly, the client should engage the client end authenticator.
    The server end authenticator will then initiate authentication
    using the NNTP sockets (if appropriate for that authentication
    protocol), using the protocol specified by the authenticator name.
    These authentication protocols are not included in this document,
    but are similar in structure to those referenced in RFC 1731[8]
    for the IMAP-4 protocol.

    If the server returns 501, this means that the authenticator
    invocation was syntactically incorrect, or that AUTHINFO
    GENERIC is not supported.  The client should retry using the
    AUTHINFO USER command.

    If the requested authenticator capability is not found, the
    server returns the 503 response code.

    If there is some other unspecified server program error, the
    server returns the 500 response code.

    The authenticators converse using their protocol until complete.
    If the authentication succeeds, the server authenticator will
    terminate with a 281, and the client can continue by reissuing
    the command that prompted the 380.  If the authentication fails,
    the server will respond with a 502.

    The client must provide authentication when requested by the
    server.  The server may request authentication at any
    time.  Servers may request authentication more than once
    during a single session.

    When the server authenticator completes, it provides to the
    server (by a mechanism herein undefined) the email address
    of the user, and potentially what the user is allowed to
    access. Once authenticated, the server shall generate a Sender:
    line using the email address provided by the authenticator
    if it does not match the user-supplied From: line. Additionally,
    the server should log the event, including the user's
    authenticated email address (if available). This will provide
    a means by which subsequent statistics generation can
    associate newsgroup references with unique entities - not
    necessarily by name.

NNTP-Ext 3.1.3.1 Responses

        281 Authentication succeeded
        480 Authentication required
     500 Command not understood
        501 Command not supported
        502 No permission
        503 Program error, function not performed
        nnn  authenticator-specific protocol.

[Source:"draft-ietf-nntp-imp-02.txt"] [Last Changed:March 1998]
[Copyright: 1998 S. Barber]

NNTP-Ext:[Previous][Up to Table of Contents] [Next]

(Corrections, notes, and links for Usenet RKT.)
by Mib Software, NNTP software and consulting


Note that all RFC977 2.4.3. General Responses may also be received.

Be sure to read NNTP-Ext 6.0 Security Considerations
Overview and Related Topics
Up To: NNTP-Ext 3.1 AUTHINFO
NNTP Command Syntax
NNTP Response Syntax
NNTP-Ext 3.1.1 Original AUTHINFO
NNTP-Ext 3.1.2 AUTHINFO SIMPLE

RKT Rapid-Links:[Search] [RKT Tips] Path:For Developers / NNTProtocol / NNTP-Ext / 3.1 AUTHINFO / 0035.htm

Copyright 1998, Forrest J. Cavalier III
Mib Software, NNTP software and consulting