ietf-nntp RFC977bis w.r.t. authentication

Chris Lewis Chris.Lewis.clewis at nt.com
Tue May 5 13:55:40 PDT 1998


Larry Osterman (Exchange) wrote:
> 
> As far as I know, there is NOTHING that needs to be done for "SASL
> complience" in the protocol definition except citing RFC2222 in the text.

That's easy.  Stan?

> The only addition that I would suggest is the ability of enumerating the
> SASL providers.  The Microsoft Exchange and MCIS servers (and the Outlook
> Express and Outlook clients) do this by returning a list of SASL providers
> supported in the response to AUTHINFO GENERIC if there are no parameters
> specified.

I thought we had already agreed on "AUTHINFO GENERIC" with no parameters
returns the list.  Ages ago.  We merely have to document what the existing
implementations do.

> Some text regarding the encoding of the arguments to AUTHINFO GENERIC is
> probably appropriate, personally I'd suggest BASE64 encoding (mostly because
> NNTP is a 7bit protocol and since the SASL packages toss around arbitrary
> binary data, it makes sense, and partly because that's what the MS servers
> have done :-)).

Is this already covered in other encoding chatter in the spec?
 
> And while we're talking about AUTHINFO GENERIC, the last paragraph in 9.1.2
> gives me heartburn - The server provides the client with the USERS email
> address by an undefined mechanism????????  And then if the From: field of
> posts doesn't match this email address, it puts a Sender: field in the post?
> Personally I'd never use such a server, while guaranteeing the identity of
> posters is interesting, there are HUGE privacy issues with a server that
> broadcasts a VALIDATED email address of a user over the internet.  I
> recognise that masking email addresses is a poor way of avoiding SPAM,
> but.......

We can make that paragraph a "mandatory option", so a site can do it if
they wish.  I was writing a BCP on this area, where it wasn't necessarily
a deliverable address in the Sender (or other authentication header),
just something in user at domain format that uniquely identified the user that
the site administrator could use.  This may be superseded by X-Trace
(if it makes it into RFC1036bis).



More information about the ietf-nntp mailing list