[comp.mail.sendmail] Pathalias and routing of mail

mike@turing.unm.edu (Michael I. Bushnell) (12/08/88)

Unmvax.unm.edu currently routes all mail for foo@baz.UUCP to
uunet.uu.net, and assumes that uunet can find host baz.  We are,
however, on USEnet, and it would be good if we routed UUCP mail
ourselves.  I understand that uunet supports a rather large mail load,
and we would like to do our part to diminish that.

The problem is that we like sendmail, and we like Internet.  We want
to route *only* mail destined for *.UUCP with pathalias.  

Does anyone know of a convenient way to integrate them?  Pathalias
produces a nice voluminous output file, but we would like to avoid
having to use smail, and we would like to route our outgoing UUCP
mail. Any suggestions?

--
Michael I. Bushnell         \  	  This above all; to thine own self be true
HASA - "A" division   GIG!   \    And it must follow, as the night the day,
mike@turing.unm.edu   	     /\	  Thou canst not be false to any man.
Numquam  Gloria Deo   	    /  \  Farewell:  my blessing season this in thee!

deke@socrates.ee.rochester.edu (Dikran Kassabian) (12/08/88)

In article <2189@unmvax.unm.edu> mike@turing.unm.edu writes:
>
>[....]
>
>The problem is that we like sendmail, and we like Internet.  We want
>to route *only* mail destined for *.UUCP with pathalias.  

You don't specify much about your mail configuration and the transport
mechanisms you have available to you.  I hope I am interpreting your question
correctly.  My short answer is:
  Add another "mailer" definition to your sendmail.cf, and then just
  recognize user@site.UUCP and resolve it to that mailer.

>Does anyone know of a convenient way to integrate them?  Pathalias
>produces a nice voluminous output file, but we would like to avoid
>having to use smail, and we would like to route our outgoing UUCP
>mail. Any suggestions?

Why avoid using smail?

We have a machine known as "ee.rochester.edu" on both the Internet and
in the UUCP maps.  We let this machine handle all the mail from within
our domain in the following way.

Any address with the right-hand side of an '@' that we can resolve
gets mailed via SMTP.  Mail of the form user@site.UUCP gets "smail'ed".
We also recognize other forms such as user@site.UUNET and user@site.BITNET
and others, in which case we see that the mail gets sent to the appropriate
gateway for further handling.

This is an extreme oversimplification of what is really happening, but
it accomplishes exactly what we want.  Might be what you want, too.

Good luck,

      ^Deke Kassabian,   deke@ee.rochester.edu   or   ur-valhalla!deke
   Univ of Rochester, Dept of EE, Rochester, NY 14627     (+1 716-275-3106)

emv@a.cc.umich.edu (Ed Vielmetti) (12/09/88)

>In article <2189@unmvax.unm.edu> mike@turing.unm.edu writes:
>>The problem is that we like sendmail, and we like Internet.  We want
>>to route *only* mail destined for *.UUCP with pathalias.  

A couple of alternatives come to mind.

You could bring up smail, and pass off all of the uucp stuff to it.
It's a full-blown mailer, so there's a fair amount of overhead involved
in learning up, but they say it's pretty reasonable.

You could bring up uumail, a small mailer that only handles rewriting
of uucp mail.  It's more or less a drop-in replacement for your uux
mailer, and it does a reasonable job of adding pathalias lookups to
sendmail.  The lookups happen after everything is resolved, so your
flexibility is limited.

You could bring up the IDA patch kit to sendmail, which provides for
direct pathalias lookups within the sendmail.cf.  Several of my
neighbors run this, and they seem to like it.

You could bring up the 'uucpdomain' modifications to sendmail that
uunet runs, which provide a similar direct lookup facility.

I can't think of any other alternatives, if someone could come forward
with a different way of working this out (short of dropping sendmail
entirely and running upas, peter) I'd like to hear about it.

BTW, mailrus, umix, and sharkey all run uumail.  It handles well-formed
addresses quite nicely.

--Ed

mike@turing.unm.edu (Michael I. Bushnell) (12/10/88)

Well, we now do UUCP routing.  Here were some of the suggestions I got:

  1: Run smail.
  2: Run smail.
  3: Run smail.
  4: Run uumail.
  5: Use the IDA enhancements.
  6: Use the same enhancements that UUNET does (similar to the ida ones).

Since (1), (2), and (3) are vastly overblown solutions to a very
simple problem, and (5) and (6) are a pain to integrate easily to new
releases of sendmail, and since Win Strickland (win@gatech.edu) was
very willing to assist me in getting what I needed, I chose (4).

Here's what we do.  We take mail addressed like a!b and turn it into
b@a.uucp.  All *.uucp mail which is not to a neighbor of ours or
destined for our domain (we are the domain gateway in the maps) is
sent to uumail for routing.  This allows us to handle two cases of
passive routing: where we are given only an address and no path at
all, and where the next hop of the path is unreacheable.  In the
second case, we are justified in rerouting since the original path was
invalid. 

Thanks to everyone for all their help.

--
Michael I. Bushnell         \  	  This above all; to thine own self be true
HASA - "A" division   GIG!   \    And it must follow, as the night the day,
mike@turing.unm.edu   	     /\	  Thou canst not be false to any man.
Numquam  Gloria Deo   	    /  \  Farewell:  my blessing season this in thee!

vixie@decwrl.dec.com (Paul A Vixie) (12/10/88)

[ Followups to comp.mail.uucp ]

[Bushnell]
# This allows us to handle two cases of passive routing: where we are given
# only an address and no path at all, and where the next hop of the path is
# unreacheable.  In the second case, we are justified in rerouting since the
# original path was invalid.

You are certainly justified in finding a route to the first host in the
path (or the only host in an address) is not a direct neighbor.  There is
great controversy over the practice of peeking ahead, beyond the first host
in the path, no matter what kicked your mailer into that mode.

Canonically, this is usually put: "given a!b!c!user, go ahead and get to 'a'
by any means available, but don't assume that your 'c' is the same as the 'c'
known to 'b'".  Details such as 'c' being a fully qualified domain are not
really that interesting, since your route to that fully qualified domain may
not be as good as the one that's being chosen, and you have no way of knowing
that unless you monitor all the links as they go through their daily dance of
the yo-yo.

Forgive me, everyone, if this seems like I'm picking nits.  The word 
"reroute" in the above-quoted text can be taken two ways.  I support one
way, and oppose the other.  The difference seems very important to me.
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013