white lists

Mark Motley mark@motleynet.com
Sat Apr 20 09:33:36 UTC 2002


Vernon,

I think you've brought this up before, but have you given any additional
thought to allowing more flexible whitelisting especially on 'From'
(e.g. regex or just simple substring match)?

My understanding is the reason this is not possible today is due to the
fact that the DCC client computes a checksum on the 'from' and compares
that to checksums on the whitelist (could be wrong here).  Since 'From'
matching in DCC appears to be somewhat deprecated, I wonder if this
still makes sense.

I'm getting very close to piloting DCC in my enterprise (nothing like a
Blackberry to drive the spam problem home).  I know the whitelisting is
going to become a big headache; it would be nice to have a more flexible
way of doing it so end-users could understand.  If you wanted to avoid
all the overhead with regex matching, I'm sure substring matching would
probably fit the bill.

- MBM

-----Original Message-----
From: Earl Killian [mailto:dcc@lists.killian.com] 
Sent: Friday, April 19, 2002 5:27 PM
To: dcc@rhyolite.com
Subject: white lists

Since folks are having some trouble with DCC whitelists, I thought I
would mention how I avoid them altogether.

My mail setup uses SMTPD to receive mail from port 25.  SMTPD has a
rules file that lets you accept or reject each RCPT TO based on the IP
address, the MAIL FROM, and the RCPT TO values (using pattern matches
for each).  This was getting me 97% spam rejection.  Adding DCC to the
flow brought this up to over 99.7% (a 10x reduction! -- thank you
Vernon).

For those not that might not remember their SMTP dialog, a typical
delivery consists of
  EHLO <sendinghostname>
  MAIL FROM:<returnaddress>
  RCPT TO:<toaddress1>
  RCPT TO:<toaddress2>
  ...
  DATA
  <header>
  <body>
  QUIT
The server responds to each command above with a 3-digit response
code.

My SMTPD rules file has the following structure:

  For each RCPT TO (accept = 2xx reply, reject = 550 reply):
     0 accept local mail
     1 reject relaying
     2 accept by whitelisted IP address
     3 accept by whitelisted MAIL FROM host
     4 accept by whitelisted MAIL FROM user
     5 accept by whitelisted mailing list RCPT TO (I use a different
       killian.com address for each mailing list)
     6 reject spammers by RBLs
     7 reject free email sites
     8 reject spammers by reverse-IP pattern match
     9 reject spammers by MAIL FROM
    10 reject MAIL FROM with no NS record for host portion
    11 reject IP with no reverse IP
    12 accept, set DCC bit

  Now accept DATA (if not every recipient rejected)

    0 if DCC bit set, submit to DCC and reject if DCC thresholds
exceeded
    1 give to sendmail for local delivery

Pros:
* Reject most spam without the message itself being transferred
  (i.e. they don't steal much bandwidth)
* Address whitelisting is more flexible than with DCC (can use fairly
  flexible pattern matching)
Cons:
* Address rejected spam does not have its DCC counter incremented
  (because we didn't allow the message body to be transferred, there's
  nothing on which to compute fuzzy checksums).  (On the other hand,
  if everyone used the same set of RBLs, this wouldn't really matter
  because the spam would be rejected everyone.)
* If any RCPT TO calls for DCC, all get it (in practice the RCPT TO
  value in the patterns is almost always "ANY", so this doesn't much
  matter).  The only problem is if someone sends a mailing list
  post to both a user and a mailing list, it might get DCC'd.
* Step #11 rejects a lot of legitimate mail (and even more spam).  Now
  that I have DCC, I should try eliminating this step and see if DCC
  does the job.

-Earl
_______________________________________________
DCC mailing list
DCC@rhyolite.com
http://www.rhyolite.com/mailman/listinfo/dcc




More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.