Subject: ehlo-ok-rsp
From: "Richard O. Hammer" <[email-masked]>
To: [email-masked]
Date: Tue, 23 Dec 2003 11:55:13 -0500
List-Id: <ietf-smtp.imc.org>

It looks to me like there is a space (SP) missing in the ABNF for 
ehlo-ok-rsp.  Here from  RFC 2821:

       ehlo-ok-rsp  =    ( "250"    domain [ SP ehlo-greet ] CRLF )
                    / (    "250-"   domain [ SP ehlo-greet ] CRLF
                        *( "250-"   ehlo-line                CRLF )
                           "250"    SP ehlo-line             CRLF  )

For a single-line response I suppose there should be a space between 
the 250 and the domain.  But this seems to say that a single-line 
response would look like this:
    250hogHeaven.org welcome

Is this list the place where I should raise such issues?

Rich Hammer
Hillsborough, N.C.

To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-ngtrans-ipv6-smtp-requirement-07.txt
Date: Mon, 15 Dec 2003 09:15:20 +0900 (JST)
From: [email-masked] (Jun-ichiro itojun Hagino)
Sender: [email-masked]

> > Personal opinion: I believe the document will have more impact if 
> > published separately from the revision to RFC 2821.  I also believe that 
> > tying this to the revision of RFC 2821 would significantly delay a 
> > published specification for how to use SMTP in the IPv6 world.
> I agree completely -- get it out there as its own RFC. Anything appropriate for 
> 2821bis can be added whenever that draft starts circulating.

	ok, i see the point.  then question to the ADs - is the current draft
	sufficient, or it sill need fixing?  (i know it's holiday season
	over there already so no need to hurry)

itojun

Date: Sat, 13 Dec 2003 20:17:01 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-ngtrans-ipv6-smtp-requirement-07.txt
Sender: [email-masked]

I agree completely -- get it out there as its own RFC. Anything appropriate for 
2821bis can be added whenever that draft starts circulating.

	Tony Hansen
	[email-masked]

Keith Moore wrote:
> Personal opinion: I believe the document will have more impact if 
> published separately from the revision to RFC 2821.  I also believe that 
> tying this to the revision of RFC 2821 would significantly delay a 
> published specification for how to use SMTP in the IPv6 world.
> 
> On Dec 10, 2003, at 10:47 PM, Jun-ichiro itojun Hagino wrote:
>>>     an updated version of draft-ietf-ngtrans-ipv6-smtp-requirement
>>>     is attached.
>>>
>>>     to ADs: it may not reflect all the coments i have received, but 
>>> anyways
>>>     better than nothing.  i think it should really be integrated into
>>>     update to RFC2821 (instead of being standalone document).
>>>     it is still using "ngtrans" in the name, however, it is suggested 
>>> that
>>>     the document should be discussed in APP area (there's no 
>>> email-related
>>>     WG exist at this point).
>>
>>     ADs: let me know how to proceed on this document.  should we propose
>>     changes to RFC2821, or?  tnx.

Cc: Keith Moore <[email-masked]>, John C Klensin <[email-masked]>, [email-masked], Ned Freed <[email-masked]>, Pete Resnick <[email-masked]>, Chris Newman <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: draft-ietf-ngtrans-ipv6-smtp-requirement-07.txt
Date: Sat, 13 Dec 2003 07:34:25 -0500
To: [email-masked] (Jun-ichiro itojun Hagino)
Sender: [email-masked]

Personal opinion: I believe the document will have more impact if 
published separately from the revision to RFC 2821.  I also believe 
that tying this to the revision of RFC 2821 would significantly delay a 
published specification for how to use SMTP in the IPv6 world.

On Dec 10, 2003, at 10:47 PM, Jun-ichiro itojun Hagino wrote:

>
>> 	an updated version of draft-ietf-ngtrans-ipv6-smtp-requirement
>> 	is attached.
>>
>> 	to ADs: it may not reflect all the coments i have received, but 
>> anyways
>> 	better than nothing.  i think it should really be integrated into
>> 	update to RFC2821 (instead of being standalone document).
>> 	it is still using "ngtrans" in the name, however, it is suggested 
>> that
>> 	the document should be discussed in APP area (there's no 
>> email-related
>> 	WG exist at this point).
>
> 	ADs: let me know how to proceed on this document.  should we propose
> 	changes to RFC2821, or?  tnx.
>
> itojun

To: John C Klensin <[email-masked]>, [email-masked], Ned Freed <[email-masked]>, Pete Resnick <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-ngtrans-ipv6-smtp-requirement-07.txt
Date: Thu, 11 Dec 2003 12:47:13 +0900 (JST)
From: [email-masked] (Jun-ichiro itojun Hagino)
Sender: [email-masked]

> 	an updated version of draft-ietf-ngtrans-ipv6-smtp-requirement
> 	is attached.
> 
> 	to ADs: it may not reflect all the coments i have received, but anyways
> 	better than nothing.  i think it should really be integrated into
> 	update to RFC2821 (instead of being standalone document).
> 	it is still using "ngtrans" in the name, however, it is suggested that
> 	the document should be discussed in APP area (there's no email-related
> 	WG exist at this point).

	ADs: let me know how to proceed on this document.  should we propose
	changes to RFC2821, or?  tnx.

itojun

Date: Mon, 8 Dec 2003 11:23:20 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-rfc2554bis-02.txt (fwd)
Sender: [email-masked]

On Sun, 7 Dec 2003, Arnt Gulbrandsen wrote:

> I've been told that digest-md5 can be implemented without storing
> cleartext passwords. Is that correct? I found an expired draft which
> suggests that it's true in some circumstances (when the realm is not
> sensitive).

As far as I know, the non-plaintext versions of DIGEST-MD5 secrets are
plaintext-equivalent for the realm in question.  So, if the password file
is compromised, then that entire realm is compromised immediately, but
the vulnerability ends at that realm (other realms with the same password
are not compromised).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-siemborski-rfc2554bis-02.txt (fwd)
Date: Sun, 7 Dec 2003 16:06:02 +0100
Sender: [email-masked]

Rob Siemborski writes:
> The most controversial issue I've hit so far is the choice of a 
> mandatory-to-implement (at a minimum level) SASL mechanism. From the 
> people I've talked to, it seems that the choice of DIGEST-MD5 is more 
> popular than the choice (that IMAP made) of STARTTLS+PLAIN, so that's 
> where the document currently stands.

I've been told that digest-md5 can be implemented without storing 
cleartext passwords. Is that correct? I found an expired draft which 
suggests that it's true in some circumstances (when the realm is not 
sensitive).

If that's correct, then I think DIGEST-MD5 is an excellent choice. No 
cleartext on the wire, often no cleartext on the server, and the client 
need not trust the server.

I like it.

For example, suppose a user already has logged in to an IMAP or POP 
server, then sends some mail, and the SMTP server challenges the client 
to produce credentials.

With DIGEST-MD5 the client can try a response immediately, based on the 
IMAP/POP password. If it's the right one, the user did not have to 
retype the password (possibly in front of company). If it's wrong, the 
SMTP client hasn't revealed the user's password.

Very good.

--Arnt

Date: Fri, 5 Dec 2003 15:50:08 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-siemborski-rfc2554bis-02.txt (fwd)
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--NextPart
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

Hi,

This is the most recent version of a revsion I've been working on to
RFC2554.  This came out of some discussions I had with others about
problems in the current spec (mostly based around lack of clarity on
the handling of the MAIL FROM AUTH= parameter and the initial client
response).

I'd like to hear some comments on it from a wider audience.

The most controversial issue I've hit so far is the choice of a
mandatory-to-implement (at a minimum level) SASL mechanism.  From the
people I've talked to, it seems that the choice of DIGEST-MD5 is more
popular than the choice (that IMAP made) of STARTTLS+PLAIN, so that's
where the document currently stands.

Please send comments to the list.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

---------- Forwarded message ----------
Date: Fri, 05 Dec 2003 15:29:09 -0500
From: [email-masked]
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-siemborski-rfc2554bis-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SMTP Service Extension for Authentication
	Author(s)	: R. Siemborski
	Filename	: draft-siemborski-rfc2554bis-02.txt
	Pages		: 18
	Date		: 2003-12-5

This document defines a Simple Mail Transport Protocol (SMTP)
extension whereby an SMTP client may indicate an authentication
mechanism to the server, perform an authentication protocol
exchange, and optionally negotiate a security layer for subsequent
protocol interactions during this session.	This extension includes
a profile of the Simple Authentication and Security Layer (SASL) for
SMTP.

This document obsoletes RFC 2554 and replaces it as a Proposed
Standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-siemborski-rfc2554bis-02.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-siemborski-rfc2554bis-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-siemborski-rfc2554bis-02.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess
Content-ID: <[email-masked]>
Content-Description: 

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="[email-masked]"
Content-ID: <[email-masked]>

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-siemborski-rfc2554bis-02.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--