(C) Copyright 1987,
    David Herron and the University of Kentucky Computer Science Dept.

Rights are granted to use, distribute, modify, and distribute
modifications of this work, provided that you subscribe to
bsmtp-users@ms.uky.edu and describe there any modifications you 
make.
---

This package of files contains my BSMTP programs.

BSMTP stands for "Batch Simple Mail Transfer Protocol".  It is a form
of SMTP for use over a network where you communicate by way of files
rather than interactive channels.  Both the UUCP network and BITNET are
file oriented networks.  This protocol was originally developed for
BITNET by E. Alan Crosswell of Columbia University, and is documented
in "CUVMB BSMTP" which is available from NETSERVE's on BITNET.  I've
included a copy of CUVMB BSMTP in this distribution; it is in it's
original form (complete with fortran carraige control).  The idea is to
take the same sorts of things the sender says in an SMTP transaction,
put it all in a file, and send that to the reciever.

Example:

HELO sending-domain
MAIL FROM: <reverse-path>	# <path> is a regular rfc-822 route/addr
RCPT TO: <forward-path>
   ...
DATA
   ...  RFC-822 style message (preferably) ...
.
QUIT

The other half of the conversation is to be returned to the sending
process.  Assumably the sending process will look through the file and
see if there are error codes, and return an error message to the human
sender if there are any.  To aid in this, Crosswell added two commands
to the SMTP command set, "TICK <id-number>" and "VERBOSE {ON,OFF}".
The id-number for the TICK command isn't the Message-ID:, but is
something else and should be used to get back the message when an error
reply comes back.  The VERBOSE command controls the verbosity of the
reply file.

The TICK and VERBOSE commands are seen and ignored because we don't
generate the reply file.  Instead we just give the message to the
mail system and let it generate error messages as necessary.  This
is a policy decision that Crosswell saw in a different light than
I saw it.  I do not know his reasoning behind deciding to generate
reply files; possibly to keep the SMTP model as closely as possible;
possibly the crudeness of the systems at the time (1982).  Nevertheless
I don't see any use for reply files so long as your underlying mail
system is good, and can generate error messages back to the original
sender as necessary.

The other "known difference" is that RFC-821 specifies that a
Return-Path: header be added to the beginning of the message, and that
each host to handle the message add themselves to the beginning of the
Return-Path:.  Back in the dark ages when RFC-821 was written, that was
probably a useful thing to do.  Nowadays that isn't so useful since
domains point exactly at the intended host without need to be able to
trace routes back through the network in order to reply.





HOW TO USE "ibsmtp"

Right now I'm only using it for receiving BSMTP from BITNET.  I hacked
on urep until we weren't using simple any more and using ibsmtp instead.
(Basically, the hacking involved changes in profile() in daemon/dafile.c
and in mailer/damail.c, the sort of changes necessary should be obvious
once you've gotten to those sections of the code).

On BITNET, BSMTP files arrive in "pure" form.

In RFC-976, Mark suggests a different form for using BSMTP.
You generate a UUCP envelope and RFC-822 envelope for a regular
message headed for b-smtp@some.site.somewhere.  The body of
this message contains a BSMTP envelope with #'s prepended to
each line.  I might argue with some of his reasoning in deciding
that is the way to do this, however it is the documented method
and will definitely do the job.

Yet this still leaves us with the problem of using BSMTP.  We will
have to have some way of knowing who can do BSMTP.  We will have
to come up with a way for generating routes to the sites which
can do BSMTP.  Also we will have to know what domains the sites
who can do BSMTP can service.

After a few minutes thought it seems that we really need to meld this
in with the map in some way.  A possibility is to set a special cost of
BSMTP which isn't really a cost, as in:

site	.edu(BSMTP), .gov(BSMTP), ...

could automagically generate a path ".edu ...!site!b-smtp".

I think that a few people will want to implement bsmtp immediately.
(In fact, if I had someone who wanted to do that I'd be happy go ahead
and implement it on our uucp side right now).  BUT those sites will
likely be spread out meaning we'd have to make extra links just to do
bsmtp over, or have some way to get across the network.  To get started
it will work to have hand generated routes and the like, but if it
grows big enough we'll want to have some sort of tools to help out.



WHY YOU WANT TO USE "ibsmtp"

The main reason you want to use BSMTP format in your mail is
to avoid sending addresses through command lines, and the resultant
mucking that the shell can do.  The addresses are hidden in the
BSMTP file which avoids handling by the shell, for most cases.

The other reason for using BSMTP is to bring the UUCP world
closer to using domains.



FUTURE NEEDS

1) Need to have this running under uucp systems.
2) Need to fix up an rmail which will handle b-smtp.  I think that
   it would be better to hack rmail to look at the address to see
   if it is b-smtp rather than send it on into the mail system.
   Sending it into the mail system will be extra overhead which
   could get nasty if this stuff ever gets used a lot.
3) Tools to help us get bsmtp stuff across the net.
4) Also, some way of knowing the right bsmtp capable place to send
   things for particular domains to.
5) "obsmtp" to create bsmtp packages.  Right now I've got a silly
   shell script which can be used.
6) A discussion group somewhere.  To get the ball rolling I've created
   an alias here "bsmtp-users" and "bsmtp-users-request".  The first
   is for discussion and the second is for administrivia.

