Can check_policy_service override sender_dependent_relayhost_maps
I use Amazon SES service as a relay. I control which sasl clients send through amazon with: main.cf: sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay_host A typical entry is: @example.com email-smtp.eu-west-1.amazonaws.com:25 master.cf: smtp inet n - - - - smtpd So if a client domain is in sender_relay_host then their outbound mail goes via amazon relay, otherwise postfix sends it directly to the recipient MX. But Amazon has a message size limit of 10MB so to allow a client to send larger emails I have to comment them out of the sender_relay_host so they are only subject to the the Postfix message size limit - in my case 40MB. I want to be able to have messages sent out directly if they are greater than 8MB, bypassing the relay, so I have taken the following action after reading Wietse's instructions in http://comments.gmane.org/gmane.mail.postfix.user/205963: I have the policy daemon postfwd running with the following entry: id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; size>800; sasl_username=~/^\S+$/ action=FILTER smtp:[127.0.0.1]25; main.cf: smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10040 This is meant to force any mail with size greater than 8MB to bypass the relay and go out directly, but it doesn't work - it uses the relay anyway. I have tested it with different, simple criteria i.e. where the sasl_username is a specific testu...@example.com but no joy. Postfwd is definitely running and listening on port 10040. So my question is how can I get "check_policy_service" to override sender_dependent_relayhost_maps Thank you, Chris Robinson
Re: Can check_policy_service override sender_dependent_relayhost_maps
To answer the question: man 5 postconf sender_dependent_relayhost_maps (default: empty) ... This information is overruled with relay_transport, sender_dependent_default_transport_maps, default_transport and with the transport(5) table. So that is no good. But there is a solution: You can override everything with the "FILTER transport:destination" directive. With Postfix 2.7 and later, you can omit the destination, so that Postfix will use the recipient domain as destination. man 5 access Note 3: the purpose of the FILTER command is to override message routing. To override the recipient's transport but not the next-hop destination, specify an empty filter destination (Postfix 2.7 and later), or specify a transport:destination that delivers through a different Postfix instance (Postfix 2.6 and earlier). Other options are using the recipient-dependent transport_maps or the sender-dependent sender_dependent_default_transport_maps features. The FILTER action takes effect for all recipients of a message. If a message has multiple FILTER actions, only the last one will take effect. Wietse
Re: Can check_policy_service override sender_dependent_relayhost_maps
On 20/01/2015 19:48, Wietse Venema wrote: To answer the question: man 5 postconf sender_dependent_relayhost_maps (default: empty) ... This information is overruled with relay_transport, sender_dependent_default_transport_maps, default_transport and with the transport(5) table. So that is no good. But there is a solution: You can override everything with the "FILTER transport:destination" directive. With Postfix 2.7 and later, you can omit the destination, so that Postfix will use the recipient domain as destination. man 5 access Note 3: the purpose of the FILTER command is to override message routing. To override the recipient's transport but not the next-hop destination, specify an empty filter destination (Postfix 2.7 and later), or specify a transport:destination that delivers through a different Postfix instance (Postfix 2.6 and earlier). Other options are using the recipient-dependent transport_maps or the sender-dependent sender_dependent_default_transport_maps features. The FILTER action takes effect for all recipients of a message. If a message has multiple FILTER actions, only the last one will take effect. Wietse Thanks so much for the reply. I have tried changing the postfwd.cf rule from: id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; sasl_username=~/^tes...@example.com$/ action=FILTER smtp:[127.0.0.1]25; to: id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; sasl_username=~/^tes...@example.com$/ action=FILTER; and id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; sasl_username=~/^tes...@example.com$/ action=FILTER smtp; and id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; sasl_username=~/^tes...@example.com$/ action=FILTER smtp:; and id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; sasl_username=~/^tes...@example.com$/ action=FILTER smtp:[]25; but the postfwd log entry shows the message hitting the "id=DEFAULT; action=dunno" catchall entry at the end. I am obviously doing something stupid with my next-hop syntax or the whole rule. I will try again tomorrow morning - it's late here. Chris Robinson
Re: Can check_policy_service override sender_dependent_relayhost_maps
On 1/20/2015 2:08 PM, Chris Robinson wrote: > > On 20/01/2015 19:48, Wietse Venema wrote: >> To answer the question: >> >> man 5 postconf >> sender_dependent_relayhost_maps (default: empty) >> ... >> This information is overruled with relay_transport, >> sender_dependent_default_transport_maps, default_transport and >> with the transport(5) table. >> >> So that is no good. But there is a solution: >> >> You can override everything with the "FILTER transport:destination" >> directive. With Postfix 2.7 and later, you can omit the destination, >> so that Postfix will use the recipient domain as destination. >> >> man 5 access >> >> Note 3: the purpose of the FILTER command is to override message >> routing. To override the recipient's transport but not the >> next-hop destination, specify an empty filter destination >> (Postfix 2.7 and later), or specify a transport:destination >> that delivers through a different Postfix instance (Postfix 2.6 >> and earlier). Other options are using the recipient-dependent >> transport_maps or the sender-dependent >> sender_dependent_default_transport_maps features. >> >> The FILTER action takes effect for all recipients of a message. >> >> If a message has multiple FILTER actions, only the last one will >> take effect. >> >> Wietse > Thanks so much for the reply. > > I have tried changing the postfwd.cf rule from: > > id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; > sasl_username=~/^tes...@example.com$/ action=FILTER smtp:[127.0.0.1]25; > to: > id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; > sasl_username=~/^tes...@example.com$/ action=FILTER; > and > id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; > sasl_username=~/^tes...@example.com$/ action=FILTER smtp; > and > id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; > sasl_username=~/^tes...@example.com$/ action=FILTER smtp:; > and > id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; > sasl_username=~/^tes...@example.com$/ action=FILTER smtp:[]25; > > but the postfwd log entry shows the message hitting the "id=DEFAULT; > action=dunno" catchall entry at the end. > > I am obviously doing something stupid with my next-hop syntax or the > whole rule. I will try again tomorrow morning - it's late here. > > Chris Robinson > > > The correct response from your policy service is "FILTER smtp:" (without quotes, of course) ie. in "FILTER transport:destination" leave the destination empty. Looks as if you're having trouble matching the expected username in postfwd. Make sure you're using the same name as logged by postfix smtpd process as sasl_username= If that doesn't get you going, you can get some rule help from the postfwd users list. The postfix part is working correctly. -- Noel Jones
Re: Can check_policy_service override sender_dependent_relayhost_maps
On 20/01/2015 23:03, Noel Jones wrote: On 1/20/2015 2:08 PM, Chris Robinson wrote: On 20/01/2015 19:48, Wietse Venema wrote: To answer the question: man 5 postconf sender_dependent_relayhost_maps (default: empty) ... This information is overruled with relay_transport, sender_dependent_default_transport_maps, default_transport and with the transport(5) table. So that is no good. But there is a solution: You can override everything with the "FILTER transport:destination" directive. With Postfix 2.7 and later, you can omit the destination, so that Postfix will use the recipient domain as destination. man 5 access Note 3: the purpose of the FILTER command is to override message routing. To override the recipient's transport but not the next-hop destination, specify an empty filter destination (Postfix 2.7 and later), or specify a transport:destination that delivers through a different Postfix instance (Postfix 2.6 and earlier). Other options are using the recipient-dependent transport_maps or the sender-dependent sender_dependent_default_transport_maps features. The FILTER action takes effect for all recipients of a message. If a message has multiple FILTER actions, only the last one will take effect. Wietse Thanks so much for the reply. I have tried changing the postfwd.cf rule from: id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; sasl_username=~/^tes...@example.com$/ action=FILTER smtp:[127.0.0.1]25; to: id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; sasl_username=~/^tes...@example.com$/ action=FILTER; and id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; sasl_username=~/^tes...@example.com$/ action=FILTER smtp; and id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; sasl_username=~/^tes...@example.com$/ action=FILTER smtp:; and id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; sasl_username=~/^tes...@example.com$/ action=FILTER smtp:[]25; but the postfwd log entry shows the message hitting the "id=DEFAULT; action=dunno" catchall entry at the end. I am obviously doing something stupid with my next-hop syntax or the whole rule. I will try again tomorrow morning - it's late here. Chris Robinson The correct response from your policy service is "FILTER smtp:" (without quotes, of course) ie. in "FILTER transport:destination" leave the destination empty. Looks as if you're having trouble matching the expected username in postfwd. Make sure you're using the same name as logged by postfix smtpd process as sasl_username= If that doesn't get you going, you can get some rule help from the postfwd users list. The postfix part is working correctly. -- Noel Jones Got it right - thank you Wietse, Noel! The empty destination like "smtp:" did it, plus I was missing the semicolon after the sasl_username rule part. The semicolon also made two other rules work ;-) Now all is sweetness and light. Chris Robinson