Prev: Patch: support BURL
Next: Migrating from postfix to Exim
From: Alex on 10 Apr 2010 20:28
Hi,

>> I'm using zen.spamhaus.org in postscreen and,

Where can I find information on postscreen?

>>    reject_rbl_client           bl.spamcop.net
>>    reject_rbl_client           bogons.cymru.com

I would also be interested in info on using the bogons list here. How
does that apply here, considering it's not very effective to spoof the
source of an email that you'd actually like to be delivered in the
first place, no?

> smtpd_recipient_restrictions =
>        ...
>        reject_rbl_client   zen.spamhaus.org
>        reject_rhsbl_client dbl.spamhaus.org
>        reject_rhsbl_sender dbl.spamhaus.org
>        reject_rhsbl_helo   dbl.spamhaus.org

I'm familiar with zen, but I believe the dbl is relatively new,
correct? What other URI BL lists do people use?

Can these postfix restrictions be used with older versions of postfix?
I have a few systems with older versions and can't upgrade right now.

> I reject most spam via other methods, mostly pcre/regex and cidr tables.  My

Can you tell me more about rejecting using cidr tables? Do you mean
the bogon list or ASN numbers? I seem to remember a downloadable list
of the top 10 ASNs that could be used to add weight to an SA score.

> dnsbl queries reject less than 1% of my spam load.  Plug the following
> dynamic/generic rdns regex table into your Postfix configuration and see if

But isn't it really a subset of just downloading a current zen zone
and querying against that?

How do you update it? Manually? That doesn't sound feasible for a
larger network or without having some type of procedure for keeping it
updated surrounding it. What type of network do you have it running
on?

> it catches some spam for you.  It does a good job here.  Given its size I'd
> recommend running it (and all your map files) via proxymap.  Ask here if

Can you include information on proxymap and postfix for me to read?

> This regex file is free for anyone to use if you wish to.  The FP rate
> should be zero since it matches only dynamic/generic rdns names.

I guess that depends on what you consider a FP, right? IOW, I'm not
currently outright rejecting mail from unknown hosts, and it's very
likely that some road-warriors could be sending from their desktops,
and that would impact them here, right?

Lots of questions, so I sure appreciate your help.

Thanks again!
Best regards,
Alex

From: Sahil Tandon on 10 Apr 2010 20:49
On Sat, 10 Apr 2010, Alex wrote:

> >> I'm using zen.spamhaus.org in postscreen and,
>
> Where can I find information on postscreen?

postscreen(8) is part of the 2.8 experimental release:

http://www.postfix.org/postscreen.8.html

--
Sahil Tandon <sahil(a)tandon.net>

From: Noel Jones on 10 Apr 2010 21:16
On 4/10/2010 5:49 PM, Stan Hoeppner wrote:
> I reject most spam via other methods, mostly pcre/regex and cidr tables. My
> dnsbl queries reject less than 1% of my spam load. Plug the following
> dynamic/generic rdns regex table into your Postfix configuration and see if
> it catches some spam for you. It does a good job here. Given its size I'd
> recommend running it (and all your map files) via proxymap. Ask here if
> you're unsure or need help implementing proxymap. It bit me the first time
> I tried it.
>
> smtpd_recipient_restrictions =
> ...
> check_client_access regexp:/etc/postfix/fqrdns.regexp
> ...


You'll probably get more hits using
check_reverse_client_hostname_access. That prevents some
clients from sneaking through as "unknown" when they don't
have a matching A record.

http://www.postfix.org/postconf.5.html#check_reverse_client_hostname_access


-- Noel Jones


>
> /etc/postfix/fqrdns.regexp
> http://www.hardwarefreak.com/fqrdns.regexp
>
> This regex file is free for anyone to use if you wish to. The FP rate
> should be zero since it matches only dynamic/generic rdns names.
>

From: Stan Hoeppner on 10 Apr 2010 22:55
Noel Jones put forth on 4/10/2010 8:16 PM:
> On 4/10/2010 5:49 PM, Stan Hoeppner wrote:
>> smtpd_recipient_restrictions =
>> ...
>> check_client_access regexp:/etc/postfix/fqrdns.regexp
>> ...
>
>
> You'll probably get more hits using
> check_reverse_client_hostname_access. That prevents some clients from
> sneaking through as "unknown" when they don't have a matching A record.
>
> http://www.postfix.org/postconf.5.html#check_reverse_client_hostname_access

I'm still on Debian Stable (Lenny) Postfix 2.5.5. When Squeeze is rolled to
stable and I get Postfix 2.6.5 I'll be changing this, as well as some other
parameters that are only available in 2.6+

--
Stan

From: Stan Hoeppner on 11 Apr 2010 00:16
Alex put forth on 4/10/2010 7:28 PM:

>> smtpd_recipient_restrictions =
>> ...
>> reject_rbl_client zen.spamhaus.org
>> reject_rhsbl_client dbl.spamhaus.org
>> reject_rhsbl_sender dbl.spamhaus.org
>> reject_rhsbl_helo dbl.spamhaus.org
>
> I'm familiar with zen, but I believe the dbl is relatively new,
> correct? What other URI BL lists do people use?

The dbl is somewhat unique in that it's not just a uri domain list. It also
contains domain names that directly send spam. This is how I use the dbl.
It stops a few spam, and every little bit counts.

> Can these postfix restrictions be used with older versions of postfix?
> I have a few systems with older versions and can't upgrade right now.

I'm not sure about all of them. Check yourself here:
http://www.postfix.org/postconf.5.html

>> I reject most spam via other methods, mostly pcre/regex and cidr tables. My
>
> Can you tell me more about rejecting using cidr tables? Do you mean
> the bogon list or ASN numbers? I seem to remember a downloadable list
> of the top 10 ASNs that could be used to add weight to an SA score.

I've built a cidr table over the last couple of years of mostly showshoe
networks that have spammed me. I also use ipdeny.com cidr ranges to block
all smtp connections from certain countries. The combined list is
approximately 12,000 cidr entries from /12s to /24s. In my case these are
implemented as:

cidr=cidr:/etc/postfix/cidr_files
smtpd_recipient_restrictions =
...
check_client_access proxy:${cidr}/spammer
...

>> dnsbl queries reject less than 1% of my spam load. Plug the following
>> dynamic/generic rdns regex table into your Postfix configuration and see if
>
> But isn't it really a subset of just downloading a current zen zone
> and querying against that?

I don't have data feed access to zen, so it would be impossible for me to
answer that question. Considering what the regex looks for, the only likely
overlap would be with the pbl. I've never tested the overlap. Even if the
overlap was 100%, local determination is a better solution for a number of
reasons, including response time and dnsbl query load. In my opinion, it's
better to make an accept/reject determination locally and only query a dnsbl
when a local determination can't be made. dnsbl lookups are the 2nd to the
last test in my config, greylisting being last. My MX MTA makes very few
dnsbl queries.

> How do you update it? Manually? That doesn't sound feasible for a
> larger network or without having some type of procedure for keeping it
> updated surrounding it. What type of network do you have it running
> on?

Most networks don't change their reverse naming conventions once they've
established them. Once the pattern is identified, it doesn't really need
maintenance. If an organization does add or change rdns patterns, the only
downside is you won't catch those, but you still get no FPs.

>> it catches some spam for you. It does a good job here. Given its size I'd
>> recommend running it (and all your map files) via proxymap. Ask here if
>
> Can you include information on proxymap and postfix for me to read?

http://www.postfix.org/postconf.5.html#proxy_read_maps

I'll be nice since this bit me on the first attempt, instead of allowing you
to make the same mistake. When you modify this list by declaring it in
main.cf, you have to include the entire default list, and then add the
additional tables you want to have read via proxymap. Hence this reference
in the documentation: "proxy_read_maps (default: see "postconf -d" output)"
The postconf -d output gives you the default proxymap list. Note that the
ones I added begin with "proxy:". The $(cidr) is merely a reference to a
variable I declared to shorten long lines.

cidr=cidr:/etc/postfix/cidr_files

proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
$sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps
proxy:${cidr}/countries proxy:${cidr}/spammer proxy:${cidr}/misc-spam-srcs
proxy:regexp:/etc/postfix/fqrdns.regexp

smtpd_recipient_restrictions =
...
check_client_access proxy:regexp:/etc/postfix/fqrdns.regexp
check_client_access proxy:${cidr}/countries
check_client_access proxy:${cidr}/spammer
check_client_access proxy:${cidr}/misc-spam-srcs
...

>> This regex file is free for anyone to use if you wish to. The FP rate
>> should be zero since it matches only dynamic/generic rdns names.
>
> I guess that depends on what you consider a FP, right? IOW, I'm not
> currently outright rejecting mail from unknown hosts, and it's very

Is it possible to get an FP from a consumer broadband rdns? Very unlikely.
Depends on your particular MX and those people sending you email. Do you
accept email directly from vanity servers on dynamic IP dsl or cable
connections? If not then your FP rate with this regex is zero.

> likely that some road-warriors could be sending from their desktops,
> and that would impact them here, right?

No, not at all. Your users should already be submitting their email for
delivery via TCP 587, commonly known as the "submission port", NOT to your
MX on TCP 25. Typically one should never implement anti-spam measures such
as those described above on the submission port. User submission requires a
valid username and password, unlike standard SMTP mail, so you don't need
hefty A/S countermeasures on the submission port. MX mail and user
submission mail should always be separated by at least the service port, if
not by physical machine. Implement the hefty A/S on MX TCP 25, not on
submission TCP 587.

If you're doing both types of mail on TCP 25 on your MX, then you need to
change that to the proper configuration ASAP separating user submission to
another port or machine. If this requires your users changing their MUA
configuration, then so be it. It's something that really needs to be done.
You should be beginning to understand at minimum one of the reasons why.
There are many others.

> Lots of questions, so I sure appreciate your help.

Hope I was able help. If anything isn't clear, ask and myself or others
should be able to get you on the right path.

--
Stan

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Patch: support BURL
Next: Migrating from postfix to Exim