source & destination based routing: When to decide where to go you
Fabio Pietrosanti
i am using postfix 2.3 doing source based routing with
sender_dependent_relayhost_maps .
I am using SQL table to do dynamic lookup and do routing based on source.
I need to match in the sql query not only the Sender but also the
Recipient because the database has to reply with the right smtp server
by looking at the couple of From + To .
Unfortunately the table in the sql statement allow me to only put a "%s"
which match the Sender:
sender_dependent_relayhost_maps =
pgsql:/etc/postfix/virtual_source_based_transport.cf
The query that's actually working is:
"query = select fqdn from postfix_source_table where name = '%s';"
I would like to make the routing decision be managed by something like that:
"query = select fqdn from postfix_source_table where sender = '%sender'
and recipient ='%recipient';"
My postfix is managing emails which "ever" have only one recipient per
email message so there's no chance to have more than one recipient.
My problem is that i can make the routing decision only by matching both
the sender and the recipient.
There's a way to do that without having to write an smtp wrapper?
Sandy Drobic
get away with using restriction classes. If that is too cumbersome, you
probably have to write a policy daemon for that.
Sandy
--
List replies only please!
Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
Fabio Pietrosanti
> Depending on how many sender/recipient pairs you are doing this, you
> can get away with using restriction classes. If that is too
> cumbersome, you probably have to write a policy daemon for that.
I will ever had "1 email = 1 pair of sender/recipient" because postfix
receive emails from a content filter that send to him only 1 email per
recipient.
Sandy Drobic
If you only have to match at most a few dozen (sender/recipient -> route)
then you can set up restriction classes. Retriction classes are
hard-coded, if you can't set them up and forget them they won't fit your
purpose.
If you want to configure LOTs of these or worse still give control of such
matching into your customers hand via a webpage for example, you NEED a
policy deamon.
mouss
> Hi all,
>
> i am using postfix 2.3 doing source based routing with
> sender_dependent_relayhost_maps .
>
> I am using SQL table to do dynamic lookup and do routing based on source.
>
> I need to match in the sql query not only the Sender but also the
> Recipient because the database has to reply with the right smtp server
> by looking at the couple of From + To .
>
> Unfortunately the table in the sql statement allow me to only put a "%s"
> which match the Sender:
> sender_dependent_relayhost_maps =
> pgsql:/etc/postfix/virtual_source_based_transport.cf
>
> The query that's actually working is:
> "query = select fqdn from postfix_source_table where name = '%s';"
>
> I would like to make the routing decision be managed by something like that:
> "query = select fqdn from postfix_source_table where sender = '%sender'
> and recipient ='%recipient';"
>
This would require modifying the sql code. the issue is that this can't
be done in single key maps (hash, ...).
I would propose adding support for keys of the form:
channel|client|sender|rcpt
but this requires non trivial design. in particular, the "fallback"
mechanism (wildcard for each field) as we don't want to do 20 queries
everytime.
> My postfix is managing emails which "ever" have only one recipient per
> email message so there's no chance to have more than one recipient.
>
> My problem is that i can make the routing decision only by matching both
> the sender and the recipient.
>
> There's a way to do that without having to write an smtp wrapper?
>
>
>
you can use maildrop (or procmail) to rewrite the rcpt based on the
route you want, then have generic map rewrite the rcpt to the original form.
but a content_filter (use smtpprox to do the smtp part for you) is simpler.
Fabio Pietrosanti
> If you want to configure LOTs of these or worse still give control of
> such matching into your customers hand via a webpage for example, you
> NEED a policy deamon.
Sandy Drobic
transport:destination". Though I am starting to wonder just what purpose
your complicated routing game is supposed to fulfil.
mouss
> Fabio Pietrosanti wrote:
>> Sandy Drobic wrote:
>>> If you want to configure LOTs of these or worse still give control of
>>> such matching into your customers hand via a webpage for example, you
>>> NEED a policy deamon.
>> How it's possible to use a policy daemon to manage routing decisions?
>>
> The only way is for the policyserver to return "FILTER
> transport:destination". Though I am starting to wonder just what
> purpose your complicated routing game is supposed to fulfil.
FILTER applies to a message, not to a recipient, and is overriden by
FILTER statements in subsequent checks. OP needs a content filter or an
MDA.
Fabio Pietrosanti
> FILTER applies to a message, not to a recipient, and is overriden by
> FILTER statements in subsequent checks. OP needs a content filter or
> an MDA.
statement in order to modify the routing behaviour?
Postfix ask what to do to the policy server by passing:
recipient=x...@x.com
sender=y...@y.com
Policy server check in my database with a sql statement like 'select
outgoing_gateway from routing_tables where recipient=x...@x.com and
sender=y...@y.com' .
Policy server return as action FILTER smtp:host:port
Does this could work?
Please consider that every message that will be matched by this postfix
instance will ever had only 1 sender and 1 recipient.
Fabio Pietrosanti
> # main.cf
> smtpd_recipient_restrictions = ..., ..., check_recipient_access
> mysql:/usr/local/etc/postfix/content_filter.mysql
>
>
> # /usr/local/etc/postfix/content_filter.mysql
> select_field='FILTER smtp-amavis:[127.0.0.1]:10024'
> where_field=CONCAT(login, '@', <internal domain>)
> additional_conditions=and bypass_spam_checks='N'
>
mmmm, you are using a policy server without having a policy server!
But when using this approach, how can i get the sender and recipient
value to get them passed to the SQL query?
Because my issue is related by taking the routing decision by looking at
recipient and sender together.
Sandy Drobic
> mouss wrote:
>> FILTER applies to a message, not to a recipient, and is overriden by
>> FILTER statements in subsequent checks. OP needs a content filter or
>> an MDA.
> You mean that policy server cannot return to postfix the "FILTER"
> statement in order to modify the routing behaviour?
No, mouss correctly stated that the filter decision will be decided for
the message. In case of multi-recipient messages the mail for all of these
recipients will then be routed according to the filter statement.
That means if you want to filter with the filter action you should make
sure to define a transport that takes care to separate multi-recipient
messages into several single-recipient messages.
<transportname>_destination_recipient_limit=1
> Postfix ask what to do to the policy server by passing:
> recipient=x...@x.com
> sender=y...@y.com
>
> Policy server check in my database with a sql statement like 'select
> outgoing_gateway from routing_tables where recipient=x...@x.com and
> sender=y...@y.com' .
>
> Policy server return as action FILTER smtp:host:port
>
> Does this could work?
Yes, that should work, provided you only have single-recipient messages at
that stage.
mouss
> Fabio Pietrosanti wrote:
>> mouss wrote:
>>> FILTER applies to a message, not to a recipient, and is overriden by
>>> FILTER statements in subsequent checks. OP needs a content filter or
>>> an MDA.
>> You mean that policy server cannot return to postfix the "FILTER"
>> statement in order to modify the routing behaviour?
>
> No, mouss correctly stated that the filter decision will be decided
> for the message. In case of multi-recipient messages the mail for all
> of these recipients will then be routed according to the filter
> statement.
>
> That means if you want to filter with the filter action you should
> make sure to define a transport that takes care to separate
> multi-recipient messages into several single-recipient messages.
>
> <transportname>_destination_recipient_limit=1
>
It would be too complicated to implement this. he would need a first
smtpd to do the transport decision, and another one to do the FILTER
decision (in a single "step", FILTER is performed before transprt so you
can't mix their effects).
a content_filter is better.
Note: He can use maildrop/procmail as a content_filter...
>
>> Postfix ask what to do to the policy server by passing:
>> recipient=x...@x.com
>> sender=y...@y.com
>>
>> Policy server check in my database with a sql statement like 'select
>> outgoing_gateway from routing_tables where recipient=x...@x.com and
>> sender=y...@y.com' .
>>
>> Policy server return as action FILTER smtp:host:port
smtp:[ip]:port is better.