🚀 go-pugleaf

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