Order of parameters for smtpd_recipient_restrictions

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Order of parameters for smtpd_recipient_restrictions

Justin Pasher
I've been reading the lists for the past few weeks, gaining tidbits of
additional knowledge here and there about Postfix and I decided to work on
improving the efficiency of the server (even if just a little bit).

Two things I've read recently:

1: The smtpd_*_restrictions directive should be thought of as "at what stage
do you want to do the processing"
2: The smtpd_*_restrictions directives (in my case
smtpd_recipient_restrictions) processes the options in the order they are
listed.

Giving this information, I tried reordering my main.cf file a bit (Postfix
2.3.8 on Debian etch). I ultimately collapsed the separate options under
smtpd_client_restrictions and smtpd_sender_restrictions into the single
smtpd_recipient_restrictions directive. As postconf shows below, here are
the currently option for smtpd_recipient_restrictions

smtpd_recipient_restrictions = permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unknown_sender_domain,
  reject_unknown_reverse_client_hostname,
  reject_non_fqdn_helo_hostname,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client xbl.spamhaus.org,
  reject_rbl_client sbl.spamhaus.org,
  check_sender_access hash:/etc/postfix/check_sender_access

I recently pushed reject_unauth_destination above the other reject_* options
in an attempt to make the processing stop right then and there when the
sender provides an invalid email address (namely to avoid RBL checks). All
valid email addresses are listed in /etc/postfix/relay_recipient_maps (all
lines end with the "OK" code).

The docs for reject_unauth_destination indicate that the request is not
rejected if the domain is listed under relay_domains, mydestination,
inet_interfaces, proxy_interfaces, virtual_alias_domains, or
virtual_mailbox_domains, but I assume Postfix will read the
relay_recipient_maps to verify the recipient...? I'm still getting entries
in the log file that said email was rejected due to "Helo command rejected",
even when the recipient email address is not listed in relay_recipient_maps.

Samples of my config files are below (soft_bounce is set right now in case I
break something)...

Thanks.

Justin Pasher

/etc/postfix/check_sender_access
--------------------
# used as a poor man's "block this sender" list
[hidden email]   REJECT Blocked
[hidden email]   REJECT Blocked

/etc/postfix/transport_maps
--------------------
.relay2-example.com        smtp:

/etc/postfix/relay_recipient_maps
--------------------
[hidden email] OK
[hidden email] OK
[hidden email] OK

postconf -n
--------------------
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 1d
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
maximal_backoff_time = 2h
maximal_queue_lifetime = 3d
minimal_backoff_time = 30m
mydestination = $myhostname, localhost.$mydomain, localhost, nmgsupport.com
mydomain = newmediagateway.com
mynetworks = 127.0.0.0/8 10.205.152.0/21
myorigin = $myhostname
parent_domain_matches_subdomains =
debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqp
d_authorized_clients,smtpd_access_maps
queue_run_delay = 15m
receive_override_options = no_address_mappings
recipient_delimiter = +
relay_domains = $mydestination, sub.relay1-example.com, relay1-example.com,
relay2-example.com
relay_recipient_maps = hash:/etc/postfix/relay_recipient_maps
relay_transport = smtp:[10.205.154.91]
relayhost =
smtp_host_lookup = native
smtpd_banner = $myhostname ESMTP $mail_name (GNU/Linux)
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_reverse_client_hostname,
reject_non_fqdn_helo_hostname,
reject_rbl_client bl.spamcop.net,
reject_rbl_client xbl.spamhaus.org,
reject_rbl_client sbl.spamhaus.org,
check_sender_access hash:/etc/postfix/check_sender_access
soft_bounce = yes
transport_maps = hash:/etc/postfix/transport_maps

Reply | Threaded
Open this post in threaded view
|

Re: Order of parameters for smtpd_recipient_restrictions

Noel Jones-2
Justin Pasher wrote:

> I've been reading the lists for the past few weeks, gaining tidbits of
> additional knowledge here and there about Postfix and I decided to work on
> improving the efficiency of the server (even if just a little bit).
>
> Two things I've read recently:
>
> 1: The smtpd_*_restrictions directive should be thought of as "at what stage
> do you want to do the processing"
> 2: The smtpd_*_restrictions directives (in my case
> smtpd_recipient_restrictions) processes the options in the order they are
> listed.

Yes, both of those statements are true.


>
> Giving this information, I tried reordering my main.cf file a bit (Postfix
> 2.3.8 on Debian etch). I ultimately collapsed the separate options under
> smtpd_client_restrictions and smtpd_sender_restrictions into the single
> smtpd_recipient_restrictions directive.

Good.  This usually makes it easier to read.


> As postconf shows below, here are
> the currently option for smtpd_recipient_restrictions
>
> smtpd_recipient_restrictions = permit_mynetworks,
>   permit_sasl_authenticated,
>   reject_unauth_destination,
>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,

I doubt reject_non_fqdn_recipient will catch anything when
it's after reject_unauth_destination, but it's a very cheap
check so it won't hurt anything.

>   reject_unknown_sender_domain,
>   reject_unknown_reverse_client_hostname,
>   reject_non_fqdn_helo_hostname,
>   reject_rbl_client bl.spamcop.net,
>   reject_rbl_client xbl.spamhaus.org,
>   reject_rbl_client sbl.spamhaus.org,

The zen.spamhaus.org rbl includes both sbl and xbl data, along
with other items.  Replace the above two lines with
    reject_rbl_client zen.spamhaus.org
and please see
http://www.spamhaus.org/organization/dnsblusage.html


>   check_sender_access hash:/etc/postfix/check_sender_access
>
> I recently pushed reject_unauth_destination above the other reject_* options
> in an attempt to make the processing stop right then and there when the
> sender provides an invalid email address (namely to avoid RBL checks). All
> valid email addresses are listed in /etc/postfix/relay_recipient_maps (all
> lines end with the "OK" code).
>
> The docs for reject_unauth_destination indicate that the request is not
> rejected if the domain is listed under relay_domains, mydestination,
> inet_interfaces, proxy_interfaces, virtual_alias_domains, or
> virtual_mailbox_domains,

The docs are correct.

> but I assume Postfix will read the
> relay_recipient_maps to verify the recipient...?

reject_unauth_destination is only concerned with the domain
name, not the user name.  There are other controls for the
recipient name.

> I'm still getting entries
> in the log file that said email was rejected due to "Helo command rejected",
> even when the recipient email address is not listed in relay_recipient_maps.
>

When "smtpd_reject_unlisted_recipient = yes" (the default),
postfix performs the recipient validation at the end of the
smtpd_recipient_restrictions list.  If you want to do this
check earlier, you can specify "reject_unlisted_recipient"
somewhere in your smtpd_recipient_restrictions list, such as
just after reject_unauth_destination.
http://www.postfix.org/postconf.5.html#reject_unlisted_recipient

You may also want to reject mail that claims to be from a
local user if that local user is unknown.
http://www.postfix.org/postconf.5.html#reject_unlisted_sender


--
Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Order of parameters for smtpd_recipient_restrictions

mouss-2
In reply to this post by Justin Pasher
Justin Pasher wrote:

> I've been reading the lists for the past few weeks, gaining tidbits of
> additional knowledge here and there about Postfix and I decided to work on
> improving the efficiency of the server (even if just a little bit).
>
> Two things I've read recently:
>
> 1: The smtpd_*_restrictions directive should be thought of as "at what stage
> do you want to do the processing"
> 2: The smtpd_*_restrictions directives (in my case
> smtpd_recipient_restrictions) processes the options in the order they are
> listed.
>
> Giving this information, I tried reordering my main.cf file a bit (Postfix
> 2.3.8 on Debian etch). I ultimately collapsed the separate options under
> smtpd_client_restrictions and smtpd_sender_restrictions into the single
> smtpd_recipient_restrictions directive. As postconf shows below, here are
> the currently option for smtpd_recipient_restrictions
>
> smtpd_recipient_restrictions = permit_mynetworks,
>   permit_sasl_authenticated,
>   reject_unauth_destination,
>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>  

you can put
    reject_unlisted_recipient
    reject_unlisted_sender
if you want to reject mail to invalid users before doing other checks.

>   reject_unknown_sender_domain,
>  

put this (reject_unknown_sender_domain) after other checks. it incurs a
DNS query to a possibly forged domain.

>   reject_unknown_reverse_client_hostname,
>  

you can add
    reject_invalid_helo_hostname
here. check the docs for what it does.

>   reject_non_fqdn_helo_hostname,
>   reject_rbl_client bl.spamcop.net,
>   reject_rbl_client xbl.spamhaus.org,
>   reject_rbl_client sbl.spamhaus.org,
>  

you are doing two queries to spamhaus. consider using zen.spamhaus.org
instead. then put it before spamcop.

>   check_sender_access hash:/etc/postfix/check_sender_access
>
> I recently pushed reject_unauth_destination above the other reject_* options
> in an attempt to make the processing stop right then and there when the
> sender provides an invalid email address (namely to avoid RBL checks). All
> valid email addresses are listed in /etc/postfix/relay_recipient_maps (all
> lines end with the "OK" code).
>  

reject_unauth_destination is used to stop open relay. this is why you
should put it as soon as possible (which is what you are doing now).
> The docs for reject_unauth_destination indicate that the request is not
> rejected if the domain is listed under relay_domains, mydestination,
> inet_interfaces, proxy_interfaces, virtual_alias_domains, or
> virtual_mailbox_domains, but I assume Postfix will read the
> relay_recipient_maps to verify the recipient...? I'm still getting entries
> in the log file that said email was rejected due to "Helo command rejected",
> even when the recipient email address is not listed in relay_recipient_maps.
>  

see above (reject_unlisted_*).  by default, postfix will reject invalid
recipients after smtpd_recipient_restrictions. with reject_unlisted_*
checks, you can chose the order and thus reject invalid addresses before
expensive checks.

> Samples of my config files are below (soft_bounce is set right now in case I
> break something)...
>
> Thanks.
>
> Justin Pasher
>
> /etc/postfix/check_sender_access
> --------------------
> # used as a poor man's "block this sender" list
> [hidden email]   REJECT Blocked
> [hidden email]   REJECT Blocked
>  

such sender blacklists require work and are not very effective as
spammers forge random addresses (well, if you want to block
@badmarkteers.example, it may be ok...). better block based on the client.
> /etc/postfix/transport_maps
> --------------------
> .relay2-example.com        smtp:
>  

why do you do this. the default (relay:) is better. if you need to
specify the destination host, use
.relay2.example            relay:[192.0.2.3]
otherwise, use DNS (MX) for the transport. you can use a private DNS
zone if you know whow to setup this (you can use either BIND views or
"split horizon").

> /etc/postfix/relay_recipient_maps
> --------------------
> [hidden email] OK
> [hidden email] OK
> [hidden email] OK
>
> postconf -n
> --------------------
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> bounce_queue_lifetime = 1d
> config_directory = /etc/postfix
> content_filter = smtp-amavis:[127.0.0.1]:10024
> mailbox_command = procmail -a "$EXTENSION"
> mailbox_size_limit = 0
> maximal_backoff_time = 2h
> maximal_queue_lifetime = 3d
> minimal_backoff_time = 30m
> mydestination = $myhostname, localhost.$mydomain, localhost, nmgsupport.com
> mydomain = newmediagateway.com
> mynetworks = 127.0.0.0/8 10.205.152.0/21
> myorigin = $myhostname
> parent_domain_matches_subdomains =
> debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqp
> d_authorized_clients,smtpd_access_maps
> queue_run_delay = 15m
> receive_override_options = no_address_mappings
>  

this is risky. better put no_address_mappings in master.cf for those
services that use it. otherwise, unfiltered mail will not be subject to
rewrite...
> recipient_delimiter = +
> relay_domains = $mydestination, sub.relay1-example.com, relay1-example.com,
> relay2-example.com
>  

remove mydestination from relay_domains.

> relay_recipient_maps = hash:/etc/postfix/relay_recipient_maps
> relay_transport = smtp:[10.205.154.91]
>  

what's this for?

> relayhost =
> smtp_host_lookup = native
> smtpd_banner = $myhostname ESMTP $mail_name (GNU/Linux)
> smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
> reject_unauth_destination,
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_reverse_client_hostname,
> reject_non_fqdn_helo_hostname,
> reject_rbl_client bl.spamcop.net,
> reject_rbl_client xbl.spamhaus.org,
> reject_rbl_client sbl.spamhaus.org,
> check_sender_access hash:/etc/postfix/check_sender_access
> soft_bounce = yes
> transport_maps = hash:/etc/postfix/transport_maps
>
>  

Reply | Threaded
Open this post in threaded view
|

RE: Order of parameters for smtpd_recipient_restrictions

Justin Pasher
In reply to this post by Noel Jones-2
> -----Original Message-----
> From: Noel Jones [mailto:[hidden email]]
> Sent: Friday, June 27, 2008 5:14 PM
> To: Justin Pasher; [hidden email]
> Subject: Re: Order of parameters for smtpd_recipient_restrictions
>
> Justin Pasher wrote:
...

> > As postconf shows below, here are
> > the currently option for smtpd_recipient_restrictions
> >
> > smtpd_recipient_restrictions = permit_mynetworks,
> >   permit_sasl_authenticated,
> >   reject_unauth_destination,
> >   reject_non_fqdn_sender,
> >   reject_non_fqdn_recipient,
> >   reject_unknown_sender_domain,
> >   reject_unknown_reverse_client_hostname,
> >   reject_non_fqdn_helo_hostname,
> >   reject_rbl_client bl.spamcop.net,
> >   reject_rbl_client xbl.spamhaus.org,
> >   reject_rbl_client sbl.spamhaus.org,
>
> The zen.spamhaus.org rbl includes both sbl and xbl data, along
> with other items.  Replace the above two lines with
>     reject_rbl_client zen.spamhaus.org
> and please see
> http://www.spamhaus.org/organization/dnsblusage.html

I currently use the two because I didn't want to include pbl.spamhaus.org
due to some clients using our mail server for sending when they are on
dynamic IP addresses. However, this was before I moved the reject_rbl_client
directive into smtpd_recipient_restrictions (after
permit_sasl_authenticated). Now that they are in one list, I can probably
switch over to zen.

> > The docs for reject_unauth_destination indicate that the request is not
> > rejected if the domain is listed under relay_domains, mydestination,
> > inet_interfaces, proxy_interfaces, virtual_alias_domains, or
> > virtual_mailbox_domains,
>
> The docs are correct.
>
> > but I assume Postfix will read the
> > relay_recipient_maps to verify the recipient...?
>
> reject_unauth_destination is only concerned with the domain
> name, not the user name.  There are other controls for the
> recipient name.
>
> > I'm still getting entries
> > in the log file that said email was rejected due to "Helo command
> rejected",
> > even when the recipient email address is not listed in
> relay_recipient_maps.
> >
>
> When "smtpd_reject_unlisted_recipient = yes" (the default),
> postfix performs the recipient validation at the end of the
> smtpd_recipient_restrictions list.  If you want to do this
> check earlier, you can specify "reject_unlisted_recipient"
> somewhere in your smtpd_recipient_restrictions list, such as
> just after reject_unauth_destination.
> http://www.postfix.org/postconf.5.html#reject_unlisted_recipient

Bingo. That seems to be the option I was missing. Thanks!

Justin Pasher

Reply | Threaded
Open this post in threaded view
|

RE: Order of parameters for smtpd_recipient_restrictions

Justin Pasher
In reply to this post by mouss-2
> -----Original Message-----
> From: [hidden email] [mailto:owner-postfix-
> [hidden email]] On Behalf Of mouss
> Sent: Friday, June 27, 2008 5:42 PM
> Cc: [hidden email]
> Subject: Re: Order of parameters for smtpd_recipient_restrictions
>
> Justin Pasher wrote:
...

> > smtpd_recipient_restrictions = permit_mynetworks,
> >   permit_sasl_authenticated,
> >   reject_unauth_destination,
> >   reject_non_fqdn_sender,
> >   reject_non_fqdn_recipient,
> >
>
> you can put
>     reject_unlisted_recipient
>     reject_unlisted_sender
> if you want to reject mail to invalid users before doing other checks.
>
> >   reject_unknown_sender_domain,
> >

Noel said the same thing and that seems to be the trick. Thanks.

> put this (reject_unknown_sender_domain) after other checks. it incurs a
> DNS query to a possibly forged domain.
>
> >   reject_unknown_reverse_client_hostname,
> >
>
> you can add
>     reject_invalid_helo_hostname
> here. check the docs for what it does.

I've added the check, since I've also read elsewhere in the list about using
this option before reject_non_fqdn_helo_hostname. What would be an example
of "bad syntax" in the HELO/EHLO command?

> >   reject_non_fqdn_helo_hostname,
> >   reject_rbl_client bl.spamcop.net,
> >   reject_rbl_client xbl.spamhaus.org,
> >   reject_rbl_client sbl.spamhaus.org,
> >
>
> you are doing two queries to spamhaus. consider using zen.spamhaus.org
> instead. then put it before spamcop.

Noel said the same, and I can probably switch to zen now that everything is
under smtpd_recipient_restrictions.

> > /etc/postfix/check_sender_access
> > --------------------
> > # used as a poor man's "block this sender" list
> > [hidden email]   REJECT Blocked
> > [hidden email]   REJECT Blocked
> >
>
> such sender blacklists require work and are not very effective as
> spammers forge random addresses (well, if you want to block
> @badmarkteers.example, it may be ok...). better block based on the client.

This file actually just has three addresses in it right now (and the people
using the email addresses would not have any idea how to forge these). It's
not designed to be 100% accurate, just to reduce annoyance from them.

> > /etc/postfix/transport_maps
> > --------------------
> > .relay2-example.com        smtp:
> >
>
> why do you do this. the default (relay:) is better. if you need to
> specify the destination host, use
> .relay2.example            relay:[192.0.2.3]
> otherwise, use DNS (MX) for the transport. you can use a private DNS
> zone if you know whow to setup this (you can use either BIND views or
> "split horizon").

Honestly, when I was originally configuring this server to relay mail, I
played around with some different setups before I got it working (it's
basically just filtering server for our Exchange server, since it's much
easier to control filtering on the Linux side). It could just be coincidence
that I added this along with some other config option that ultimately made
it work. I'll have to go read up on the differences between how Postfix
handles smtp: and relay:

> > /etc/postfix/relay_recipient_maps
> > --------------------
> > [hidden email] OK
> > [hidden email] OK
> > [hidden email] OK
> >
> > postconf -n
> > --------------------
> > alias_database = hash:/etc/aliases
> > alias_maps = hash:/etc/aliases
> > append_dot_mydomain = no
> > biff = no
> > bounce_queue_lifetime = 1d
> > config_directory = /etc/postfix
> > content_filter = smtp-amavis:[127.0.0.1]:10024
> > mailbox_command = procmail -a "$EXTENSION"
> > mailbox_size_limit = 0
> > maximal_backoff_time = 2h
> > maximal_queue_lifetime = 3d
> > minimal_backoff_time = 30m
> > mydestination = $myhostname, localhost.$mydomain, localhost,
> nmgsupport.com
> > mydomain = newmediagateway.com
> > mynetworks = 127.0.0.0/8 10.205.152.0/21
> > myorigin = $myhostname
> > parent_domain_matches_subdomains =
> >
> debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qm
> qp
> > d_authorized_clients,smtpd_access_maps
> > queue_run_delay = 15m
> > receive_override_options = no_address_mappings
> >
>
> this is risky. better put no_address_mappings in master.cf for those
> services that use it. otherwise, unfiltered mail will not be subject to
> rewrite...

I had this set simply verbatim from the HOWTO on workaround.org
(http://workaround.org/articles/ispmail-etch/). As I understand it, all mail
gets filtered through AMaViS because of the content_filter setting...? Maybe
you're referring to another type of filtering done by Postfix?

> > recipient_delimiter = +
> > relay_domains = $mydestination, sub.relay1-example.com, relay1-
> example.com,
> > relay2-example.com
> >
>
> remove mydestination from relay_domains.

This was another thing I was confused about. I've seen messages on the list
saying that $mydestination should not be listed in both relay_domains and
... some other directive, but it's actually the Postfix default for
relay_domains?

[justinp@host ~]$ postconf -d|grep relay_domains
relay_domains = $mydestination

> > relay_recipient_maps = hash:/etc/postfix/relay_recipient_maps
> > relay_transport = smtp:[10.205.154.91]
> >
>
> what's this for?

All (valid) incoming email on this server is bound for 10.205.154.91, so I
set it up to always use 10.205.154.91 for relaying. Perhaps it's redundant
with the settings I put for transport_maps?

Thanks for the tips.

Justin Pasher

> > relayhost =
> > smtp_host_lookup = native
> > smtpd_banner = $myhostname ESMTP $mail_name (GNU/Linux)
> > smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated,
> > reject_unauth_destination,
> > reject_non_fqdn_sender,
> > reject_non_fqdn_recipient,
> > reject_unknown_sender_domain,
> > reject_unknown_reverse_client_hostname,
> > reject_non_fqdn_helo_hostname,
> > reject_rbl_client bl.spamcop.net,
> > reject_rbl_client xbl.spamhaus.org,
> > reject_rbl_client sbl.spamhaus.org,
> > check_sender_access hash:/etc/postfix/check_sender_access
> > soft_bounce = yes
> > transport_maps = hash:/etc/postfix/transport_maps

Reply | Threaded
Open this post in threaded view
|

Re: Order of parameters for smtpd_recipient_restrictions

mouss-2
Justin Pasher wrote:

>> -----Original Message-----
>> From: [hidden email] [mailto:owner-postfix-
>> [hidden email]] On Behalf Of mouss
>> Sent: Friday, June 27, 2008 5:42 PM
>> Cc: [hidden email]
>> Subject: Re: Order of parameters for smtpd_recipient_restrictions
>>
>> Justin Pasher wrote:
>>    
> ...
>  
> [snip]
>> you can add
>>     reject_invalid_helo_hostname
>> here. check the docs for what it does.
>>    
>
> I've added the check, since I've also read elsewhere in the list about using
> this option before reject_non_fqdn_helo_hostname. What would be an example
> of "bad syntax" in the HELO/EHLO command?
>  

EHLO café
EHLO $helo
...

junk chars will appear as '?' in the logs.

> [snip]
>> such sender blacklists require work and are not very effective as
>> spammers forge random addresses (well, if you want to block
>> @badmarkteers.example, it may be ok...). better block based on the client.
>>    
>
> This file actually just has three addresses in it right now (and the people
> using the email addresses would not have any idea how to forge these). It's
> not designed to be 100% accurate, just to reduce annoyance from them.
>  

ah, ok.

> [snip]
>>> receive_override_options = no_address_mappings
>>>
>>>      
>> this is risky. better put no_address_mappings in master.cf for those
>> services that use it. otherwise, unfiltered mail will not be subject to
>> rewrite...
>>    
>
> I had this set simply verbatim from the HOWTO on workaround.org
> (http://workaround.org/articles/ispmail-etch/). As I understand it, all mail
> gets filtered through AMaViS because of the content_filter setting...? Maybe
> you're referring to another type of filtering done by Postfix?
>  

the setting is ok if all mail is filtered. but we've seen people asking
why their aliases are not expanded, and it was because they excluded
some mail from filtering, or temporarily disabled the filter for some
reason. if you keep this in mind, there should be no problem.

>  
>>> recipient_delimiter = +
>>> relay_domains = $mydestination, sub.relay1-example.com, relay1-
>>>      
>> example.com,
>>    
>>> relay2-example.com
>>>
>>>      
>> remove mydestination from relay_domains.
>>    
>
> This was another thing I was confused about. I've seen messages on the list
> saying that $mydestination should not be listed in both relay_domains and
> ... some other directive, but it's actually the Postfix default for
> relay_domains?
>  


that's a compatibility setting. if you want to accept mail for all
subdomains of your domains, then the default setting will allow that
(this works with the default setting of parent_domain_matches_subdomains).

note that it is now recommended to set
parent_domain_matches_subdomains =
(empty value) if you don't need its functionality.

> [justinp@host ~]$ postconf -d|grep relay_domains
> relay_domains = $mydestination
>
>  
>>> relay_recipient_maps = hash:/etc/postfix/relay_recipient_maps
>>> relay_transport = smtp:[10.205.154.91]
>>>
>>>      
>> what's this for?
>>    
>
> All (valid) incoming email on this server is bound for 10.205.154.91, so I
> set it up to always use 10.205.154.91 for relaying. Perhaps it's redundant
> with the settings I put for transport_maps?
>
>  

transport_maps are a cleaner way to do this.
Reply | Threaded
Open this post in threaded view
|

RE: Order of parameters for smtpd_recipient_restrictions

Justin Pasher
> -----Original Message-----
> From: [hidden email] [mailto:owner-postfix-
> [hidden email]] On Behalf Of mouss
> Sent: Saturday, June 28, 2008 3:59 AM
> Cc: [hidden email]
> Subject: Re: Order of parameters for smtpd_recipient_restrictions
>
> Justin Pasher wrote:
...

> >>> recipient_delimiter = +
> >>> relay_domains = $mydestination, sub.relay1-example.com, relay1-
> >>>
> >> example.com,
> >>
> >>> relay2-example.com
> >>>
> >>>
> >> remove mydestination from relay_domains.
> >>
> >
> > This was another thing I was confused about. I've seen messages on the
> list
> > saying that $mydestination should not be listed in both relay_domains
> and
> > ... some other directive, but it's actually the Postfix default for
> > relay_domains?

I've removed $mydestination and things still seem to be delivering properly.

> >>> relay_recipient_maps = hash:/etc/postfix/relay_recipient_maps
> >>> relay_transport = smtp:[10.205.154.91]
> >>>
> >>>
> >> what's this for?
> >>
> >
> > All (valid) incoming email on this server is bound for 10.205.154.91, so
> I
> > set it up to always use 10.205.154.91 for relaying. Perhaps it's
> redundant
> > with the settings I put for transport_maps?
> >
> >
>
> transport_maps are a cleaner way to do this.

I tried removing the relay_transport directive and now I remember why I set
it (it was because it was the only way I could figure out how to get it
working). Luckily my setup only relays mail to 10.205.154.91, so it didn't
cause a problem.

Here's the scenario that breaks when I remove relay_transport. I probably
made the mistake of previously removing lines from transport_maps that I
thought were not important. :(

This postfix filtering server: server1.relay1-example.com

/etc/postfix/transport_maps
--------------------
server1.relay1-example.com   local:
.relay1-example.com          smtp:

/etc/aliases
--------------------
root:    [hidden email]

Send email to [hidden email]. It will be delivered through
the local: transport. It is then mapped over to [hidden email],
according to the aliases file. I then get a warning in the logs about a mail
loop.

Jun 28 11:53:39 nmgapps postfix/smtp[15689]: 4571B70809D:
to=<[hidden email]>, orig_to=<[hidden email]>,
relay=none, delay=0.01, delays=0/0.01/0/0, dsn=4.4.6, status=SOFTBOUNCE
(mail for relay1-example.com loops back to myself)

Basically, server1.relay1-example.com relays all mail for relay1-example.com
and relay2-example.com. This server's name is on the same domain name as the
relay domain (relay1-example.com). Could this possibly be related to the
gotcha you previously mentioned (receive_override_options =
no_address_mappings)?

I also tried changing the line in transport_maps to read the following (with
no luck)

.relay1-example.com   relay:[10.205.154.91]

I added the relay_transport directive to push everything through
relay1-example.com (10.205.154.91), since this is the only server for which
we relay mail, and the looping problem went away. That's why I decided to
just leave it that way when I originally set it up.

Justin Pasher

Reply | Threaded
Open this post in threaded view
|

Re: Order of parameters for smtpd_recipient_restrictions

mouss-2
Justin Pasher wrote:

> [snip]
>
> I tried removing the relay_transport directive and now I remember why I set
> it (it was because it was the only way I could figure out how to get it
> working). Luckily my setup only relays mail to 10.205.154.91, so it didn't
> cause a problem.
>
> Here's the scenario that breaks when I remove relay_transport. I probably
> made the mistake of previously removing lines from transport_maps that I
> thought were not important. :(
>
> This postfix filtering server: server1.relay1-example.com
>
> /etc/postfix/transport_maps
> --------------------
> server1.relay1-example.com   local:
> .relay1-example.com          smtp:
>
> /etc/aliases
> --------------------
> root:    [hidden email]
>
> Send email to [hidden email]. It will be delivered through
> the local: transport. It is then mapped over to [hidden email],
> according to the aliases file. I then get a warning in the logs about a mail
> loop.
>
> Jun 28 11:53:39 nmgapps postfix/smtp[15689]: 4571B70809D:
> to=<[hidden email]>, orig_to=<[hidden email]>,
> relay=none, delay=0.01, delays=0/0.01/0/0, dsn=4.4.6, status=SOFTBOUNCE
> (mail for relay1-example.com loops back to myself)
>  

you have no transport for relay1-example.com but your postfix is an MX
for this domain. you need to add a transport for this domain. see below.

> Basically, server1.relay1-example.com relays all mail for relay1-example.com
> and relay2-example.com. This server's name is on the same domain name as the
> relay domain (relay1-example.com). Could this possibly be related to the
> gotcha you previously mentioned (receive_override_options =
> no_address_mappings)?
>
> I also tried changing the line in transport_maps to read the following (with
> no luck)
>
> .relay1-example.com   relay:[10.205.154.91]
>
>  

This matches subdomains, but not the domain itself:

add the entry for the domain as well:

relay1-example.com   relay:[10.205.154.91]




> I added the relay_transport directive to push everything through
> relay1-example.com (10.205.154.91), since this is the only server for which
> we relay mail, and the looping problem went away. That's why I decided to
> just leave it that way when I originally set it up.
>
> Justin Pasher
>
>  

Reply | Threaded
Open this post in threaded view
|

RE: Order of parameters for smtpd_recipient_restrictions

Justin Pasher
> -----Original Message-----
> From: [hidden email] [mailto:owner-postfix-
> [hidden email]] On Behalf Of mouss
> Sent: Sunday, June 29, 2008 6:30 AM
> Cc: [hidden email]
> Subject: Re: Order of parameters for smtpd_recipient_restrictions
>
> Justin Pasher wrote:
> > [snip]
> >
> > I tried removing the relay_transport directive and now I remember why I
> set
> > it (it was because it was the only way I could figure out how to get it
> > working). Luckily my setup only relays mail to 10.205.154.91, so it
> didn't
> > cause a problem.
> >
> > Here's the scenario that breaks when I remove relay_transport. I
> probably
> > made the mistake of previously removing lines from transport_maps that I
> > thought were not important. :(
> >
> > This postfix filtering server: server1.relay1-example.com
> >
> > /etc/postfix/transport_maps
> > --------------------
> > server1.relay1-example.com   local:
> > .relay1-example.com          smtp:
> >
> > /etc/aliases
> > --------------------
> > root:    [hidden email]
> >
> > Send email to [hidden email]. It will be delivered
> through
> > the local: transport. It is then mapped over to admin@relay1-
> example.com,
> > according to the aliases file. I then get a warning in the logs about a
> mail
> > loop.
> >
> > Jun 28 11:53:39 nmgapps postfix/smtp[15689]: 4571B70809D:
> > to=<[hidden email]>, orig_to=<root@server1.relay1-
> example.com>,
> > relay=none, delay=0.01, delays=0/0.01/0/0, dsn=4.4.6, status=SOFTBOUNCE
> > (mail for relay1-example.com loops back to myself)
> >
>
> you have no transport for relay1-example.com but your postfix is an MX
> for this domain. you need to add a transport for this domain. see below.
> > Basically, server1.relay1-example.com relays all mail for relay1-
> example.com
> > and relay2-example.com. This server's name is on the same domain name as
> the
> > relay domain (relay1-example.com). Could this possibly be related to the
> > gotcha you previously mentioned (receive_override_options =
> > no_address_mappings)?
> >
> > I also tried changing the line in transport_maps to read the following
> (with
> > no luck)
> >
> > .relay1-example.com   relay:[10.205.154.91]
> >
> >
>
> This matches subdomains, but not the domain itself:
>
> add the entry for the domain as well:
>
> relay1-example.com   relay:[10.205.154.91]

Ahhh... Something so simple. That seems to have fixed the problem. Now I can
remove relay_transport without breaking anything. Thanks!

Justin Pasher