re: Batch Processing -- via SMTP....

Craig Partridge (craig@NNSC.NSF.NET)
Tue, 20 Sep 88 09:05:29 -0400

> What are the possibilities for expanding SMTP to provide a mechanism to
> allow batch processing to occur over the network(s)?

Lots of people already do batch processing with SMTP, and there's actually
a fair amount of literature on it:

    - the MOSIS chip fabrication system (described in an ISI report that
    I'm told is now out of print)

    - the CSNET nameserver has a e-mail component for retrieving entries
    (see Solomon and Landweber's paper in Computer Networks 1982).

    - the netlib system (see Dongarra and Grosse's CACM article in May 1987)
    Note that they claim that the netlib system is the first of its kind --
    which isn't true. So far as I can tell, MOSIS was the first.

    - the CSNET Info Server (see the paper in Computer Communication Review,
        October 1987)

Based on my experience writing the CSNET Info Server, the problem of doing
batch processing isn't in SMTP itself, but with addressing. The old saw
of "be liberal in what you accept and conservative in what you send" really
bites automatic mail programs. Two problems in particular come to mind:

    - Busted return addresses. Your local mailer accepts messages
    for the batch program which has a bad return address (this is a *good*
    thing to do in general -- if the addressee is a person, better that
    he/she get the message than it be returned to the sender, or, given
    the return address is bad, dropped on the floor). Unfortunately,
    the batch program, which wants to return information to the sender
    has a request it can't reply to! (If you allow users to indicate
    third-party addresses in the batch request, this problem gets worse.
    Then, even if we fixed the problem of bad return addresses in
    mailers, users could still specify bad addresses)

    - Mail loops. Originally, the Info Server put the CSNET postmaster's
    address as the source address in the SMTP envelope, and the Info
    Server's program address in the From: field. The idea was that
    errors would be returned to the envelope sender (our postmaster)
    but that users that replied to Info Server messages (perhaps with
    a request for more information) would indeed get the Info Server.

    Unfortunately, there are mail systems out there that still reply
    to the From field instead of the envelope sender. As a result,
    we had some spectacular mail loops between remote mailers, who
    were sending error messages back to the Info Server, and Info Server
    which was happily treating the error messages as requests and
    sending them back to the remote mailer (which promptly sent them
    back to the Info Server). In fact, in at least one case I
    think we hit a sorceror's apprentice problem with a mailer in
    BITNET -- it sent two error messages, so we'd send two replies,
    so it would send four messages.... (I think we were well over
    twenty messages per volley by the time we caught this).

We might be able to fix the error handling problem through education.
I think we will always have to worry about busted return addresses --
it is too easy to misconfigure a mailer in this world.


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:30 GMT