Re: [exim] Query on address rewriting - can it be done in an…

Inizio della pagina
Delete this message
Reply to this message
Autore: Jeremy Harris
Data:  
To: exim-users
Oggetto: Re: [exim] Query on address rewriting - can it be done in an ACL?
On 05/09/2010 03:00 PM, Ron White wrote:
> On Sun, 2010-05-09 at 14:34 +0100, Jeremy Harris wrote:
>> On 05/09/2010 08:16 AM, Ron White wrote:
>>> On Sun, 2010-05-09 at 12:31 +1000, Ted Cooper wrote:
>>>> This doesn't seem like a job for address rewriting. I just use a catch
>>>> all router at the end with specific conditions.
>>>>
>>>> I have a very old setup that will catch all crap sent to a domain I
>>>> specify in a directory. I should have changed this ages ago into
>>>> something more useful, but not many people use a catch all so it's not
>>>> something I want to change.
>>>>
>>>> Anyway, If I have a domain I want to catch all on, I "touch
>>>> /etc/exim/catchalladdress/<domain to catch>" and then this router
>>>> sitting at the bottom of my routers does the rest:
>>>>
>>>> # last router before default reject
>>>> catchall:
>>>>     driver = redirect
>>>>     domains = dsearch;/etc/exim/catchalladdress
>>>>     data = catchall@$domain
>>>>     cannot_route_message = Unknown user

>>>>
>>>> .. well, except that I also add an alias on that domain called
>>>> "catchall" which redirects itself to whatever account you want, OR just
>>>> create an account called catchall that collects everything.
>>>>
>>>> If you want, you can keep the original recipients by adding them as a
>>>> header.
>>>>
>>>> I only run a catch all so I can make up email addresses on the fly on a
>>>> spam/bacon trap only domain. Very useful for tagging which site which
>>>> addresses were entered into. Other than that, they're evil.
>>>>
>>>>
>>>>
>>> Hi Ted,
>>>
>>> Thanks for that. It's a little more complex in my set up because Exim
>>> handles mail for:
>>>
>>> 1. Locally hosted domains and recipients
>>> 2. Remote/relay to domains and recipients
>>> 3. Remote/relay domain may also have users locally hosted user
>>> accounts(such as postmaster/abuse/notifications).
>>>
>>> The catch-all is dynamic. The user can change the local part
>>
>> The we're talking at cross-purposes. Catchall, to me, means
>> that any local-part (for some particular domain) is accepted.
> That's right. The issue is the domain may be local or remote and the
> dynamic address needs to be verified.
>>
>>    which means
>>> (1) the final catch-all recipient needs to be verified so we don't
>>> accept mail for something we can't deliver (2) that catch all could be a
>>> locally routed account, a remote smtp destination (sub classes of 'by
>>> ip, by hostname, by mx) (3) the per-user settings of the destination
>>> catch all, which are set in the ACL's, would not be honoured potentially
>>> leading to spam/viruses flowing through unchecked. As far as I
>>> understand it using a router to do it means that you have accepted the
>>> message at that point.

>>
>> Not if you do recipient-verification in your RCPT acl. That calls the routers.
> But for locally hosted 'virtual' users I'm doing this in an ACL and
> checking against a mysql database. The reason for this is my lowest
> 'unit' is a recipient, not a domain. fred@??? may be a locally
> hosted user belonging to domain foo.bar, but randy@??? may be on a
> different host. The 'host' data could be of three types, an ip address,
> a hostname lookup or an mx lookup. The consensus was mixed when I asked
> about this and we arrived at an ACL being the best way to control this.
> Relay destinations are verified with a callout.


Ok, so why not just do your DB lookup for all your users, local or not? Have
the lookup return the delivery name, or NULL if not an acceptable
source address. The "delivery name" is a file path for "local" users (starting with
a slash), and a name@domain for "remote" users (no slash, but has the "@").
Catchalls are done by the DB lookup.

You only need the one lookup, done by a single redirect router. The router
handles the filename or remote-dest coming back (see docs chapter 22.6)
using both a file_transport (or directory_transport) and redirect_router
(ch. 15).

It's easily expandable to multiple destinations, and to deliver-to-pipe.
And it puts all the complex knowledge in the DB.


As you might guess, I don't like the rewrite facilities of Exim one bit.
You can do all you need with routers, and you always need some routers.
You don't need any rewrite rules, in general.

Cheers,
     Jeremy