Re: [Exim] hiding alias names

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: freeware
Dátum:  
Címzett: exim-users
Tárgy: Re: [Exim] hiding alias names
I'm encountering exactly this problem, but for different reasons.
Hotmail will throw a message into a junk mail folder if the To: or Cc:
headers do not contain the recipient's address. Other junk filters do
so too. I want to replace the alias in To: with the recipient, and in
some cases put the alias in the Cc: (so that people can either "reply"
to the sender or "reply all" to the list). I don't want the
individual recipients being listing in each message, for their
privacy.

I've already tried this with a static list of 20 recipients. I had to
send out a test message to the alias, then follow up with direct
messages generated by a custom shell script, warning them to expect
the prior message. Except for the one guy who replied, I still don't
know whether the other 19 got the message, configured their junk
filters, etc. It's not a computer-savvy group.

I've given a cursory look at external tools like Mailman and
Smartlist, but ultimately I need to get the addresses realtime via an
SQL query. Exim appears to have this power; the others seem to
require (and manage) their own database files.

I could write my own Perl script to collect the addresses from the
database, and call Exim for each, but was hoping to avoid that.

I also had some trouble even finding this thread. Doesn't this
feature have a name? "Exploding", I thought.

--Mike


On Thu, 22 Aug 2002, Philip Hazel wrote:
>On Thu, 22 Aug 2002, Peter Duffy wrote:
>
>> Assume that I've got a mail server mydomain.co.uk, and an entry in
>> /etc/aliases:
>>
>> dodgy_suppliers: fred.bloggs@???, joe.doe@???
>>
>> If I send a message to "dodgy_suppliers", it is sent successfully at the
>> expanded addresses, but arrives addressed to
>> "dodgy_suppliers@???", not the expanded address to which it
>> has been sent.
>
>Well, strictly, no. Each copy that arrives is addressed, *on the
>envelope*, to the recipient address. Otherwise it wouldn't get there.
>However, redirection (aliasing) does not change the contents of the To:
>header inside the message.
>
>> For blatantly obvious reasons, I don't want the users collected under
>> this alias to become aware that I have thus categorized them!! What I
>> want is for the "To:" header line to contain just the current address
>> from the alias expansion.
>
>The way I would expect most people to do this would not be to use
>system-wide aliases. After all, some other user of the system might have
>an entirely different list of dodgy_suppliers. I would expect that most
>people would use the features of their addressbooks to maintain lists
>like this. The MUAs that I've used would indeed replace the To: header
>line with the actual list, and you'd see that happen as you composed the
>message.
>
>Now, there is still a problem. An addressbook entry with multiple
>addresses might well put all of them into the To: header. You might not
>want that; you might want to send a separate message to each. I don't
>know much about very many MUAs, but perhaps there is one that can be
>configured to do that.
>
>> This seems to be an absurdly commonplace and
>> trivial requirement, but as yet I've not been able to find an explicit
>> way of achieving it. I eventually tried a rule to rewrite the "to"
>> header line, but at the point the rewrite happens, $local_part and
>> $domain still contain respectively "dodgy_suppliers" and
>> "mydomain.co.uk": there don't seem to be equivalent variables containing
>> the parts of the expanded address.
>
>That is the case for global rewrites. They happen when the message is
>received, before any aliasing etc.
>
>Actually, I think Exim can sort of do what you want. Investigate the use
>of header rewriting on transports. Check for the headers_rewrite option.
>You could rewrite the address in the To: header to be the address in the
>envelope. However, in order to do this, you would need to set max_rcpt=1
>on the smtp transport, so that it sends a separate copy for each
>recipient. This might have performance implications.