greg.vaudreuil | 2 Aug 02:32 1994

WG Last Call: Binary SMTP


     At the last meeting of the IETF mail extensions working group, I took 
     an action to initiate a 4 week working group last call period for this 
     SMTP binary extension.

     The document is in the Internet-Drafts directories as 
     <draft-vaudreuil-smtp-binary-04.txt>.  It will be reposted as an 
     Internet draft under the filename <draft-mailext-smtp-binary-04.txt>

     The working group discussed this proposal and identified no problems.  
     However, there was an insufficient people present who felt competent 
     to fully approve this document, and a last mailing list review was 
     requested.  Please give this document a final once-over (or twice) and 
     send comments.  There is already one implementation of this protocol 
     extension. 

     Greg V.

Stephen J Berch | 6 Aug 01:54 1994
Picon
Picon

Scripts to send amil through SMTP


When I try and write a script to send mail through smtp the telnet 
session closes without the mail going through. What I've tried to do is 
write all the commands and information for the mail and smtp into a file 
and then pipe the file into the telnet session, like this:

     telnet mailhost 25 < mailfile > /dev/nul

The mailfile has HELO, mailfrom: , rcpt to: , data , text, followed by CR 
. CR, and quit. 

Can anyone offer hints or instructions to make this work? Guidance 
appreciated.

Steve

Keith Moore | 9 Aug 20:27 1994
Picon

Re: WG Last Call: Binary SMTP

Greg writes (to ietf-smtp):

>     At the last meeting of the IETF mail extensions working group, I took 
>     an action to initiate a 4 week working group last call period for this 
>     SMTP binary extension.
>     
>     The document is in the Internet-Drafts directories as 
>     <draft-vaudreuil-smtp-binary-04.txt>.  It will be reposted as an 
>     Internet draft under the filename <draft-mailext-smtp-binary-04.txt>
>     
>     The working group discussed this proposal and identified no problems.  
>     However, there was an insufficient people present who felt competent 
>     to fully approve this document, and a last mailing list review was 
>     requested.  Please give this document a final once-over (or twice) and 
>     send comments.  There is already one implementation of this protocol 
>     extension. 

Comments on the CHUNKING extension:

1) it would be useful, I think, to explicitly state that BDAT and DATA
   cannot both be used in the same mail transaction.  Once BDAT has been
   issued, any DATA command (without an intervening MAIL or RSET command)
   should result in a 5XX error.  Similiarly for use of BDAT after DATA.

2) Explicitly state that RSET clears all accumulated chunks.

3) I believe there is also a need for checkpoint/restart mechanism based on
   chunking, which should be included in the chunking extension.  Though an
   additional extension along these lines would be cheap to implement, each
   new SMTP extension introduces the potential for bugs in the client-server
(Continue reading)

Dave Crocker | 9 Aug 23:27 1994
Picon

Re: WG Last Call: Binary SMTP

Keith,

I'm sympathetic to the desire for checkpoint/restart.  In fact, I've been
astonished at how little use of such mechanisms has shown up in the
Arpanet/Internet in the last 20 years.  FTP spec'd it from the start.
Almost no one uses it.

Blame it on having an Internet that is too reliable, I guess.

I suspect it also has to do with complexity and the retention of state
across sessions.

Hence, let me suggest that any attempt at such a mechanism should try for
the simplest one possible.

E.g., sender say BDAT msgid=xxx,continue

reply specifies the byte offset that is the last byte held by the recipient.
sender must then start sending from count+1.

Byte counts are in terms of network canonical form, and not local storage.
Also, note byte and not line or segment count.

Sender is free never to exercise this facility.  Receiver is free always to
answer with a count of 0.

Dave

-----

(Continue reading)

greg.vaudreuil | 10 Aug 01:00 1994

Re[2]: WG Last Call: Binary SMTP


Comments on the CHUNKING extension:

1) it would be useful, I think, to explicitly state that BDAT and DATA
   cannot both be used in the same mail transaction.  Once BDAT has been 
   issued, any DATA command (without an intervening MAIL or RSET command) 
   should result in a 5XX error.  Similiarly for use of BDAT after DATA.

          I will clarify this in the document.

2) Explicitly state that RSET clears all accumulated chunks.

          I will also explicitly state that RSET clears the accumulated 
          chunks.

3) I believe there is also a need for checkpoint/restart mechanism based on
   chunking, which should be included in the chunking extension.  Though an 
   additional extension along these lines would be cheap to implement, each 
   new SMTP extension introduces the potential for bugs in the client-server 
   interaction.  (If nothing else, there are more conditions to test.)  This 
   is particularly true for an SMTP extension that changes the SMTP state 
   machine. 

          Checkpointing is good, checkpointing may be simple, but it is not 
          the point of this document.  Checkpointing is clearly another 
          ESMTP keyword so I see no advantage in combining it with this 
          document.  

          I do not see the immedate necessity for checkpointing as I do for 
          Binary transport.  Adding checkpointing now rather than later 
(Continue reading)

Ned Freed | 10 Aug 00:08 1994

Re: WG Last Call: Binary SMTP

> Comments on the CHUNKING extension:

> 1) it would be useful, I think, to explicitly state that BDAT and DATA
>    cannot both be used in the same mail transaction.  Once BDAT has been
>    issued, any DATA command (without an intervening MAIL or RSET command)
>    should result in a 5XX error.  Similiarly for use of BDAT after DATA.

Excellent point -- I agree this needs to be stated.

> 2) Explicitly state that RSET clears all accumulated chunks.

It should not be necessary to say this, but it can't hurt.

> 3) I believe there is also a need for checkpoint/restart mechanism based on
>    chunking, which should be included in the chunking extension.  Though an
>    additional extension along these lines would be cheap to implement, each
>    new SMTP extension introduces the potential for bugs in the client-server
>    interaction.  (If nothing else, there are more conditions to test.)  This
>    is particularly true for an SMTP extension that changes the SMTP state
>    machine.

I've thought about this some, and while I originally thought that chunking
should be another option in the BDAT I'm no longer sure about that. It may be
cleaner to have it as a separate command and response. This decoupling may
lessen the chance of complex interaction bugs as well.

>    I realize that checkpoint/restart introduces its own set of concerns,
>    (including the possible need for security measures), but I would like to
>    see further discussion of this matter to determine whether this is the
>    right set of functionality, before putting the CHUNKING extension on the
(Continue reading)

Dave Crocker | 10 Aug 01:04 1994
Picon

Re[2]: WG Last Call: Binary SMTP

At 4:00 PM 8/9/94, greg.vaudreuil <at> octel.com wrote:
>  Checkpointing is clearly another
>          ESMTP keyword so I see no advantage in combining it with this
>          document.

fair point.  I think I now cast my vote in the direction that greg suggests.

d/

-----

Dave Crocker                            <dcrocker <at> mordor.stanford.edu>
675 Spruce Dr.                  +1 408 246 8253;  fax: +1 408 249 6205
Sunnyvale, CA  94086 (USA)

Dave Crocker | 10 Aug 01:20 1994
Picon

checkpoint option

At 3:08 PM 8/9/94, Ned Freed wrote:
>Interesting point. I think we may want to look at checkpointing now to
>determine if there's some interaction we need to know about.
>
>Does anyone have a strawman checkpoint proposal to offer at this time?

Just to start things off:

The following is predicated on the belief that restart is not needed often.
Therefore, it should be real cheap in the normal case, possibly at the
expense of slightly higher overhead when it is invoked.

A server may choose to do checkpointing by recording the addressing info
and the content up to a "network" byte offset of the last byte received,
along with the message id that is included by the client.

That is, the server announces support of the option in the EHLO and a
conforming client includes MSGID= in the Mail From.  The msgid ought to be
the same as in the RFC822 headers...

Only content (DATA and BDAT) may be checkpointed.

If things are interrupted, the client starts with the MAIL FROM, including
the same MSGID=.  If the server has saved stated, then the reply code says
'I've got what you sent up to byte xxx.  The client then goes directly to a
DATA/BDAT command sending byte XXX+1.

d/

-----
(Continue reading)

Peter Sylvester | 10 Aug 12:10 1994
Picon
Picon

Re: WG Last Call: Binary SMTP

> I'm sympathetic to the desire for checkpoint/restart.  In fact, I've been
> astonished at how little use of such mechanisms has shown up in the
> Arpanet/Internet in the last 20 years.  FTP spec'd it from the start.
> Almost no one uses it.
Just a side remark: An FTP user can easily survive with TCP time outs
of days, and just let his FTP client hang around for a week. 

An MTA can probably not tolerate hanging SMTP session for weeks,
and may even change his transfer strategies. Therfore the situation
doesn't seem a little bit different to me.

> 
> Hence, let me suggest that any attempt at such a mechanism should try for
> the simplest one possible.
> 
> E.g., sender say BDAT msgid=xxx,continue
> 
> reply specifies the byte offset that is the last byte held by the recipient.
> sender must then start sending from count+1.
> 
> Byte counts are in terms of network canonical form, and not local storage.
> Also, note byte and not line or segment count.
> 
> Sender is free never to exercise this facility.  Receiver is free always to
> answer with a count of 0.
> 
A model for checkpointing exists, and it is called Reliable Transfer
Service. Why is it necessary to reinvent the wheel? At least the
model seems useful to me: It solves the following problems.

(Continue reading)

Peter Sylvester | 10 Aug 14:34 1994
Picon
Picon

Re: checkpoint option

> 
> That is, the server announces support of the option in the EHLO and a
> conforming client includes MSGID= in the Mail From.  The msgid ought to be
> the same as in the RFC822 headers...
> 
What does this mean? The 'msgid' in the RFC822 header? If you
mean 'Message-Id:' then this is clearly wrong because you can
have several 'copies' of a message with the same 'Message-id',
BUT with different headers, for example of a message with
bcc: recipients.

Peter


Gmane