Subject: SMTP AUTH implementations?

From: Nelson Tang <[email-masked]>
Date: Wed, 21 Apr 1999 11:59:44 -0700 (PDT)

Hi -

I'm looking for any work on implementations of the SMTP AUTH extension
(RFC 2554).  Can anyone point me to any such resources?

Thanks,
--Nelson

~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
  Nelson Tang                  Internet Research Lab
[email-masked]         UCLA Computer Science Department

---

From: Tim Martin <[email-masked]>
Date: Fri, 23 Apr 1999 16:15:00 -0400 (EDT)

> (RFC 2554).  Can anyone point me to any such resources?

At CMU we have implemented patches for Sendmail for SMTP AUTH based on our
SASL library. Currently the Sendmail guys are reviewing the patches for
hopeful inclusion in the next version of Sendmail (8.10 I believe). If you
have any questions or would like to try an interoperability test please
contact me.

Tim Martin

---

From: Chris Newman <[email-masked]>
Date: Mon, 26 Apr 1999 22:04:08 -0700

> (RFC 2554).  Can anyone point me to any such resources?

Our shipping server has SMTP AUTH support for relay and I'd be glad to set
up test accounts for client implementors.  Not sure when we'll get to
implementing the server->server SMTP AUTH feature.

There's a variety of client support out there.  Netscape 4.5, Mulberry,
Execmail (aka Simeon), Paladin mail, and Eudora.

In addition, Outlook Express and Netscape 4.0x implemented an early draft
of SMTP AUTH (using slightly different variants of the non-standard LOGIN
mechanism) which technically violates the ESMTP spec, but doesn't seem to
cause much harm in practice.

		- Chris

---

From: Tim Martin <[email-masked]>
Date: Fri, 23 Apr 1999 16:15:00 -0400 (EDT)

Tim Martin

---

From: Chris Newman <[email-masked]>
Date: Mon, 26 Apr 1999 22:04:08 -0700

- Chris

Date: Mon, 26 Apr 1999 22:04:08 -0700
From: Chris Newman <[email-masked]>
Subject: Re: SMTP AUTH implementations?
Originator-info: login-id=chris; server=thor.innosoft.com
To: Nelson Tang <[email-masked]>, [email-masked]
Sender: [email-masked]

		- Chris

Date: Fri, 23 Apr 1999 16:15:00 -0400 (EDT)
From: Tim Martin <[email-masked]>
To: [email-masked]
Subject: Re: SMTP AUTH implementations?
Sender: [email-masked]

Tim Martin

Date: Fri, 23 Apr 1999 14:25:38 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: Laurence Lundblade <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: SMTP AUTH implementations?
Sender: [email-masked]

Laurence Lundblade wrote:
> 
> Also can someone explain the paragraph?
>   If an AUTH fails the server MUST behave the same....
> 
> If it doesn't change it's behavior (e.g. accept submission for
> relay), what's the point? 

That's just it, many systems >>don't<< accept submission for relay under
unauthenticated circumstances, but would like to do so if you are
authenticated.

	Tony Hansen
	[email-masked]

Date: Fri, 23 Apr 1999 10:25:04 -0700
To: [email-masked], [email-masked]
From: Laurence Lundblade <[email-masked]>
Subject: RE: SMTP AUTH implementations?
Sender: [email-masked]

(if this discussion has been had before please point me to it...)

I know a lot of client folks have a user preference about SMTP AUTH 
(the "manual" option in Chris's implementation list). Personally I'm 
very reluctant to present the user with yet another option to set, so 
my thought is to prompt the user for a password when the server 
advertises AUTH.

This depends somewhat on servers advertising AUTH only if they mean 
it and need it, which I think implies that servers that support AUTH 
don't advertise it unless the administrators configures it to be on. 
Basically they adhere to section 9 paragraph 4 that says you 
shouldn't advertise unless the user has some gain. Is this what 
servers are doing?

Also can someone explain the paragraph?
  If an AUTH fails the server MUST behave the same....

If it doesn't change it's behavior (e.g. accept submission for 
relay), what's the point? I would guess what this means is that the 
server shouldn't close the connection, should still accept other SMTP 
commands, and maybe even perform some of the functions associated 
with those commands.

LL

At 4:26 PM +0100 4/23/99, [email-masked] wrote:
>Hello Nelson
>We (ISOCOR) have implemented server side.
>Up and running on our live N-PLEX Global servers (if version number 
>reported begins with 4).
>We have tested against a few - including Netscape Communicator 4.5
>[is the source for that up on Mozilla?]
>
>Once you have something ready to test then feel free to give us a shout.
>
>Rgds
>Paul Webster - ISOCOR UK
>http://www.isocor.com
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: 21 April 1999 21:11
>To: [email-masked]
>Subject: SMTP AUTH implementations?
>
>
>Hi -
>

From: [email-masked]
X400-Received: by mta ISOGB02 in /PRMD=ISOCOR/ADMD=Eirmail400/C=IE; relayed; 23 Apr 1999 16:27:32 +0100
X400-Received: by mta ISOGB01 in /PRMD=ISOCOR/ADMD=Eirmail400/C=IE; relayed; 23 Apr 1999 16:27:09 +0100
To: [email-masked]
Subject: RE: SMTP AUTH implementations?
X400-MTS-Identifier: [/PRMD=ISOCOR/ADMD=Eirmail400/C=IE;ISOCOR-36e14ab8-isogb01]
X400-Content-Identifier: RE: SMTP AUTH im
Date: 23 Apr 1999 16:26:54 +0100
Importance: normal
Autoforwarded: false
Sender: [email-masked]

Hello Nelson
We (ISOCOR) have implemented server side.
Up and running on our live N-PLEX Global servers (if version number reported begins with 4).
We have tested against a few - including Netscape Communicator 4.5
[is the source for that up on Mozilla?]

Once you have something ready to test then feel free to give us a shout.

Rgds
Paul Webster - ISOCOR UK
http://www.isocor.com
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 21 April 1999 21:11
To: [email-masked]
Subject: SMTP AUTH implementations?

Hi -

Thanks,
--Nelson

Date: Wed, 21 Apr 1999 11:59:44 -0700 (PDT)
From: Nelson Tang <[email-masked]>
To: [email-masked]
Subject: SMTP AUTH implementations?
Sender: [email-masked]

Hi -

Thanks,
--Nelson