Am 12.02.2015 um 01:03 schrieb Shawn Heisey:
On 2/11/2015 3:24 PM, li...@rhsoft.net wrote:
just don't enable deep protocol tests if you don't want 450 rejects and
rob0's example is nice but don't blindly follow howtos without real
understanding
http://www.postfix.org/POSTSCREEN_README.html
http://www.postfix.org/POSTSCREEN_README.html#after_220
I did look at that README, but apparently I did not fully grasp what I
was reading. Thanks for the prod in the right direction.
Is there any way to enable some logging so that I can definitively tell
which part of the postscreen config is responsible for a rejection,
without enabling extremely verbose logging?
no, but there are only two reasons for a 450 reject in postscreen
* a enabled deep protocol test
* postscreen_whitelist_interfaces = !<honeypot-backup-mx-ip>, static:all
On my re-read of the README, if I'm understanding it right, the options
I have chosen will result in an automatic reject of all connections from
a new source. When they retry, they will be allowed through, if they
passed the tests and the reconnect is within the time limit.
To test this theory, I deleted the postscreen_cache.db file, restarted,
and tried a new message. The first attempt was rejected with the 450,
but when I flushed the queue on the sender immediately without
restarting postfix on the receiver, the message cleared postscreen
successfully. This is a little bit like a greylist.
it is in fact and it may lead to all the troubles of greylisting for
mails from large senders spread temporary undeliverable mail to
different nodes and so never reach the whitelisting
hence the idea of the "postscreen_whitelist_interfaces" is way better
because it mainly affects bots trying the backup-mx first and never come
back and don't harm senders re-try on the primary MX
I'm planning to increase postscreen_dnsbl_ttl to 4 hours. Does this set
off any red flags for anyone?
depends on your spam-flow
i would consider it way too long because it caches also NXDOMAIN results
of spambots not in enough blacklists now but make it there within the
TTL timeframe
