Further to our discussion on Tuesday night:
As a wonderful local example, I’ve just discovered that with postfix, enforcing valid HELO hostnames (which really isn’t all that stringent a check!) prevents the Winnipeg Free Press’ website from emailing me. It seems registering on the website causes the registration-confirmation email to be sent from “clickability.com” (aka Limelight’s “Dynamic Site Platform”). OK, fine. They even have reverse DNS set up correctly. But their outbound MX host identified itself as “la-mailout1.clickability.com”. No such A record exists, so postfix immediately rejects the message at the HELO stage.
FWIW, the host connecting to me is “dv-mailout1.clickability.com”, which correctly resolves forward and reverse.
For anyone who’s interested, my Postfix main.cf reads, in part:
smtpd_helo_restrictions =
permit_inet_interfaces,
permit_mynetworks,
permit_sasl_authenticated,
check_helo_access hash:/etc/postfix/client_access,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
reject_unauth_pipelining,
reject_rhsbl_helo zen.spamhaus.org
but adding:
dv-mailout1.clickability.com OK
la-mailout1.clickability.com OK
208.80.58.240 OK
to /etc/postfix/client_access (and remembering to run postmap on it) eventually convinces Postfix to let this message in. (But typically not immediately, which I still don’t understand. Ideas?) Only one of those lines should be necessary, but I’ve never figured out which one :-).
-Adam Thompson
athompso@athompso.net
On 12-10-11 12:57 AM, Adam Thompson wrote:
to /etc/postfix/client_access (and remembering to run postmap on it) eventually convinces Postfix to let this message in. (But typically not immediately, which I still don't understand. Ideas?) Only one of those lines should be necessary, but I've never figured out which one :-).
The following reference provides an explanation: http://www.postfix.org/DATABASE_README.html
Process dependent ... I generally reload and/or restart, depending on what is being changed. :-)
Dan.
------------------------------------------------------------------- snippet below ------------------------------------ Maintaining Postfix lookup table files
When you make changes to a database while the mail system is running, it would be desirable if Postfix avoids reading information while that information is being changed. It would also be nice if you can change a database without having to execute "postfix reload", in order to force Postfix to use the new information. Each time you do "postfix reload" Postfix loses a lot of performance.
If you change a network database such as LDAP, NIS or SQL, there is no need to execute "postfix reload". The LDAP, NIS or SQL server takes care of read/write access conflicts and gives the new data to Postfix once that data is available.
If you change a regexp: or pcre: file then Postfix may or may not pick up the file changes immediately. This is because a Postfix process reads the entire file into memory once and never examines the file again.
If the file is used by a short-running process such as smtpd(8), cleanup(8) or local(8), there is no need to execute "postfix reload" after making a change.
If the file is being used by a long-running process such as trivial-rewrite(8) on a busy server it may be necessary to execute "postfix reload".
If you change a local file based database such as DBM or Berkeley DB, there is no need to execute "postfix reload". Postfix uses file locking to avoid read/write access conflicts, and whenever a Postfix daemon process notices that a file has changed it will terminate before handling the next client request, so that a new process can initialize with the new database.
-
Adam Thompson -
Dan Keizer