craig@NNSC.NSF.NET (Craig Partridge) (09/20/88)
> 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. Craig
CERF@A.ISI.EDU (09/24/88)
The big problem with batch via SMTP is authenticating that the sender has privileges to use the target resources - one presumably doesn't like to leave passwords en clair in SMTP traffic. Vint
patterso@hardees.rutgers.edu (Ross Patterson) (09/26/88)
Craig, The experience of the BITNET "LISTSERV" mail manager bears out your observations from the Info server. Many's the time we've wished for an explicitly defined address to direct errors towards, rather than relying on the mail system's implementors to grasp the vagueries of RFC822's From: and Sender:; RFC821's MAIL FROM:, and the interaction between them all. We've even found some mailers that use Reply-to: as an error target! LISTSERV has the unenviable status of both a mail originator (for the discussion groups it manages), and a batch processor (for the various commands it accepts (subscription requests, file retrievals, database search, etc.), causing it even further grief. One mail-based batch processor I'm aware of, which provides access to an otherwise online computer conference, explicity codes a "Reply-to: Garbage@Garbage (Don't REPLY to this message)" to avoid the problem. Ross Patterson Rutgers University