Re: [exim] routing logic based on sender and recipient

Góra strony
Delete this message
Reply to this message
Autor: Jasen Betts
Data:  
Dla: exim-users
Temat: Re: [exim] routing logic based on sender and recipient
On 2013-07-23, Florin Andrei <florin@???> wrote:
> I am banging my head against the wall trying to solve a routing problem
> with a different MTA, and I'm getting nowhere.
>
> I know Exim is very configurable, but I've never actually used it. I'd
> like to setup a test instance and try to achieve the desired routing
> algorithm. This is for a QA site which is a copy of the production site,
> with some exceptions: e.g., emails generated during testing must be
> routed locally, as opposed to blasting the Internet with bogus messages.
> There are some extra twists as well.
>
> The mail server is receiving email from several QA machines via SMTP,
> and then delivers it according to various rules.
>
> The logic is this:
>
> 1. All emails with a sender @boringdomain.com will be routed to the
> Internet as if this was a plain relay, no exceptions, no special rules.
> Basically, I need to punch a clean relay hole through the system for
> these senders. If there's no match here, go to next rule:
>
> 2. All emails with a recipient within a very short list
> (jim@???, joe@???) are delivered locally, and
> will typically be processed by various scripts specified in ~/.forward.
> If there's no match here, then next:
>
> 3. All emails with the recipient @fancydomain.com are to be delivered
> via SMTP to relay1.fancydomain.com. If no match here, then:
>
> 4. All other emails will be delivered locally (and then will bounce with
> user not found, and sent to a local account which is the sender for
> these emails, and will get caught by other scripts).
>
> I have rules 2-4 already implemented in a different MTA software for a
> long time now and everything works great, I just can't do sender-based
> routing before recipient-based for the new rule #1.
>
> Could someone sketch an Exim config example that would achieve the logic
> described above? Thank you.


Let me get this straight, do you want emails addressed to fancydomain.com
that are sent froim your LAN to be sent out onto the internet and not
processed like ones that arrive from outside?


This is _only_ a sketch.

put the routers in the order you described them, the first one to
succeed will claim the email.

# 1

dnslookup router
condition = ${if eqi {${domain:$sender}}{boringdomain.com}}
transport = remote_smtp

#2

use routers from the example config file
you may want to use a local_parts = condition in these routers if
you have user accounts in the exim server that you do not want to
accept mail for on this machine.

#3

manualroute router, smtp transport. see documentation

#4

is default behaviour - no code is needed


specify verify=recipient/callout=10s somwhere in the RCPT ACL chain seen
by inbound messages. (and not outbound) to avoid producing backscatter.

something like this in the rcpt ACL, probably in addition to other
checks that normally go there:

  accept
    # your LAN network here - 
    hosts = 10.0.0.0/8 
    # or omit that line if you want to allow any host to send:
    conditon ${if eqi {${domain:$sender}}{boringdomain.com}}
    verify = recipient


  deny 
    # your LAN network here:
    hosts = 10.0.0.0/8 
    # or omit that line if you want to allow any host to send:
    conditon ${if eqi {${domain:$sender}}{boringdomain.com}}
    message = unroutable address <$recipient>


  deny 
    domains = fancydomain.com
    !verify = recipient/callout=10s
    message = mailbox <$recipient> does not exist 


  accept
    domains = fancydomain.com


  deny 
    message = this is not an open relay




--
⚂⚃ 100% natural