Re: [exim] Rewrite FROM address

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Luke Sheldrick
Fecha:  
A: exim-users
Asunto: Re: [exim] Rewrite FROM address
Hi Phil,

Hope you don't mind me contacting you again, however have just come to look
at this again, and have had a thought.

My config for my transporters looks like:

redirect:
        driver = redirect
        local_part_suffix = +* : -*
        local_part_suffix_optional
        data = ${lookup{$local_part@$domain}
lsearch{/etc/exim/exim-redirect-mail-for-this-list-of-users.txt}}


internal:
        driver = manualroute
        local_part_suffix = +* : -*
        local_part_suffix_optional
        domains = +relay_to_domains
        transport = remote_smtp
        route_data =
${lookup{$domain}partial-lsearch{/etc/exim/exim-deliver-to-these-servers.txt
}}


external:
        driver = manualroute
        domains = ! +relay_to_domains
        transport = remote_smtp
        ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
        route_list = * lnd04.an0key.net
        no_more



how would I phrase you extra config to allow the rewrites?





-----Original Message-----
From: Phil Pennock [mailto:exim-users@spodhuis.org]
Sent: 28 January 2008 23:25
To: Luke Sheldrick
Cc: Exim Mailing List
Subject: Re: [exim] Rewrite FROM address

On 2008-01-26 at 17:08 +0000, Luke Sheldrick wrote:
> Another quick question, I personally utilise receipent forwarding or
> whatever it is called, i.e. Luke+forumname@??? will come to
> luke@???


Sub-addressing is the modern name.

Eg: RFC 5233 Sieve Email Filtering: Subaddress Extension

> However to reply to groups, I have subscribed to using this method, means
> the mail has to come from that address. The way I am doing it, is to setup

a
> new imap account in my email software. However this is getting all a bit
> much :P


A whole new account, instead of delivering to a shared folder which you
subscribe to? Seems excessive.

> Is there a way to get exim to rewrite the from, if the to is a paticular
> address. I.e. If a mail comes from luke@???, destined for
> user-forum@???, it can rewrire it to luke+somesite@????


Sure, but what about when you group reply to a user and the
forum/list/whatever is only CC'd?

> I am guessing it can, but havent a clue on the config.


Address rewriting, with a string expansion based on the recipient.
Failed expansions cause the rewrite to just be ignored. You want to do
this per-recipient, rather than trying to resolve rules about multiple
recipients in a list; however, this has the effect of "leaking" the
non-subaddressed email address to all recipients that you reply to, and
then any subsequent replies from them will include the non-subaddressed
form too.

All of the below is untested by me and may require further debugging by
you.

Let's say that /etc/mail/subaddress-maps/ contains files for each user
on your system, so that there's a file "luke" for you. In that file,
you will have lines looking like:

  user-forum@??? :    luke+somesite


On the remote SMTP transport (pardon the very long lines):

max_rcpt = 1
headers_rewrite = *@an0key.co.uk
${lookup{$local_part@$domain}lsearch{/etc/mail/subaddress-maps/$1}{$value}fa
il}@??? f
return_path =
${lookup{$local_part@$domain}lsearch{/etc/mail/subaddress-maps/$1}{$value}fa
il}

Note that I provided three lines above; the second ends with a single
field "f"; if you don't see just three lines then check your wrapping.
For your config, insert \-line-continuations to taste.

Note that you can never have more than one RCPT per message for this to
work, hence "max_rcpt"; this has some performance implications but
they're probably insignificant for a personal server. You probably want
to have:
log_selector = +return_path_on_delivery
in your main config, to get the actual return path logged.

If you decide to put this data into an SQL DB or something instead of
the filesystem and you're not sure about the lookup caching, then you
might do this lookup once in the Router, setting "data = " and then
refer to this with $address_data in the transport. For that, you would
probably want to set a string ":FAIL:" instead of failing the expansion,
then explicitly fail the transport's expansions. Ie, change "fail" to
"{:FAIL:}" and then use:
return_path = ${if !eq{$address_data}{:FAIL:}{$address_data}fail}

-Phil