On 4-Apr-2009, at 16:02, Noel Jones wrote:
Best in smtpd_data_restrictions so you don't reject sourceforge and
others sender verification probes.
Is there anything I need to be concerned about having/not having in
smtpd_data_restrictions? it is currently commented out. if I simply
put:
smtpd_data_restrictions =
reject_unauth_pipelining,
reject_rbl_client ips.backscatterer.org,
reject_rbl_client bl.spamcannibal.org
permit
is that good enough? (the pipelining was there before in the
commented out declaration along with the permit). I am sad to say I am
still a little unclear about how the various smtpd_mumble_restrictions
work together.
IP you've provided as source of backscatter is listed in
backscatterer.org.
Moreover, SPF won't help you much, because other mailserver admins
would have to check it, and it's rarely supported.
True. It "seems" that sites with SPF are less frequently chosen as
joe-job victims, but there's no guarantee. At any rate, adding SPF
shouldn't hurt anything.
Well, I am hoping spf helps a bit. I'd left off the ~all on some
domain's configuration and I've noticed a lot os this backscatter has
Received-SPF: neutral (mail9.webair.com: 85.9.127.134 is neither
permitted nor denied by SPF record at kreme.com)
Other suggestions...
Add the header_checks suggested in
http://www.postfix.org/BACKSCATTER_README.html
Note the examples will need to be "customized" for your site.
Oh, those look like a good idea in general, backscatter or not. At
least in the header_checks. I am leery of running body_checks as it
seems those would be expensive.
If you're using SpamAssassin, the VBOUNCE rules are helpful.
Yeah, but SA is run after reception. I'd rather reject backscatter
than discard it, if possible.
Thanks, this is great info.
--
I'll trade you 223 Wesley Crushers for your Captain Picard
