Re: [Exim] Alias names

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Philip Hazel
Date:  
À: Sujit Choudhury
CC: exim_users, sujit
Sujet: Re: [Exim] Alias names
On Wed, 25 Apr 2001, Sujit Choudhury wrote:

> If another person joins with the same initial then in the past we had create
> a mail alias like this:
> firstname.surname:    <staff-id on staff server>@staffserver.unl.ac.uk

>
> The problem is everybody expects the mail alias to be in the form of
> I.Surname, and we have had e-mails ending up in wrong places. Is there any
> way to solve the problem, i.e if there are two I.Surname then it asks the
> sender whom do you want to send the mail?


ROTFL, I'm afraid.

You can implement this by aliasing I.Surname to a pipe that sends back
an appropriate message. Or you could do it by an autoreply transport.
But consider: Do you really want to?

Think about it. Your vice-chancellor is called V.I.Person and all goes
well for years, until a junior temporary research assistant, also called
V.I.Person, joins your staff. Suddenly all the vice-chancellor's mail
gets refused and sent back (probably to other V.I. persons) with this
"stupid message". Do you think your VC and her correspondents are going
to be pleased by this situation?

With a small number of people (say < 100) you can negotiate about this
kind of thing. Once it gets bigger than that, you are taking a bigger
and bigger risk. I bet there is, or has been, at least one VC and
probably several important professors called J.Smith. I append a message
that was posted on the DRUMS list some time back that tells a tale on
this topic.

In case it's of interest: at Cambridge we have permanent and unique mail
IDs that are never re-issued. These are used for addresses of the form
ph10@???. If people want something more "friendly" they have to use
a more specific domain such as a department or college, and within that
domain they can locally negotiate about their addresses without
bothering the central administrators. So you could have
J.Caesar@??? as well as J.Caesar@??? or whatever.
These can be simple forwardings to jc10@??? and jc11@???
if so desired. So not only do we distribute the interpretation of
"friendly" addresses, we also distribute the negotiation about what they
should be.

> Also will the alias file be read only if the name can not be resolved for
> incoming mail or everytime a mail comes? If the later were to be true then
> lot of cpu will be wasted since most mail are for students (total of 20,000)
> and not staff (1000).


That depends on whether you put your aliasfile director before or after
the localuser director. Looks like you want to put it after.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.



---------- Message about the perils of using real names --------

Date: Wed, 2 Jun 1999 10:51:54 -0700
From: bill@??? (WJCarpenter)
To: drums@???

I have seen the definition of ecstasy. It is this.

Once upon a time, I worked for a large company (6 digits worth of
employees). Me and my fellow malcontents argued vigorously for
several years for permanent and unique email IDs. Powers That Be
argued back that <Last@???> or <First.Last@???> or
<First.M.Last@???> or even <First.M.Last/shoesize=9.5@???>
were surely unique enough (and were dynamically resolved in a
company-wide database). It was the officially recommended way to have
your email address on your business cards and whatnot.

At one time, there were three people in the company with the same
First.Last as me (one with the same middle initial), but that argument
didn't prevail, presumably because I was just lowly scum. Then one
holy and blessed day, the company hired a person who happened to have
the same First.Last as one of the Powers That Be, instantly
invalidating his business cards and .sig file. The permanent and
unique (and, incidentally, user-selected) email ID feature was added
to the company-wide database within a couple of months.

We put down our torches and pitch forks and danced in the streets.