Re: [exim] Rejecting direcly connected customers at connect …

Pàgina inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
A: exim users
Assumpte: Re: [exim] Rejecting direcly connected customers at connect time
Andreas Pettersson wrote:
> I'm thinking of rejecting connections from some 'spam problem areas' in
> the connect acl.
> Below are the config I wish to use.
> Does anyone have anything to comment?


Welll.. like my aging corpus 'good in parts'...

You are on to a technique 'of value', and we are about a year further down that
road, so...

> Might I end up with some
> unexpected problems? Are the regexes matching the end users and do their
> ISP's really serve them with mail gateways?
>


You need not worry about that part.

Many senders NOT using the ISP's MTA are zombies. They don't read.

Most of the others are folks believe that if they can tick a box, their machine
can be an MTA. They *won't* read, they'll either cry 'unfair', blame the system,
or both.

'unexpected..'

While your list does have some of the more common offenders, you will need a
list of perhaps 200-500 to stop 60-70% of such misbehaviour, and 600-2,000 to
stop 95%+ of it. Or so we see after 'mining' a year's worth of logs and running
such a list for many months.

As I say often here - your traffic pattern may be very different from some other
mx, ours *especially*.

There may be some further oportunity to seek the 'smell' of dynamic IP in the
prefix, *independent* of the domain.tld. IOW *any* appearacne of 'pool', 'dial',
'dyn', 'res', 'adsl', and so on.

Otherwise, there might be too much resource-load to search an ever-growing list,
OR process too many complex match strings.

We've built our lists from repeat-offenders and RBL hits, so as to 'long-term
cache' (weeks or months).

This dramatically reduces callouts to said RBL's, and has the added benefit of
blocking sources who have been consistently rude to us, but have NOT otherwise
been blacklisted globally. We have had to open whitelist passes for a few
brokerages and banks who really should pay more attention to the world, but
otherwise, no one is complaining.

As only a miniscule fraction of total RBL denizens are likely to ever target any
given MTA, this does at least reduce callouts, and is lower load than enquiring
agaisnt even a full-RBL local copy.

OTOH, before we get this far, we have already dropped arrivals that do not pass
forward/reverse lookup, have no DNS entry at all, so don't have to check every
arrival against these lists. Far from it!

What makes it 'livable', OTOH, is to skip these tests if the arrival is either
'authenticated' on the submission port, or is in a whitelist.

Checking that first (usually fewer than 20 entries), takes care of the customer
who feel they *must* work to/from a correspondent running a 'pirate' MTA.

And where we *may* go next is to whitelist the 'known' MX for the larger ISP's,
then blacklist their entire remaining domain.tld so as to be able to match on,
for example just '*rr.com' w/o the more complex string match also seeing 'cpe-"
or 'res'.

Downside is the larger the ISP, the greater the likelihood they use separate
'outbound' MX, and these critters are often NOT given proper DNS entries, or the
entries are not kept current as servers are rolled in and out of use.

Further filip is that some ISP's list their entire PA netblock(s) against a DNS
entry, such that every single possible DHCP-assigned IP will return a DNS match
or *some* kind.

I'll say it again - what *we* block is based on what abuse *we* have been hit with.

Our patterns, below, may (Hell *will*!) be pure trouble for someone else, so
'grain of salt' here... and please don't jump up and say 'you can't do that..',
when you mean "[ most | other ] folks dare not do that...).

We don't owe zombie farmers, or the ISP's who won't intercept port 25 from thier
back-end networks the time of day.

Ironically, time-of-day is one of the things our 'banner' does give before
disconnect.

;-)

Our 'broad' matches inlined against your list of tests, below.

Caveats as stated, above.

YMMV, YOMD

Bill Hacker
>
> # comcast.net
> deny  condition = ${if match 
> {$sender_host_name}{\N^c-.*\.comcast\.net$\N} {yes}{no} }
>       message   = Use your ISP's mail server to send mail

>


As we (in Hong Kong) have never had even ONE legit message to/from comcast, we
block on *comcast.net

> # rr.com
> deny  condition = ${if match 
> {$sender_host_name}{\N^cpe-.*\.res\.rr\.com$\N} {yes}{no} }
>       message   = Use your ISP's mail server to send mail

>


Ditto. *rr.com

> # verizon.net
> deny  condition = ${if match 
> {$sender_host_name}{\N^pool-.*\.verizon\.net$\N} {yes}{no} }
>       message   = Use your ISP's mail server to send mail

>


Ditto. *verizon.net

> # wanadoo.fr
> deny  condition = ${if match 
> {$sender_host_name}{\N\.abo\.wanadoo\.fr$\N} {yes}{no} }
>       message   = Use your ISP's mail server to send mail


Ditto. *wannadoo.fr (and .nl, and others)

>
> # proxad.net
> deny  condition = ${if match 
> {$sender_host_name}{\N\.(adsl|fbx)\.proxad\.net$\N} {yes}{no} }
>       message   = Use your ISP's mail server to send mail

>
>


Ditto. *proxad.net