We upgraded recently from 2.3.3 (RHEL5 stock Postfix)  to 2.6.6 (RHEL6
stock Postfix). The settings, including $smtpd_sender_restrictions,
$smtpd_recipient_restrictions, and the ldap lookup maps (as well as the
backend LDAP servers) are the same.

The new systems are faster hardware, and faster disks, however, I notice
a very slight delay (maybe 1s) on the newer system after RCPT TO (it's
perceptible visually if you telnet to port 25 and send a message).
There's a local instance of unbound and rbldnsd, though I don't think
DNS lookups are the issue, since the sending hosts are both in
$mynetworks and explicitly whitelisted (they're also exempted from
rate-limiting).

We have a Java process that sends mail serially (one connection per
message, one after the other), which used to be able to send about 5-7
messages in 1 second; after the cutover to the new system, it's more
like 1 message per second. Overall, the new system seems to perform
well, and obviously, the "right" fix is for them to increase concurrency
and send more messages per connection.

That said, is there a general change in Postfix (intentional, to deter
spammers, a configurable knob I'm missing, or just due to doing things
in a more comprehensive way), that accounts for this? If I turn on
debugging for smtp connections from that host (in $debug_peer_list), or
make smtpd more verbose, will I see any information about how long
individual lookups are taking?

There are a lot of LDAP lookups involved, and I'll look at profiling
those and seeing if indices need to be added on any fields, but the same
configuration was snappier with the older version with the same backend
hosts.

Note: the sending system in question is in a CIDR range listed in
/etc/postfix/white_list_internal_servers, though doesn't seem to make a
difference one way or another.

local_recipient_maps            =
                                  proxy:ldap:acct_ldap,
                                  $alias_maps,
                                  unix:passwd.byname

alias_maps                      =
                                  proxy:ldap:acct_forw_ldap
                                  proxy:ldap:acct_alias_ldap,
                                  proxy:ldap:other_alias_ldap,
                                  hash:/etc/postfix/aliases

smtpd_sender_restrictions =
   check_sender_access regexp:/etc/postfix/sender_redirect,
   check_sender_access regexp:/etc/postfix/no_valid_sender,
   check_sender_access hash:/etc/postfix/auto_generated_files/sender_blocks,
   permit_sasl_authenticated,
   permit_mynetworks,
   check_sender_access hash:/etc/postfix/allow_from_inside_networks_only,
   check_client_access cidr:/etc/postfix/white_list,
   reject_unknown_sender_domain,
   reject_non_fqdn_sender

smtpd_recipient_restrictions =
   check_recipient_access regexp:/etc/postfix/no_sender_rte,
   check_recipient_access hash:/etc/postfix/auto_generated_files/rcpt_blocks,
   check_recipient_access hash:/etc/postfix/hold-users,
   permit_sasl_authenticated,
   check_client_access cidr:/etc/postfix/white_list_internal_servers,
   reject_unknown_recipient_domain,
   reject_non_fqdn_recipient,
   permit_mynetworks,
   reject_unauth_destination,
   check_client_access cidr:/etc/postfix/white_list,
   check_recipient_access ldap:acct_class_ldap,
   reject_non_fqdn_sender,
   reject_invalid_helo_hostname,
   reject_non_fqdn_helo_hostname,
   reject_rbl_client zen.spamhaus.org,
   reject_rhsbl_client dbl.spamhaus.org,
   reject_rhsbl_sender dbl.spamhaus.org

Reply via email to