RBL and Whitelist, which one comes first? Legitimate emails getting bounced

[Roy@ENHOST]

Hi guys,

Some of you might have installed a module to query the RBLs whenever an email comes in.
Ive always wondered if the email will be rejected if the sender IP is listed in the RBL lists BUT the email itseld is whitelisted by the recipient.
By right, the whitelist should come first before the RBL but I have the impression that what happens is the other way round.

Let me hear your take on this.

 

[lloyd_tennison]

Depends on how your RBL's are installed.

# Check sending hosts against DNS black lists.
# Reject message if address listed in blacklist.
deny message = Message rejected because $sender_fullhost \
is blacklisted at $dnslist_domain see $dnslist_text
        !hosts = +relay_hosts
        !authenticated = *
        dnslists = bl.spamcop.net : \
        xbl-sbl.spamhaus.org : \
        list.dsbl.org : \
        combined.njabl.org : \
        relays.ordb.org : \
        badconf.rhsbl.sorbs.net : \
        socks.dnsbl.sorbs.net : \
        nomail.rhsbl.sorbs.net : \
        smtp.dnsbl.sorbs.net : \
        misc.dnsbl.sorbs.net 
        !domains = +rbl_bypass
        !hosts = +rbl_whitelist
#**#
#**# DNSBL List End
#**#

is what I use and I know it works.

(From Rvskin, etc.)

 

[RickG]

Roy: In addition to Lloyd's example, if the RBL ACL is set up correctly, you may need to look at an actual message header to insure the user has whitelisted the correct information.

And while on the subject of "which comes first," I've always wondered if there is a preferred order in which the anti-spam tests should be placed in the ACL, particularly as they relate to the verify recipient (aka user unkown) process.

For example, let's say you are using a combination of:

- HELO/EHLO tests
- RBL Checks
- Reverse Host Lookup
- Sender Verify

We've got things set up so that when a message arrives ...

1) It goes through various HELO/EHLO tests (quick and easy on resources). Rejected if does not pass.
2) If the message passes #1, a recipient check is performed and rejected if user is unkown. Of course Jonathan's Dictionary Attack script is at the very top of the stack.
3) If it passes #2, it is checked against various RBL's
4) If it passes #3, an rDNS check is performed (can lead to some false positives - we have to maintain a whitelist)
5) If the message gets through #4, a sender/callout takes place
6) Finally, the message is accepted and handed off to MailScanner / SpamAssassin.

I've seen some examples where the recipient verification is done further down in the process (i.e. RBL checks take place regardless of whether the mail is addressed to a valid user). Our objective was to cut down on resources and unnecessary queries. But are we better off having a spam source see we are verifying against RBLs and never seeing the user unkown?

Not certain there is a right answer. Anyone have any thoughts on the above? Thx -

 

[chirpy]

There's two ways I'd look at it:

1. Verify first then RBL - you may be giving amunition to the spammer since they will know which address doesn't work and which is being bounced from an RBL and may simply develop a database that way. I doubt they'd bother with this at all, but it leaves the opportunity there

2. Check RBL and then verify. Maintains a consistent approach, i.e. block all spam from anyone on RBL's equally. Downside is that if the account didn't exist anyway (i.e. the verify would fail) you're wasting resources on an RBL lookup

My preference would probably be:

1. Dictionary attack ACL

2. Protocol checks (EHLO,HELO, etc)

3. rDNS check (be careful with this as you mentioned)

4. RBL checks

5. Verify recipient

6. Verify sender/callout

The reason for the Dictionary attack being first is that if you reject emails at this stage, any 4 in a row of _any_ of the checks will prompt it to be put in exim_deny and blocked entirely without the need for subsequent checks for the duration of the block.