Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!twwells!bill From: bill@twwells.com (T. William Wells) Newsgroups: comp.mail.uucp Subject: Re: Smail, Aliases & Programs Keywords: smail alias Message-ID: <1989Nov13.093416.19547@twwells.com> Date: 13 Nov 89 09:34:16 GMT References: <590@piglet.vision.UUCP> <974@becker.UUCP> <254733A5.10634@ateng.com> <13074@s.ms.uky.edu> <254CCBB1.19467@ateng.com> <1989Nov2.200712.163@twwells.com> <255344AF.10561@ateng.com> <1989Nov6.064722.15635@twwells.com> <2558A19B.26552@ateng.com> Organization: None, Ft. Lauderdale, FL Lines: 120 In article <2558A19B.26552@ateng.com> chip@ateng.com (Chip Salzenberg) writes: : According to bill@twwells.com (T. William Wells): : >Deliver does much of its work by running shell scripts. Lmail : >doesn't call anything external except to run commands on request : >and to do remote mailing (and it batches remote addresses to : >minimize the number of calls). : : Ah, yes. Well, Deliver's design criteria did not include working well alone : (though it can be done). Deliver was intended for use with Smail 2, Smail 3 : or Sendmail. That is also how I see lmail. But I also intended it to do as much work as possible itself, because I'm an efficiency junkie. :-) : Perhaps more significant is that Deliver's use of shell scripts makes : hacking your mail system much easier. That ease of use is sometimes a : more important win than efficiency. For example: : : o Does your mailer not understand your network? : : No problem; use Deliver to run the network's remote execution : program. (Chip Rosenthal did this.) I've been thinking of ways to do this with lmail, though my reason has less to do with the structure of my local network as my desire to have precise control of how my mail goes from here to there in the global network. As an example of this, I have a marked preference for storing addresses as user@domain in my address lists. But this generally means that my e-mail goes through uflorida, which manages to munge the headers in such a way that certain sites can not read it! So, what I want to do is to have mail destined for that site be routed through uunet instead. Oh, I could fudge my pathalias file, but that would really be a bear. Instead, I'm thinking of adding stuff to lmail to let it do this, so that I can just do simple configures and have it do what I want. The main reason I've not done this already is that I suspect that to really do it right would mean reinventing sendmail. And that is a slightly bigger job than I want to take on right now! : o Do you want a mail to news gateway? : : In the system delivery file, notice addresses that look like newsgroups; : hand those messages to the gateway program. (I did this.) This I can do easily enough. Just have aliases for the newsgroups I want to gateway. : o Want your mail delivered with a "Status: O" header so your user agent : can tell which messages you haven't read? : : No worries. (Me again -- my user agent is Elm.) Actually, I've had a slightly different interest: munging outgoing mail headers. An example: if I mail to a local mailing list, the To: line does not get a domain name. It works fine for everyone else, of course! This is a bug in my mailer, but it would be nice if someone automatically appended the domain on outgoing mail. I could probably fudge lmail to do this, but I suspect that smail is really the right place. : A note for you vaporware junkies: Deliver 2.0 patch #2 will include : logs for deliveries and errors. The error log will include failed messages' : headers. Now _that's_ something I should be adding to lmail. Right now, smail generates logging information, but that is not sufficient for tracking mailing list stuff, which lmail handles. : In conclusion: I don't doubt that lmail can be more efficient than Deliver. : But Deliver is no pig, either. And the real question is, which is more : valuable -- your computer's time, or yours? The answer is "yes". :-) Seriously. Over 80% of my waking hours are spent working with this computer. Something that takes my computer's time takes *my* time. And, of course, for my purposes, configuring lmail is simpler than configuring Deliver would be. So, for *my* particular purposes, I save time both ways. Your milage may differ. :-) --- Hey, I just had a thought: there is little reason for me not to add features that would permit easy integration of the two. I could look for .deliver files in user's home directories and, if found, run deliver for them instead of attempting normal delivery. I have an alias bad-mail to which undeliverable mail is sent. The way that works is this: just before returning a failure code to (presumably) smail, I attempt mailing to bad-mail. This way I get to see what kinds of bounces happen on my system. I could easily add an alias, say try-mail, which is similar to this, except that, if mail to try-mail succeeds, no error code is returned. (Actually, that was the way I originally coded bad-mail, but I found redirecting the mail overly onerous.) One could modify the call to smail to call Deliver instead, if one wanted remote mail to get processed by it as well. (For my uses, I wouldn't: I'd assume that, once things got to the remote address stage, all the important processing was already done. But I expect others will have different purposes.) The effect of all this would be that lmail would get first dibs on the message and so, for the easy stuff, you get the advantages of its efficiency and of its easy configurability. But for the more complex stuff, Deliver gets to do its magic. What do you think? --- Bill { uunet | novavax | ankh | sunvice } !twwells!bill bill@twwells.com