[comp.mail.sendmail] Need to fake return machine address

Lennart_Lovstrand.EuroPARC@Xerox.COM (05/25/90)

In article <106@tdatirv.UUCP> swf@tdatirv.UUCP writes:
>In article <1990May21.181455.22689@mozart.amd.com> mikel@mozart.amd.com
>(Michael W. Wellman) writes:
>>  I've several machines which are used interactively
>>and we wish to have all mail sent only to one machine.  So, assuming that
>>foo is the mail machine, if user@bar sends mail to user1, I want:
> 
>>1)  the mail to be routed automatically to user1@foo
>>2)  the return addresses to be configured so that the return address shows
>>    up as user@foo.
>>
>	I would also be interested in this.  We have a very similar situation
>here. And it makes for some real difficulties with external mail.

Hi, maybe this helps.  The configuration file in the IDA Sendmail Kit has
had this feature for a long time in two forms:

The general version uses a separate "GENERICFROM" database that maps
arbitrary physical addresses (even non-local) to logical addresses for all
header senders.  The database is in turn derived from an extended form of
the aliases database (called xaliases).  For example, an entry like:

	lel@ida, lenlo@ida, Lennart.Lovstrand@ida:
		<> L-LOVSTRAND@LISBET, < lel@obelix, < LENNART@HAZEL, <> lenlo

would mean that any mail coming from either of L-LOVSTRAND@LISBET,
lel@obelix, LENNART@HAZEL, or lenlo on the local host will be rewritten
to have a sender of lel@ida.liu.se.  (Conversely, any mail to lel@ida,
lenlo@ida, or Lennart.Lovstrand@ida will be delivered to L-LOVSTRAND@LISBET
and lenlo on the local host.)

While this feature relies on IDA's generic DBM support, you may be able to
use Sun's YP macros as a substitute.

The simpler version defines a set of hosts which are to be hidden behind
the mailer's hostname.  Any sender address coming from a user on one of
these hosts will be rewritten as user@$j.

The recipe for this goes somewhat like this:

FH/etc/hosts.equiv		(or whatever file you want to use)

S5				(or S1 on non-IDA Sendmails)
...
# Hide these nodes using our own name
R$+@$=H			$: $1@$j
...

All of the above substitutions are performed in ruleset 5 in IDA Sendmail,
which is the header sender specific ruleset.  In a normal sendmail, it
would have to go into ruleset 1, which serves both envelope and header senders.

--------

On the side, I really wish people wouldn't set "Distribution: usa" on
issues that aren't specifically limited to the US.  I generally hate
receiving mail or news related to someone wanting to sell their car in some
remote part of the world, but I also dislike being cut off from an
interesting information flow for no particular reason.  Please let's try
and keep distributions to be meaningful.

Cheers,
--
--Lennart <Lovstrand.EuroPARC@Xerox.COM>
Rank Xerox EuroPARC, 61 Regent St, Cambridge, CB2 1AB, England

jik@athena.mit.edu (Jonathan I. Kamens) (05/26/90)

  Project Athena has a similar problem.  We have almost 1000 public
workstations, none of which receive mail locally; however, mail sent
from them goes through sendmail, and the addresses of local users have
to have "@ATHENA.MIT.EDU" tacked onto the end of them.  We accomplish
this by doing the following:

1. Outgoing mail from a workstation is run through a *very* bare-bones
cf file which is capable of delivering only mail that is explicitly
marked LOCAL or POP (e.g. user@host.LOCAL).  Since most workstations
aren't configured for local accounts or for pop, the LOCAL and POP
delivery lines in the cf file are very rarely used.

2. Any mail that is not LOCAL or POP is forwarded to the mailhub for delivery.

3. The mailhub takes "@ATHENA.MIT.EDU" onto any address that has only a
username on it, then continues with mail delivery.

4. There is a huge automatically generated aliases file on the mailhub
which says where incoming mail is supposed to go.  This includes all the
mailing lists, and all the post-office addresses for users (mail isn't
stored for everybody on the mailhub; it's stored on several post offices
from which users pick up their mail using Kerberized POP protocol).

  Now, an example.  Let's say I'm on workstation w1, and I send mail
with a To: address of "joeruser".  Here's what happens:

1. The local cf sees that the message isn't LOCAL or POP, so it forwards
it to ATHENA.MIT.EDU, the mailhub.

2. The mailhub sees the "joeruser" and changes it to
"joeruser@ATHENA.MIT.EDU".  It also changes the from address from "jik"
to "jik@ATHENA.MIT.EDU", since the local cf doesn't add the workstation
address to my address.  The "@ATHENA.MIT.EDU" stuff is added both in the
message text and internally.

3. The mailhub then realizes that the joeruser address is local after it
strips off the @ATHENA.MIT.EDU internally (but not in the message text),
and finds the post office address for joeruser in the aliases file, and
delivers it.

  You can use a similar mechanism, on a smaller scale, to channel all of
your mail through one machine with a big aliases file.  Note, however,
that this scheme makes it difficult to send mail directly to a machine
participating in this scheme, because the machine is going to want to
forward the message to the mailhub unless you end the message in LOCAL.

  If there is some interest, I can post our workstation and mailhub cf
files (or, at least, all of the relevant parts -- I don't think I need
to post the standard canonicalization stuff).

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710

Makey@Logicon.COM (Jeff Makey) (05/30/90)

Add a rule similar to the following to ruleset 3:

R$*<@$%y>$*	$:$1<@mailhost>$3	route YP hosts to the mail host

This will rewrite any host name known to YP into "mailhost".  By doing
this in ruleset 3, all return addresses and recipient addresses will
be affected.  You may need to modify this to account for domain-ized
names.  Replace "mailhost" with the name of your mail host, or add
"mailhost" as a host alias.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey