Re: [exim] multiple dummy domains

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Gary Stainburn
Dátum:  
Címzett: exim-users
Tárgy: Re: [exim] multiple dummy domains
On Tuesday 28 June 2016 17:36:54 Mike Brudenell wrote:
> Hi, Gary -
>
> There are several ways of doing it, with the most general perhaps being to
> do lookups in text files — perhaps one per domain — to see if the address
> is one to rewrite and, if so, what it should be rewritten to.
>


This was my first (and most likely) choice. I already have a file

/etc/aliases.d/existing_domain.com

which is a simple alias file and contains all of the valid email addresses for
that domain. My thought is to create symlinks to

/etc/aliases.d/webdomain1.com
/etc/aliases.d/webdomain2.com

etc. and then add them to my exim.conf. This way I only ever have one file to
edit.

> However the really simple way is to take a look at the *Address
> Rewriting* chapter
> in the Exim specification:
>
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch-address_rewriti
>ng.html
>


I did consider using rewriting rules, but feel this method is less clear or
obvious. I feel both the logic and the exim.conf would be clearer using the
method above.

>
> This feature lets you rewrite any or all of the normal message headers
> and/or the envelope. So you could rewrite the Envelope To ("env-to") in
> order to change the recipient the message is delivered to. (Alone, this
> would leave the visible To header showing the original address, but you
> could rewrite this as well if you wished.)
>
> Of course you shouldn't blindly rewrite *every* domain's addresses! You'll
> first want to check if the domain is one of yours and that you need to
> rewrite it. You could do this using an lsearch of a text file to see if the
> domain is listed in it. Or maybe consider using a database instead if you
> have loads of domains.
>
> See the section *Rewriting patterns* in that chapter for a database lookup
> using "partial-dbm" in the match-pattern to give you some ideas.
>
> Cheers,
> Mike Brudenell
>