vixie@decwrl.dec.com (Paul Vixie) (08/13/88)
The folks at Rutgers seem intent on making us all work harder -- these obscene message-id's they generate keep making RN blow up. Yes, I know I can fix my software, but why is it always Rutgers that makes things stretch to their breaking point? Sigh. Not my topic, please ignore. In article <Aug.11.20.43.05.1988.26993@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: # My final words on the subject.... # # Note: The use of source routing is discouraged. Unless the # sender has special need of path restriction, the choice # of transmission route should be left to the mail tran- # sport service. # # [RFC-822: Section 6.7.2, Page 32] Eliot, The person you need to yell at for this offense is Dave Taylor. ELM is the only user agent I know of that has an option for automatic source routing. Perhaps you can tell at Dan Heller, MUSH has everything else, it probably has this too. But you aren't addressing my complaint. My mail transport software (sendmail) is selecting a source route. Your mail transport software (who knows?) is overriding it. And note "unless the sender has special need of path restriction" -- this means that if the sender has some reason to select a certain source route, the mail transport software should respect that choice. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013
taylor@hplabs.hp.com (Dave Taylor) (08/18/88)
Paul Vixie replies to a comment of Eliot Lear with: > The person you need to yell at for this offense is Dave Taylor. ELM is the > only user agent I know of that has an option for automatic source routing. Yo! Vixie! Yer wrong, mon! 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...). I don't know, this is a pretty serious issue, actually. I guess we're just disagreeing on some fundamental issues here, that of the system modifying its behaviour to match the needs and expectations of the user, or vice versa. 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. That's wrong. In the same way, sendmail is *not* the right place to have personal aliases -- if I want to be able to send mail to "vixie" from my computer, I should *not* have an alias in the /usr/lib/aliases file "vixie:vixie@DEC". That's too far down, and too late for the cognitive process of composing and sending a message. I want to know IMMEDIATELY that if I type in 'vixe' instead, it's wrong. Comments? -- Dave Taylor
vixie@decwrl.dec.com (Paul Vixie) (08/23/88)
Dave Taylor felt misused when I said: # > The person you need to yell at for this offense is Dave Taylor. ELM is the # > only user agent I know of that has an option for automatic source routing. # # Yo! Vixie! Yer wrong, mon! Hey, like, you're right. I rather like ELM's source-routing and aliasing features; they're cute, harmless, and occasionally very helpful. I brought up ELM because Eliot seemed confused about what we were talking about -- if he really was upset about source routing in user agents, the thing to yell about is ELM, not Smail. I think he got the point. Sorry to rope you into this. I really don't mind this feature of ELM. But as long as we're talking about where user-name aliasing should go, I agree that there should be a way to do it in the user agent, but I like having it available in the MTA as well -- .forward files are a pain when someone leaves the host and you don't want to keep their account online. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013
tron@amdahl.uts.amdahl.com (Ronald S. Karr) (08/25/88)
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]