BSMTP: Batch Simple Mail Transfer Protocol

Fuente

BATCH SIMPLE MAIL TRANSFER PROTOCOL



E. Alan Crosswell

Columbia University Center for Computing Activities


Prepared for presentation at BITNET programmers' meeting

13 September 1982



1. Acknowledgements

The following paper is based on electronic mail discussions on BITNET and
original  ideas for a Batch SMTP implementation developed by Mike O'Dell on
ARPAnet.  Thanks to Greg Minshall for making Mike's ideas known.


2. Introduction

SMTP [1] is an interactive protocol that defines  a  transaction  between
two  mail transport servers.  One is defined to be the sender and the other
the recipient.

1      2
Using RSCS , UUCP , or any other store-and-forward transfer system  where
a file  is  the  smallest unit of transmission it is clearly impossible to
maintain such a full-duplex transaction.  In RSCS, only files may  be  used
to communicate between service machines and no guarantee can be made of the
order  of arrival of one file with respect to another.  Also, communication
with other than VM systems is required.  Systems connected  via  HASP  SML,
NJE/NJI and other links exist (MVS, Unix, Tops-20, etc.).

Why  then  should SMTP be used?  Maybe it shouldn't.  However, since ARPA
supports it, it  will  be  well  defined  and  understood  by  the  largest
internet.    Also,  it  seems relatively straightforward to create programs
that will take a Batch SMTP (BSMTP) file and pass  it  to  a  SMTP  system,
simulating a real SMTP hookup.

3. Batch SMTP operation

BSMTP uses seperate files for whole sections of a transaction rather than
each  line.   The idea is to create a list of commands that would be issued
assuming all previous commands had received OK replies.   This  transaction
log  could  then  be sent to the receiver BSMTP server which reads the file
and logs its responses.  The response log is then returned, etc.

An example of an SMTP transaction is in in figure 1 and an example of the
equivalent BSMTP transaction is in figures 2 and 3 below.

S: HELO CUVMB.BITNET                   ! begin session
R: 250 CUVMA.DECNET                    ! acknowledgement and ID
S: MAIL FROM:<EACUS@CUVMB.BITNET>      ! request to send mail
R: 250 OK                              ! receiver agrees to accept
S: RCPT TO:<AC2US@CUVMA.BITNET>        ! recipient #1 is named
R: 250 OK                              ! receiver will do it
S: RCPT TO:<FOO@CUVMA.BITNET>          ! recipient #2 is named
R: 551 No such user                    ! denied this one
S: DATA                                ! ready to send data
R: Start mail input, end with record containing only "."
Date: Monday, 13-Sep-82 10:32 EST
From: Alan Crosswell <EACUS@CUVMB>
Subject: Hello
To: AC2US@CUVMA

Hello there....
.

Figure 1:    Sample SMTP transaction


HELO CUVMB.BITNET
MAIL FROM:<EACUS@CUVMB.BITNET>
RCPT TO:<AC2US@CUVMA.BITNET>
RCPT TO:<FOO@CUVMA.BITNET>
DATA
Date: Monday, 13-Sep-82 10:32 EST
From: Alan Crosswell <EACUS@CUVMB>
Subject: Hello
To: AC2US@CUVMA

Hello there....
.
QUIT

Figure 2:   BSMTP: File from CUVMB to CUVMA


220 CUVMA.BITNET Batch Simple Mail Transfer Service Ready
250 CUVMA.BITNET
250 OK
250 OK
551 No such user
354 Start mail input.  End with "."
250 OK
221 CUVMA.BITNET Service closing transmission...

Figure 3:   BSMTP: File from CUVMA to CUVMB


4. Modifications to SMTP syntax

How  does the server on CUVMB in the preceding example know which file in
its reader is the reply to which file it sent?  There's no way to  be  sure
unless  some  sort  of  extra identification is imbedded in the files.  The
following proposed additions to the SMTP commands would solve this and  the
problem of coordinating processing of replies:

4.1. Ticket command

TICK <ticket-id>

The  Ticket  command  is  used to mark a file with additional identifying
information.  This would be a unique message indentifier generated  by  the
sending BSMTP system.  By use of the ticket, the BSMTP sender would be able
to identify a later BSMTP reply.

4.2. Verbose command

ON
VERB
OFF

The Verbose command solves the problem of coordinating BSMTP transactions
further  by  specifying  that  all  commands received by the receiver BSMTP
system be echoed in its reply along with its usual reply codes  (VERB  ON).
Data  other  than  that  on  command  lines need not be echoed, so the file
overhead is not substantial.

4.3. Advantages

Use of Ticket and Verbose has several advantages, The ticket  provides  a
unique identifier that the sender can use to keep track of the files it has
shipped.   When a reply arrives, the sender simply looks up the information
it stored when it generated the ticket and uses the information  to  inform
any  interested parties (the person who sent the mail) of the status of the
request.

The  use of verbose takes the burden off the sender to remember and later
synchronize the commands it sent with the replies it  receives.    Assuming
the  sender  trusts  the  replying BSMTP system, it has all the information
needed in the proper order.  This information could very easily be  "piped"
into a program that simulates the SMTP full-duplex interaction.

A  very simple sender implementation would not even have to keep track of
tickets as long as the verbose information is supplied to it.

5. Example of BSMTP operations

A complete example would be as follows:

1. The CUVMB mailer receives a file from a local user to be sent to
a user at CUVMA.

2. A unique ticket is created and a file is punched to CUVMA.   The
ticket is stored for later recall.

3. The CUVMA mailer receives the file from CUVMB.

4. Mail is sent to the CUVMA user.

5. A  verbose  reply  file  is  generated which contains the ticket
supplied by CUVMB and is punched to the CUVMB mailer.

6. The CUVMB mailer receives the file.

7. The file is recognized as a reply rather than an  original  file
sent  from  CUVMA  by  the  presence  of reply codes rather than
commands.

8. Each code 250 line is read and skipped.
9. Each code 050 line (the echoed  command)  is  processed  to  the
degree  desired.    In  this case, the TICK is found and used to
access the ticket that was previously saved.

10. Other code 050 lines and their replies  are  processed  and  the
appropriate  action  is  taken (i.e. EACUS is informed that user
FOO was not found).

HELO CUVMB.BITNET
VERB ON
TICK 0001
MAIL FROM:<EACUS@CUVMB.BITNET>
RCPT TO:<AC2US@CUVMA.BITNET>
RCPT TO:<FOO@CUVMA.BITNET>
DATA
Date: Monday, 13-Sep-82 10:32 EST
From: Alan Crosswell <EACUS@CUVMB>
Subject: Hello
To: AC2US@CUVMA

Hello there....
.
QUIT

Figure 4:   BSMTP: file generated by sender


220 CUVMA.BITNET Batch Simple Mail Transfer Service Ready
250 CUVMA.BITNET
050 VERB ON
250 OK
050 TICK 0001
250 OK
050 MAIL FROM:<EACUS@CUVMB.BITNET>
250 OK
050 RCPT TO:<AC2US@CUVMA.BITNET>
250 OK
050 RCPT TO:<FOO@CUVMA.BITNET>
551 No such user
050 DATA
354 Start mail input.  End with "."
250 OK
050 QUIT
221 CUVMB.BITNET closing transmission...

Figure 5:   BSMTP: file returned by recipient


6. Compatibility with SMTP


The  Ticket  and Verbose commands and 050 reply code are additions on top
of the current SMTP specification.  Assuming that they would be ignored  by
an SMTP process, compatibility is maintained.  The Verbose command has even
been suggested as a debugging aid for SMTP implementers.

_______________
1
IBM VM/370 Remote Spooling Communications Subsystem
2
Unix to Unix Communication Program


REFERENCES

[1]   Jonathan B. Postel.

Simple Mail Transfer Protocol.
ARPANET Request for Comments, No. 821; Information Sciences
Institute, University of Southern California, 4676 Admirality Way,
Marina del Rey, California 90291, 1982.


Table of Contents

1. Acknowledgements
2. Introduction
3. Batch SMTP operation
4. Modifications to SMTP syntax
4.1. Ticket command
4.2. Verbose command
4.3. Advantages
5. Example of BSMTP operations
6. Compatibility with SMTP


List of Figures

Figure 1:   Sample SMTP transaction
Figure 2:   BSMTP: File from CUVMB to CUVMA
Figure 3:   BSMTP: File from CUVMA to CUVMB
Figure 4:   BSMTP: file generated by sender
Figure 5:   BSMTP: file returned by recipient