Subject: Re: [lemonade] update to RFC 1845 checkpoint/restart
From: Dave Cridland <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: Enhancements to Internet email to support diverse service enivronments <[email-masked]>, <[email-masked]>
Date: Wed, 15 Mar 2006 23:33:36 +0000
List-Id: <ietf-smtp.imc.org>

On Wed Mar 15 19:52:14 2006, Tony Finch wrote:
> > > The REPLAY spec is currently weak in descibing the line between 
> a retry
> > > and a replay. For example, the 555 response to MAIL would be 
> better as a
> > > 455 that would cause the client to retry with a new transaction 
> (i.e. a
> > > fresh <txn-id>). The corresponding situation with an improved 
> CHUNKING
> > > would be an unexpected 355 response. The problem here is what 
> happens if
> > > the client has pipelined some data after the erroneous command?
> >
> > I don't follow all of this.
> 
> I'm worried about transaction ID collisions, which I suppose are 
> most
> likely to be caused by a client going insane (unless someone 
> manages to
> successfully attack a client's txn-id generation algorithm). At the 
> moment
> the replay spec makes this problem detectable by the 555 response 
> to MAIL
> (though I plan to change this to 455). Checkpoint assumes this 
> situation
> is OK since it looks to the server like a normal transaction 
> restart.
> 
> 
Right, gotcha.

You're saying that in the case where a transaction id collides, or, 
for some reason, the client thinks it's sending the transaction anew 
instead of resuming, then there's a problem here that 1845 missed 
because of the lack of pipelining.

A solution is to state that use of TRANSID= denotes either resumption 
or new, and the client must wait for the response unless it knows 
what it will be in advance (by having previously issued a REPLAY 
command and examined the response). Then add an additional parameter 
which indicates to the server that the TRANSID is expected to be 
fresh, and if not, to reject this transaction. (Perhaps a  
TRANSID-NEW assertion parameter)

This means that RFC1845bis (ie, this spec) clients use:

MAIL FROM:<[email-masked]> TRANSID=xyz TRANSID-NEW

for starting a new transaction, and do not need to synchronize, 
whereas RFC1845 clients don't use the additional parameter, but do 
synchronize.

That handles the collision case, but the case where two clients 
simultaneously attempt to resume a TRANSID, is much more difficult to 
deal with.

You could define REPLAY as an assertion that subsequent usage of this 
TRANSID in a MAIL command in this session is a resumption, which 
prevents accidental duplication, and then you merely have to deal 
with failing DATA, BDAT, and BURL commands if a TRANSID is resumed by 
another session. (And, one assumes noting this in logs or to the 
sender as a possible bug or security issue.)

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 15 Mar 2006 19:52:14 +0000
From: Tony Finch <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Tony Finch <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>, [email-masked]
Subject: Re: [lemonade] update to RFC 1845 checkpoint/restart
Sender: [email-masked]

> > The REPLAY spec is currently weak in descibing the line between a retry
> > and a replay. For example, the 555 response to MAIL would be better as a
> > 455 that would cause the client to retry with a new transaction (i.e. a
> > fresh <txn-id>). The corresponding situation with an improved CHUNKING
> > would be an unexpected 355 response. The problem here is what happens if
> > the client has pipelined some data after the erroneous command?
>
> I don't follow all of this.

I'm worried about transaction ID collisions, which I suppose are most
likely to be caused by a client going insane (unless someone manages to
successfully attack a client's txn-id generation algorithm). At the moment
the replay spec makes this problem detectable by the 555 response to MAIL
(though I plan to change this to 455). Checkpoint assumes this situation
is OK since it looks to the server like a normal transaction restart.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOLE LUNDY FASTNET SOUTH IRISH SEA: EAST 4 OR 5, OCCASIONALLY 6 LATER.
SHOWERS, BECOMING WINTRY FOR A TIME. MODERATE OR GOOD, OCCASIONALLY POOR AT
FIRST.

Date: Wed, 15 Mar 2006 16:46:10 +0000
Subject: Re: [lemonade] update to RFC 1845 checkpoint/restart
From: Dave Cridland <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: Enhancements to Internet email to support diverse service enivronments <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Wed Mar 15 15:37:25 2006, Tony Finch wrote:
> On Wed, 15 Mar 2006, Dave Cridland wrote:
> 
> Thanks for your comments.
> 
> 
Pleasure. RFC1845 has a lot to offer, I think.

> The REPLAY spec is currently weak in descibing the line between a 
> retry
> and a replay. For example, the 555 response to MAIL would be better 
> as a
> 455 that would cause the client to retry with a new transaction 
> (i.e. a
> fresh <txn-id>). The corresponding situation with an improved 
> CHUNKING
> would be an unexpected 355 response. The problem here is what 
> happens if
> the client has pipelined some data after the erroneous command?
> 
> 
I don't follow all of this.

> > 5) The syntax of REPLAY means that the syntax of txn-id is not 
> accurate as
> > given in section 6. A txn-id MUST NOT be "CLEAR", in particular. 
> The syntax of
> > REPLAY is, in my opinion, quite ugly as a result.
> 
> Perhaps it should be a separate command. I also considered making 
> the
> transaction log clearing implicit, when the server sees a QUIT from 
> the
> client. But what commend to use when the client wants to leave the
> connection idle waiting for new messages? EHLO?
> 
> 
No, because EHLO is already mandated as being a noisier RSET. I think 
a new command, or else changing the syntax of REPLAY. I have no 
preference as to which.

> > 6) There's no mention here of BURL.
> >
> > a) An octet-offset provided by the server MUST NOT point into a 
> BURL chunk.
> > BURL chunks MUST be appended atomically.
> 
> Yes, that's a sound suggestion.
> 
> 
It's by far the simplest.

> > b) For BURL and BDAT commands, an additional parameter could be 
> defined, which
> > could then be send in lieu of, or in addition to, the octet-count 
> by the
> > server, thus providing for the (rare) case where a client cannot 
> know the
> > octet count of a BURL chunk without downloading it.
> 
> Perhaps a chunk count as well as an octet count? There would have 
> to be an
> octet offset within the chunk, so that the chunk count and chunk 
> offset
> together mean the same thing as the octet offset. I'll see if I can 
> think
> of a good way of specifying it. I'm wary because its in danger of 
> getting
> a bit complicated.
> 
> 
Yes, that would be complicated.

FWIW, I can only think of one case where the length of a resource is 
likely to be unknown, and that's the case where the client only has 
the URLAUTH URL. That said, the only case I can think of for that 
involves Alice granting Bob read access to a message via URLAUTH, and 
Bob using an ESMTP send with BURL in order to copy the message to his 
IMAP server in order to read it efficiently. That is a somewhat 
contrived use-case.

I'd be happy to see the entire problem noted and subsequently ignored.

> > 7) Your description of how to send no data with DATA is 
> incorrect, it's
> > actually DATA<CRLF><wait for 354><CRLF>.<CRLF>
> 
> That's two octets of data (a blank line), not zero :-) but I should
> mention the wait for 354. cf. the text about a "single dot" in 
> RFC2920.

(This is "below") Ah, I sit corrected. I'd previously somehow misread 
RFC2821 section 4.1.1.4 para 2 as saying the exact opposite of what 
it does say. I have no idea how I misread that. This makes things 
much easier, and of course eliminates my point 3.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 15 Mar 2006 15:37:25 +0000
From: Tony Finch <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Tony Finch <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>, [email-masked]
Subject: Re: [lemonade] update to RFC 1845 checkpoint/restart
Sender: [email-masked]

On Wed, 15 Mar 2006, Dave Cridland wrote:

Thanks for your comments.

> 1) Why have a distinct response 255 instead of 355 <length of complete
> message>? A client's behaviour is likely to be the same, and
> semantically, there is no difference.

I vacillated a bit here - at one point the spec also had a 555 response
instead of 355 0. You are probably right that 255 is also redundant.

> 2) This specification is needlessly not compatible with RFC1845 on a
> number of points. I can't see why this needs to be so.
>
> 4) Section 9, first para, is an example of (2).

Hmm, yes, I suppose it might be possible (and desirable) to be backwards
compatible.

The REPLAY spec is currently weak in descibing the line between a retry
and a replay. For example, the 555 response to MAIL would be better as a
455 that would cause the client to retry with a new transaction (i.e. a
fresh <txn-id>). The corresponding situation with an improved CHUNKING
would be an unexpected 355 response. The problem here is what happens if
the client has pipelined some data after the erroneous command?

> 3) The DATA offset restriction (beginning of a line) is problematic because it
> forces a server to store the message one entire line in arrears, because of
> the multi-line termination of the data transmission with DATA. This is
> probably required, in order to gain compatibility with RFC1845, but it needs
> to be pointed out.

I'm not sure it's necessary to be a line in arrears. You can store each
line as you receive it, until you get a line containing just a dot. You
only need a one-line window.

> 5) The syntax of REPLAY means that the syntax of txn-id is not accurate as
> given in section 6. A txn-id MUST NOT be "CLEAR", in particular. The syntax of
> REPLAY is, in my opinion, quite ugly as a result.

Perhaps it should be a separate command. I also considered making the
transaction log clearing implicit, when the server sees a QUIT from the
client. But what commend to use when the client wants to leave the
connection idle waiting for new messages? EHLO?

> 6) There's no mention here of BURL.
>
> a) An octet-offset provided by the server MUST NOT point into a BURL chunk.
> BURL chunks MUST be appended atomically.

Yes, that's a sound suggestion.

> b) For BURL and BDAT commands, an additional parameter could be defined, which
> could then be send in lieu of, or in addition to, the octet-count by the
> server, thus providing for the (rare) case where a client cannot know the
> octet count of a BURL chunk without downloading it.

Perhaps a chunk count as well as an octet count? There would have to be an
octet offset within the chunk, so that the chunk count and chunk offset
together mean the same thing as the octet offset. I'll see if I can think
of a good way of specifying it. I'm wary because its in danger of getting
a bit complicated.

> 7) Your description of how to send no data with DATA is incorrect, it's
> actually DATA<CRLF><wait for 354><CRLF>.<CRLF>

That's two octets of data (a blank line), not zero :-) but I should
mention the wait for 354. cf. the text about a "single dot" in RFC2920.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
NITON: A DEPRESSION MOVING EAST INTO TRAFALGAR WILL GENERATE STRONG EASTERLY
WINDS IN ALL AREAS DURING FRIDAY, PERHAPS GALE FORCE IN NORTH FITZROY, SOLE
AND SHANNON.

Date: Wed, 15 Mar 2006 15:11:11 +0000
Subject: Re: [lemonade] update to RFC 1845 checkpoint/restart
From: Dave Cridland <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: Enhancements to Internet email to support diverse service enivronments <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Wed Mar 15 04:46:06 2006, Tony Finch wrote:
> http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-replay.html

Comments, in no particular order:

1) Why have a distinct response 255 instead of 355 <length of 
complete message>? A client's behaviour is likely to be the same, and 
semantically, there is no difference.

2) This specification is needlessly not compatible with RFC1845 on a 
number of points. I can't see why this needs to be so.

3) The DATA offset restriction (beginning of a line) is problematic 
because it forces a server to store the message one entire line in 
arrears, because of the multi-line termination of the data 
transmission with DATA. This is probably required, in order to gain 
compatibility with RFC1845, but it needs to be pointed out.

4) Section 9, first para, is an example of (2).

5) The syntax of REPLAY means that the syntax of txn-id is not 
accurate as given in section 6. A txn-id MUST NOT be "CLEAR", in 
particular. The syntax of REPLAY is, in my opinion, quite ugly as a 
result.

6) There's no mention here of BURL.

a) An octet-offset provided by the server MUST NOT point into a BURL 
chunk. BURL chunks MUST be appended atomically.

b) For BURL and BDAT commands, an additional parameter could be 
defined, which could then be send in lieu of, or in addition to, the 
octet-count by the server, thus providing for the (rare) case where a 
client cannot know the octet count of a BURL chunk without 
downloading it.

7) Your description of how to send no data with DATA is incorrect, 
it's actually DATA<CRLF><wait for 354><CRLF>.<CRLF>

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 15 Mar 2006 04:46:06 +0000
From: Tony Finch <[email-masked]>
To: [email-masked], [email-masked]
Subject: update to RFC 1845 checkpoint/restart
Sender: [email-masked]

A few weeks ago I started a discussion on the lemonade list about
efficient message transmission using a combination of PIPELINING and
CHUNKING. I've since written a draft which addresses the increased risk of
message duplication which can occur with fully-pipelined message
transmission. The meat of it is a more pipelinable version of RFC 1845
checkpoint/restart. The gravy is a few sections of rationale...

http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-replay.html

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
NITON: A DEPRESSION MOVING EAST INTO TRAFALGAR WILL GENERATE STRONG EASTERLY
WINDS IN ALL AREAS DURING FRIDAY, PERHAPS GALE FORCE IN NORTH FITZROY, SOLE
AND SHANNON.

Date: Mon, 13 Mar 2006 08:12:06 -0500
From: John C Klensin <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: [email-masked]
Subject: Re: LISTSERV (or equivalent) source code and documentation, pre-1991
Sender: [email-masked]

--On Sunday, 12 March, 2006 13:02 -0800 Dave Crocker
<[email-masked]> wrote:

> John,
> 
>>   The
>> second was Eric Thomas's "Revised LISTSERV" -- a complete
>> rewrite, preserving only some concepts and syntax.  That is
>> probably the one you are thinking of.  Eric is, as far as I
>> know, still around and selling a descendant of that code as a
>> commercial product and service.  My memory is fading, but I
>> don't believe Eric's code has ever been public.
> 
> 
> Sorry for being unclear.  Yes, I mean Eric's version. (Or any
> equivalent functionality.)
> 
> I had already checked with him. Even HE does not know where
> any early versions are, but he believes that the source code
> was widely distributed.
> 
> Certainly the documentation was.

Indeed, given that sending "help" commands to the thing could
easily bury one in documentation.   I may have those
documentation files around somewhere, but it would require
considerable digging; we should have an offline conversation if
you want me to try doing that.  I believe that the source was
distributed.  However, Eric was, if I recall, proprietary enough
about it from a fairly early date, my observation about "not
public" still applies.  Because LISTSERV was a key BITNET
facility, if I wanted to find code, I'd check with Educause
(then Educom), any vestiges of CREN you can find around, and the
universities that were running large versions of the thing with
many lists: Cornell, CUNY, and Princeton come immediately to
mind as likely candidates, as are several institutions in France
and Germany.

    john

Cc: [email-masked], [email-masked]
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Subject: Re: LISTSERV (or equivalent) source code and documentation, pre-1991
Date: Sun, 12 Mar 2006 22:09:18 -0800
To: John C Klensin <[email-masked]>
Sender: [email-masked]

On 12 mar 2006, at 12.55, John C Klensin wrote:

> Eric is, as far as I
> know, still around and selling a descendant of that code as a
> commercial product and service.  My memory is fading, but I
> don't believe Eric's code has ever been public.

Correct in both cases. http://www.lsoft.com/

    paf

Cc: [email-masked]
To: Dave Crocker <[email-masked]>
Date: Sun, 12 Mar 2006 14:04:14 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: LISTSERV (or equivalent) source code and documentation, pre-1991
Sender: [email-masked]

> I'm in search of source code and manuals for LISTSERV, or equivalent
> functionality, prior to 1991.

Exactly what "equivalent functionality" are you looking for? LISTSERV did a
bunch of stuff, including returning files in response to mailed in requests,
maintaining mailing lists, operating in tandem with other LISTSERVs elsewhere,
and probably some other stuff I no longer recall. There were a bunch of other
packages around back then but they differed somewhat in the functionality they
offered, and AFAIK none of them did the tandem operation stuff LISTSERV did.

> In spite of LISTSERV's survival, its early code is proving quite difficult to
> find.

The PMDF MAILSERV channel was, according to the copyright on the code,
originally written in 1989. This is from the PMDF V4.3 (ca 1994) version I have
online:

(*      Author:    Eric Thies ([email-masked])                 *)
(*                 University of North Carolina at Greensboro      *)
(*                 January 1989                                    *)
(*                                                                 *)
(*      Rewritten by: Ned Freed ([email-masked])                 *)
(*                    Innosoft International, Inc.                 *)
(*                    December 1991                                *)

MAILSERV did the file distribution and list maintenance stuff but didn't handle
actual list expansion - it relied on PMDF's own expansion facilities for that.
(Basically it edited the files the list membership was stored in.) Of course it
didn't do any of the distributed stuff.

The source for V5.2 and earlier versions is in Pascal. I don't have versions
before V4.3 online and as a result I don't know exactly what functionality was
added when. (I'm not sure sources for versions prior to 4.3 exist any more -
and if they do they're probably on 9-track tape somewhere in Iron Mountain that
may or may not be readable at this point.)

I do have the original AAAREADME.TXT file for MAILSERV that Eric Thies sent me
on Wed, 18 Jan 89 20:03 EST. I also have a bunch of correspondence about the
development of this code, some private, some from the info-pmdf list.

As for printed manuals, I was responsible for PMDF documentation up to V3.0 (ca
1988) and I have hard copy of all of those in my files. After that Kristin
Hubner took over (this was around the time Innosoft took over development of
PMDF) so I don't have copies of the 4.0-4.2 manuals that would be relevant
here. They probably do exist, however - somewhere in Iron Mountain... Theory
says they can be retrieved if need be.

Does any of this help?

				Ned

Date: Sun, 12 Mar 2006 13:02:51 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: LISTSERV (or equivalent) source code and documentation, pre-1991
Sender: [email-masked]

John,

>   The
> second was Eric Thomas's "Revised LISTSERV" -- a complete
> rewrite, preserving only some concepts and syntax.  That is
> probably the one you are thinking of.  Eric is, as far as I
> know, still around and selling a descendant of that code as a
> commercial product and service.  My memory is fading, but I
> don't believe Eric's code has ever been public.

Sorry for being unclear.  Yes, I mean Eric's version. (Or any equivalent 
functionality.)

I had already checked with him. Even HE does not know where any early versions 
are, but he believes that the source code was widely distributed.

Certainly the documentation was.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

Date: Sun, 12 Mar 2006 15:55:36 -0500
From: John C Klensin <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: LISTSERV (or equivalent) source code and documentation, pre-1991
Sender: [email-masked]

--On Sunday, 12 March, 2006 11:59 -0800 Dave Crocker
<[email-masked]> wrote:

> Howdy.
> 
> I'm in search of source code and manuals for LISTSERV, or
> equivalent functionality, prior to 1991.
> 
> In spite of LISTSERV's survival, its early code is proving
> quite difficult to find.

Dave, there were two things called LISTSERV in early BITNET
context.  The earlier one was done by Hank Nussbacker.  I think
I have that code somewhere and think I could find him and get
permission to give it to you (assuming I could find it).  The
second was Eric Thomas's "Revised LISTSERV" -- a complete
rewrite, preserving only some concepts and syntax.  That is
probably the one you are thinking of.  Eric is, as far as I
know, still around and selling a descendant of that code as a
commercial product and service.  My memory is fading, but I
don't believe Eric's code has ever been public.

FWIW, both are, IIR, written largely in REXX.

     john

> 
> Thanks.
> 
> d/

Date: Sun, 12 Mar 2006 11:59:56 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: LISTSERV (or equivalent) source code and documentation, pre-1991
Sender: [email-masked]

Howdy.

I'm in search of source code and manuals for LISTSERV, or equivalent 
functionality, prior to 1991.

In spite of LISTSERV's survival, its early code is proving quite difficult to find.

Thanks.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: FW: I-D ACTION:draft-vaudreuil-esmtp-binary3-02.txt 
Date: Fri, 10 Mar 2006 15:10:58 -0600
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C64487.1F5BDF8A
Content-Type: text/plain;
	charset="iso-8859-1"

FYI.

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 10, 2006 3:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-vaudreuil-esmtp-binary3-02.txt 

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

	Title		: SMTP Service Extensions for Transmission of Large and Binary MIME Messages
	Author(s)	: G. Vaudreuil
	Filename	: draft-vaudreuil-esmtp-binary3-02.txt
	Pages		: 12
	Date		: 2006-3-10
	
This memo defines two extensions to the SMTP service.  The first 
extension enables a SMTP client and server to negotiate the use of an 
alternative to the DATA command, called "BDAT", for efficiently 
sending large MIME messages.  The second extension takes advantage of 
the BDAT command to permit the negotiated sending of MIME messages 
that employ the binary transfer encoding. This document is intended to 
obsolete RFC 3030.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-vaudreuil-esmtp-binary3-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-vaudreuil-esmtp-binary3-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_000_01C64487.1F5BDF8A
Content-Type: message/rfc822

To: 
Subject: 
Date: Fri, 10 Mar 2006 14:52:25 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C64487.1F5BDF8A"

------_=_NextPart_002_01C64487.1F5BDF8A
Content-Type: text/plain

------_=_NextPart_002_01C64487.1F5BDF8A
Content-Type: application/octet-stream;
	name="ATT47258"
Content-Disposition: attachment;
	filename="ATT47258"

Content-type: message/external-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-vaudreuil-esmtp-binary3-02.txt

------_=_NextPart_002_01C64487.1F5BDF8A
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-vaudreuil-esmtp-binary3-02.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"

------_=_NextPart_002_01C64487.1F5BDF8A--

------_=_NextPart_000_01C64487.1F5BDF8A
Content-Type: text/plain;
	name="ATT4725845.txt"
Content-Disposition: attachment;
	filename="ATT4725845.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

------_=_NextPart_000_01C64487.1F5BDF8A--

Date: Thu, 9 Mar 2006 16:22:00 -0800
To: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: [lemonade] Re: PIPELINING and failed recipients
Cc: [email-masked]
Sender: [email-masked]

At 12:28 AM -0500 3/7/06, Robert A. Rosenberg wrote:

>  At 15:40 -0800 on 03/06/2006, Randall Gellens wrote about 
> [lemonade] Re: PIPELINING and failed recipients:

That attribution is misleading, since I was quoting a message from 
Tony Finch, I think.

>>   >   One advantage of a sync point
>>>    after the message envelope is that the client can decide not to 
>>> proceed if
>>>    a subset of the recipients are rejected; this doesn't work if 
>>> the envelope
>>>    and data are pipelined. (It is also limited by how strongly the 
>>> server can
>>>    verify addresses.) What do you think of having a NOPARTFAIL parameter to
>>>    the MAIL command, which means that the client is asking the server to
>>>    reject the message data if any of the recipients are rejected - "no
>>   >  partial failure".
>
>  If I am sending a multi-addressed message, I would like the ability 
> (even if pipelining) to get a response stating if each recipient 
> was accepted or not, and have the MUA requeue the message with all 
> the rejected addresses while allowing the message to get sent with 
> the valid addresses. IOW: Leave it as "failed" as presently occurs 
> if it can not get sent BUT remove the accepted addresses so the 
> failed version only contains the rejected addresses.

I am not sure what you are saying.  Are you asking that clients be 
written to behave in a specific way regarding a message where some 
recipients are rejected by the submission server?

Currently, clients can choose which behavior to support: immediate 
send to good recipients, or hold message in abeyance and alert user, 
who can either correct or delete the bad rejected recipients.

No one has suggested anything that would force the client to choose 
one way or the other.

An extension such as "NOBADRCPT" (or "ABORTONBADRCPT" or 
"ERRONBADRCPT") would allow the client to behave in either way.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
"SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of
San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle

Date: Tue, 7 Mar 2006 00:28:08 -0500
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: [lemonade] Re: PIPELINING and failed recipients
Cc: [email-masked]
Sender: [email-masked]

At 15:40 -0800 on 03/06/2006, Randall Gellens wrote about [lemonade] 
Re: PIPELINING and failed recipients:

>  >   One advantage of a sync point
>>   after the message envelope is that the client can decide not to proceed if
>>   a subset of the recipients are rejected; this doesn't work if the envelope
>>   and data are pipelined. (It is also limited by how strongly the server can
>>   verify addresses.) What do you think of having a NOPARTFAIL parameter to
>>   the MAIL command, which means that the client is asking the server to
>>   reject the message data if any of the recipients are rejected - "no
>  >  partial failure".

If I am sending a multi-addressed message, I would like the ability 
(even if pipelining) to get a response stating if each recipient was 
accepted or not, and have the MUA requeue the message with all the 
rejected addresses while allowing the message to get sent with the 
valid addresses. IOW: Leave it as "failed" as presently occurs if it 
can not get sent BUT remove the accepted addresses so the failed 
version only contains the rejected addresses.

Date: Mon, 6 Mar 2006 15:40:23 -0800
To: [email-masked], [email-masked]
From: Randall Gellens <[email-masked]>
Subject: [lemonade] Re: PIPELINING and failed recipients
Cc: Ned Freed <[email-masked]>, Chris Newman <[email-masked]>
Sender: [email-masked]

At 1:22 PM +0000 2/23/06, Tony Finch wrote:

>  I think both Ned and Dave mentioned the irritation that can arise from a
>  message and receiving a bounce for some of the recipients. (Note to self:
>  [email-masked] is the wrong address).

It's [email-masked].

>   One advantage of a sync point
>  after the message envelope is that the client can decide not to proceed if
>  a subset of the recipients are rejected; this doesn't work if the envelope
>  and data are pipelined. (It is also limited by how strongly the server can
>  verify addresses.) What do you think of having a NOPARTFAIL parameter to
>  the MAIL command, which means that the client is asking the server to
>  reject the message data if any of the recipients are rejected - "no
>  partial failure".

Perhaps "NOBADRCPT" or my earlier suggestion of "ABORTONBADRCPT".

Maybe "ERRONBADRCPT"?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
When a man's best friend is his dog, that dog has a problem.
                                             --Edward Abbey

Date: Mon, 6 Mar 2006 15:40:13 -0800
To: [email-masked], [email-masked]
From: Randall Gellens <[email-masked]>
Subject: [lemonade] Re: PIPELINING, AUTH, and CHUNKING
Sender: [email-masked]

At 12:56 PM +0000 2/23/06, Tony Finch wrote:

>  The BURL spec requires a sync point after the "LAST" BDAT or BURL command,
>  instead of after the message envelope. I think it would be better for BDAT
>  and BURL to not require any synchronization at all: if the client wants a
>  sync, it can use the NOOP command. Note that the main reason a sync point
>  is required after DATA is so that the client and server agree about
>  whether the next utterance from the client is a command or is message
>  data. This isn't a problem for BDAT because the command and data are sent
>  together, with a single response from the server for both.
>
>  This would allow a client to pipeline multiple messages together, which
>  means you can move from using TCP in interactive mode to bulk data mode,
>  and therefore make the best use of the available bandwidth. For example,
>  consider a 1Mb/s link with a 100ms RTT. If the client sends a 5KB message,
>  this takes about 50ms to transmit, so by the time the server's replies
>  arrive the client will be one or two messages further on; if there was a
>  problem, the client can deal with it asynchronously, and it will have done
>  50ms extra useful work. If the client sends a 20KB message, the server's
>  replies will start arriving part-way through message transmission, so if
>  there is a problem the client can usefully RSET it before the next chunk
>  to save time and bandwidth.
>
>  I think it would be cool to allow this kind of high-bandwidth asynchronous
>  message transmission. It is also more friendly from the point of
>  congestion control than having multiple concurrent SMTP connections
>  perpetually in TCP slow start.

Interesting.  Both mobile and desktop clients often send multiple messages.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
"The meat is rotten, but the booze is holding out."
--alleged computer translation of "The spirit is willing,
  but the flesh is weak."

Date: Mon, 6 Mar 2006 15:39:45 -0800
To: [email-masked], [email-masked]
From: Randall Gellens <[email-masked]>
Subject: [lemonade] Re: PIPELINING, AUTH, and CHUNKING
Sender: [email-masked]

At 12:56 PM +0000 2/23/06, Tony Finch wrote:

>  For example, it's common to have dual-purpose MSA
>  and MX servers which operate in MSA mode after AUTH and MX mode otherwise.
>  If the client pipelines an AUTH and an intended submission, but the auth
>  fails, bad things will happen - recipients will be rejected that would
>  have been OK, an incomplete message will suffer an anti-spam penalty
>  instead of being fixed up, etc.

Another reason to stop running dual-purpose servers on port 25, and 
restrict 25 to message relay, and use port 587 for message 
submission.  It makes the client's intent much more clear.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
"Contrariwise," continued Tweedledee, "if it was so, it might
be, and if it were so, it would be; but as it isn't, it ain't. That's
logic!"