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