[RndTbl] spam filtering based on invalid DNS - local example

[Dan Keizer]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.muug.mb.ca/pipermail/roundtable/attachments/20121011/b5122d1f/attachment-0001.html>