OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: multirecipient mail and adding headers

From: Noel Jones (njonesmegan.vbhcs.org)
Date: Fri Jun 01 2007 - 17:25:02 CDT


At 04:13 PM 6/1/2007, Kenny Dail wrote:
>Ok so we are trying some different things to block mail with post fix.
>Trouble is that multirecipient mail is being check many times, and in
>cases where a header is added, the header is being added multiple times.

It should be no surprise that smtpd_recipient_restrictions is
processed once for each recipient. If there is a rule here that adds
a header, one header will be added each pass.

>Is there a cleaner way to do this?

You can put the rule that adds headers under smtpd_data_restrictions,
which only runs once after all the recipients have been accepted but
before the actual message has been transmitted.
Note that if there are multiple recipients for a message, the
recipient names are not available in the context of
smtpd_data_restrictions. This could cause unexpected behavior in a
policy service or a check_recipient_access map that depends on having
the recipient name available.

>postconf -n
>hash_queue_names = deferred, defer active bounce flush incoming

The default for this is now "deferred, defer". This should be
appropriate for the vast majority of systems unless you commonly have
thousands of messages in the {active, bounce, flush, incoming} queues.
http://www.postfix.org/postconf.5.html#hash_queue_names

>local_recipient_maps =
>mydestination = $myhostname
>mydomain = amigo.net
>relay_domains = re-2.org slvdweller.com trappermine.com
>relay_recipient_maps =

It appears that you accept mail for invalid recipients for both
$myhostname and your relay_domains. You are strongly encouraged to
have working recipient validation to reduce the load on your system
and reduce the amount of backscatter you produce.
http://www.postfix.org/LOCAL_RECIPIENT_README.html
http://www.postfix.org/postconf.5.html#relay_recipient_maps

>smtpd_helo_restrictions = permit_sasl_authenticated,
>permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_hostname
>smtpd_recipient_restrictions = permit_sasl_authenticated,
>permit_mynetworks, reject_unknown_recipient_domain,
>reject_unauth_destination, reject_unlisted_recipient,
>check_recipient_access mysql:/etc/postfix/mysql-no-filter-header.cf,
>check_recipient_access mysql:/etc/postfix/mysql-no-filter.cf,
>check_client_access cidr:/etc/postfix/dnswl/postfix-dnswl-header,
>check_client_access cidr:/etc/postfix/dnswl/postfix-dnswl-permit,
>check_policy_service inet:127.0.0.1:10031, check_policy_service
>inet:127.0.0.1:12525, permit_mx_backup, permit

reject_unknown_recipient_domain is unlikely to do anything here other
than reject your own domain if your DNS hiccups. Best to remove it
from this list.
permit_mx_backup isn't doing any good where it is, best to remove it
("permit_mx_backup, permit" is an expensive no-op). The final
"permit" is implied and unnecessary, but doesn't hurt anything. List
domains for which you provide backup MX service in relay_domains,
list their valid recipients in relay_recipient_maps or use selective
reject_unverified_recipient for those domains if you can't get a user list.

--
Noel Jones