Xref: utzoo comp.mail.uucp:1726 comp.mail.headers:402 Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdahl!tron From: tron@amdahl.uts.amdahl.com (Ronald S. Karr) Newsgroups: comp.mail.uucp,comp.mail.headers Subject: Re: Eliot Lear's final words aren't about this problem Message-ID: Date: 25 Aug 88 08:03:49 GMT References: <34@volition.dec.com> <432@hptsug2.HP.COM> Reply-To: tron@amdahl.uts.amdahl.com (Ronald S. Karr) Organization: Amdahl Coup, UTS Products Hen house Lines: 57 In article <432@hptsug2.HP.COM> taylor@hplabs.hp.com (Dave Taylor) writes: >The gig here is that software should be concerned with the *user* >not the *specification* or the *machine*. Elm (not ELM) has the >builtin hooks to pathalias and the domain rewrite database because >it's something that *users need* (caveat: most sites can rephrase >that as `needed' instead, but there are still leaf Unix nodes on >the periphery...). >The counter-example, one that happens with `lower level >routing', is that you send mail to a host and accidentally >mistype the hostname. You have to wait for your system to >choke on it and return it as a dead letter before you are >notified something is wrong. Hey, man. Like, my Sun, it don't even have much of an alias file, or a path database. It just goes and sends everything it gets off to some other host (over UUCP). ELM aint ever going to get no verification out of that. But more seriously, the mailer we are using at amdahl has multiple path databases, an alias file, a mailing-list directory (which is not tied to the aliases file), and some other features that neither ELM nor any other UA knows about. If you want to verify addresses in the UA, why don't you just ask the MTA? This will work in sendmail. It will also work with Smail3 (still in alpha release, sorry :-). Just connect to the mailer and engage in an interactive SMTP dialog with it. The VRFY command should work nicely. If you can connect to an existing mailer process (over a socket, or over a named pipe), then the response time for requests is generally good, and you do not have to worry about which MTA is being used. Of course, if you can't query your MTA for valid addresses, there is not much you can do except emulate what the MTA will do. But them's the breaks. Some other interesting problems are that MTA's should not be designed with synchronous behavior being a requirement. If Smail3 can't route an address because a lock file is being held for an extended time period, or because a remote host with routing information is down, or whatever, it tries again later. In response to an SMTP VRFY operation, it will return a non-fatal error code indicating a temporary failure. A User Agent would have to be prepaired to handle these problems. The upshot of this is that a User Agent should be concerned with the *user* and the Mail Transfer Agent should be concerned with *mail*, and the *specification* and the *machine*. As long as there exists more than one UA on a system, or as long as alias and path information can be used by remote hosts, the system alias and routing databases should be in the MTA. It is reaonable for a UA to ask the opinion of the MTA, it is counterproductive for a UA to do the work of the MTA. -- tron |-<=>-| ARPAnet: amdahl!tron@Sun.COM tron@uts.amdahl.com UUCPnet: {decwrl,sun,uunet}!amdahl!tron [views above shouldn't be viewed as Amdahl views, or as views from Amdahl, or as Amdahl views views, or as views by Mr. Amdahl, or as views from his house]