lel@ida.liu.se (Lennart Lovstrand) (04/27/87)
In article <1320@decuac.DEC.COM> avolio@decuac.dec.com (Frederick M. Avolio) writes: > Just tacking on a host name yields addresses like: > host1!CSNET-RELAY.ARPA!username%siednarb%brandeis.csnet > (A real address from a From: line.) Hey, that's at least parsable! What do you say about examples like: enea!seismo.CSS.GOV!!wiscvm.wisc.edu:IMHW400!INDYCMS.BITNET or enea!seismo.CSS.GOV!!OZ.AI.MIT.EDU,!MC.LCS.MIT.EDU:ebg!REAGAN.AI.MIT.EDU which are real "From_" line instances produced by our backbone. (They are very nice and cooperative otherwise, no blame intended for anything except the above. Their From: lines are much better, for instance.) I don't know, but I guess the European UUCP mail climate differs a lot from the US. We have the EUnet organization and "official" backbones to rely on. The backbones keep complete UUCP and domain maps, which simplifies things much for the rest of us. Re: whether to prefix myhost! onto the From: or not.. Well, we *completely* rewrite *all* addresses to domain format internally and then turn them back into !-paths for some, but not all, UUCP traffic. (Do I see a flame coming? :-) It actually works well too, but probably only because we don't use standard sendmail source or config files... As for the UUCP world, our strategy has been to divide it into three different classes: 1) bsmtp nodes, for which we supply RFC822 conformant addresses only. Our node name is prepended to the "MAIL FROM:" line using the RFC822 source routes syntax. 2) "smart" UUCP nodes, for which we supply domain style addresses in the header lines and domain/!-paths as appropriate for envelope addresses. Our node name is only prepended to the "From_" line. 3) "dumb" UUCP nodes, for which we only supply !-paths with our UUCP node name prepended whereever applicable (both envelope and headers). This means that we rely on our neighbors to forward mail using whatever appropriate format they use on further communication. For local mail and mail relayed into the TCP/IP or DECnet worlds, addresses are produced to be essentially conformant with RFC822. This goes for both envelope and header items. In that way, they never have to bother with !-paths--they never even see them. In case anybody would be interested, I plan to package our changes to the sendmail source together with our locally produced config files and send them to mod.sources. I've put down a lot of effort on making the changes as minimal(?) and clean as possible while still getting the required functionality. The stuff is based on the 5.51 version of sendmail and has been implemented on Sun-3 OS 3.2, Gould with UTX/32 and a PDP-11/73 with BSD2.9(!) The source changes include the following features: o A general and direct interface to named dbm databases (selectable from your sendmail.cf). This means you can read your pathalias output directly from sendmail. o Batched SMTP support in sendmail. Both a client end that produces SMTP scripts and a server end that mails back errors. o Separate control over envelope and header rewriting rulesets. Header addresses are passed through rulesets 1 & 2 while envelope addresses are formatted using rulesets 5 & 6. Mailer specific envelope/header rewriting rulesets are selected in the mailer defs. o Support for the `p' mailer flag (M_FROMPATH) in the code that produces UUCP "From_" lines, thus making it possible for you to add your hostname to the envelope sender only. o A new `V' mailer flag (M_RELATIVIZE), which removes the recipient host (+ "!") from paths through the them and adds your hostname to the other header addresses. recipient!user are not touched, however. o Support for default arguments in nametable and dbm file lookups. Eg. "$[ foo $: bar $]" will expand to foo's official hostname if known or to bar otherwise. o Support for multi-token class matches. If you have a string like "foo.bar.edu" in class X and have "." as a separator char, the old sendmail just wouldn't match it. This one does. o Support for embedded ruleset calls (like "$>4$>10$>6 $1@.$2"). o Support for completely separate UUCP and domain names. o More elaborate match mechanism for searching unknown local recipients in the full name part of /etc/passwd. o Support for Maryland's mdbm package for systems that don't have ndbm. o Symbolic ruleset test mode output (ie. "$#" for "^X" or whatever it normally is). and a couple of bug fixes. The config file fully understands and supports: o Domains--both user@domain and domain!user. o RFC822 Source Routes, ie. <@domain,...:user@domain> o RFC822 Group Names, ie. "Foo: misc_addresses ;" o The Ole ARPAnet %-kludge. o UUCP !-paths. and a resonable mixture of the above. We also use it for maintaining a set of generic local usernames, as in the case of "lel@ida.liu.se", which is not a user on a specific machine, but rather an entry in a shared aliases table with a forwarding pointer to my preferred machine. Puh, I'll refrain myself from going further into detail. I think I've gone far enough already to put at least some of you into instant boredom. And other into instant flaming... Ack, that's life. The summer is coming. Enjoy! --Lennart, writing to you from a slowly thawing country in northern Europe. -- Dept of Computer and Information Science, University of Linkoping, Sweden Internet: Lennart.Lovstrand@IDA.LiU.SE EAN/X.400: lel@ida.liu.sunet UUCP: {mcvax,munnari,seismo}!enea!liuida!lel EARN/BITNET: LEL@SELIUI51