Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!mcsun!ukc!icdoc!sot-ecs!tjc
From: tjc@ecs.soton.ac.uk (Tim Chown)
Newsgroups: comp.mail.elm
Subject: Re: expanding reply address in 2.3
Message-ID: <2862@ecs.soton.ac.uk>
Date: 6 Jun 90 10:40:08 GMT
References: <2856@ecs.soton.ac.uk> <1990Jun5.225613.15848@DSI.COM>
Organization: University of Southampton, UK
Lines: 39

In <1990Jun5.225613.15848@DSI.COM> syd@DSI.COM (Syd Weinstein) writes:

>tjc@ecs.soton.ac.uk (Tim Chown) writes:
>>Anyway, I've commented out the whole #ifdef .. #endif in the above
>>code and I seem to have the 2.2 functionality again.  Will I get
>>horrible side-effects ?
>Nope, just the effect stated above, that a 'local' reply might go to
>one of your aliases.  Now if you are sure that no local user names
>will ever match a user or system alias, then that block of code
>could safely be commented out.

OK, I see the problem arises where a user sets up an alias and
then gets mail from a true user with that alias as their mail ID.
So I guess the kludge *is* needed.  Having said that, we have
several hundered users, with Elm the prominent mail front-end,
and I've had no reports (as postmaster) of mail going astray
under 2.1/2.2 because of this aliasing problem.

>What I don't remember any more, was whether the local system name
>was supposed to get taken back off before we handed the message
>off the the MTA or not....

It would seem sensible to do so, though our sendmail configuration
handles it fine.  The crux of the problem is that our site is
"ecs.soton.ac.uk" and that that is the only nationally registered
domain we use.  We hide all our other machines beneath this.
When Joe User replies to local mail in 2.3, he may choose to
edit the header, then sees a To: line with the recipient with
hostname.domainname tacked on.  Joe can get confused by this. 

Perhaps Elm could tack the fullhostname info on invisibly to the user,
by not displaying local addresses in the header info.  This way you'd 
get the best of both worlds.

But a minor problem in an otherwise fab product !

Cheers,
	Tim Chown
	T.Chown@ecs.soton.ac.uk