On 1/21/2011 10:39 AM, Jerrale G wrote:
With 2.7 and prior, we would use -o content_filter under the
first transport to check for viruses and then pipe to
spamassassin:
# line 5 of master.cf
#smtp inet n - n - - smtpd
# -o content_filter=scan:[127.0.0.1]:10025
# -o smtpd_authorized_xforward_hosts=127.0.0.0/8

With the new postscreen, it was ignoring this first transport
now and we only got spamassassin and clamav to work again
after changing:

# line 28 of master.cf
smtpd pass - - n - - smtpd
-o content_filter=scan:[127.0.0.1]:10025
-o smtpd_authorized_xforward_hosts=127.0.0.0/8

Is this the correct transport to put this under?

Yes.

What
transports from 2.7 should NOT be in master.cf for 2.8, as we
still have all the old ones and the new ones that "make
upgrade" added?

What does RELEASE_NOTES say about removing entries from master.cf?




We also took all of the smtpd_*_restrictions that contained
reject_*_client and reject_*_sender and put correctly, on the
first try, them under postscreen_dnsbl_sites:

Postscreen doesn't do any sender checks. All RBL lookups are on the client IP only. Sender checks and client hostname checks (rhsbl/rhswl) must still be in smtpd_*_restrictions.



postscreen_dnsbl_ttl=1d

1 day is a little long for caching RBL lookups. The default 1h is probably better.


postscreen_access_list=permit_mynetworks,
cidr:/etc/postfix/ps_override

## we disabled tls/ssl ONLY in postscreen for the first
connect attempt, due to the current tls attack Wietse was
talking about on postfix.org
## so that clients would only be offered TLS on the SECOND,
bare_newline_connection attempt. I think this is the best work
around for now for
## these attacks while allowing TLS to still be offered,
right? The idea is they are refused TLS on the first "new"
connection attempt so that scanners
## scanning for TLS mail servers will think we dont offer it.
postscreen_use_tls=no

OK. postscreen won't offer STARTTLS to new clients, but "known" PASS OLD or whitelisted clients use the smtpd_*tls settings.

It's unclear if this is generally useful.


postscreen_dnsbl_action=enforce
postscreen_dnsbl_sites = dnsbl.sorbs.net=127.0.0.[2..12],
dnsbl.dronebl.org=127.0.0.[1..30],
bl.spamcop.net,
cbl.abuseat.org,
zombie.dnsbl.sorbs.net,
sbl.spamhaus.org,
b.barracuracentral.org,
zen.spamhaus.org,
postmaster.rfc-ignorant.org=127.0.0.[3;4],
abuse.rfc-ignorant.org=127.0.0.[3;4],
bl.nszones.com,
bogusmx.rfc-ignorant.org

Goodness that's a lot of RBLs! You should carefully review what you're using there. A couple problems jump out at me: cbl.abuseat.org and sbl.spamhaus.org are included in zen, and the rfc-ignorant lists are generally inappropriate for direct blocking. I'm not familiar with several of the others you're using; make sure they are active and that their listing criteria is compatible with your goals.


postscreen_cache_cleanup_interval=24h
postscreen_cache_retention_time=2d

Do you have a purpose in changing these, or do you just like to twiddle knobs? The defaults are carefully chosen and should be appropriate for the majority of sites.




  -- Noel Jones

Reply via email to