ietf-nntp RFC977bis w.r.t. authentication
Stan Barber
sob at academ.com
Tue May 5 16:21:00 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?
Great. If that's all it takes, that's great. If someone will draft the
proposed changes to the current draft (04) and post them to the list, then
we can get on with it.
>
> > 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.
Are there two or more implementations that do this? Please list another for
me. Thanks.
>
> > 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?
NNTP is an 8bit protocol in this 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).
Again, if someone will propose a specific change to the text in the current
draft (04) about this, we can get on with this.
--
Stan | Academ Consulting Services |internet: sob at academ.com
Olan | For more info on academ, see this |uucp: mcsun!academ!sob
Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.
More information about the ietf-nntp
mailing list