Could Be OT: How many people only accept reverse DNS lookupmail?

[Jim Holland]

On Sat, 26 Aug 2006, Julian Field wrote:

> Kevin Miller wrote:
> > Michael Baird wrote:
> > 
> >> I've been testing http://smfs.sourceforge.net/smf-sav.html this milter
> >> as well, on a lower pref MX (Spam Catcher). It goes further then just
> >> checking reverse DNS, it also checks whether the domain actually
> >> accepts mail, and if it accepts mail for the specified sender.
> > 
> > Just installed this on a test server and a third level mx gateway (that
> > gets maybe a half dozen non spam emails on a good day!)
> > 
> > Have one question though - how do these sorts of milters deal with
> > mailing lists?  An awful lot of them seem to send from no-reply
> > addresses.  Do list senders typically create a valid account and just
> > quietly drop any mail back, or what?  I can see the sender check
> > dropping a lot of valid email from lists so am a bit leary about it.  Am
> > I losing sleep over nothing?
> 
> On a slightly related question, I built this on a client's machine the 
> other day, but could not remotely see how to configure it. The docs are 
> next to useless from what I could find.
> 
> Hints?

See my rough notes below for a Debian installation, written in hindsight
after much trial and error.  I use it just for filtering my personal mail
after it has been through the main MANGO system.  So far it has stopped a
few spammers that got through MailScanner (which is not currently using
SpamAssassin etc yet due to lack of processing power), but the traffic is
not large enough to draw many conclusions there.

I have also installed it on a very old Red Hat 6.1 nameserver for which
the incoming mail should only have been correspondence about domain
registrations, but in the end the ratio of spam to genuine but very
important mail was well over 100:1.  This utility alone immediately
blocked 80% of the spam, with no false positives at all.  (Initially it
would not compile - as it was never intended for such an old OS as 6.1 -
but the very helpful developer (Eugene Kurmanin <me at kurmanin.info>) very
kindly held my hand on line and with a combination of hacking of the
source code and finding some old bind include files we got it working).

I haven't tested the Recipient e-Mail Address Verification yet.

The code is still at an early stage of development, but I am very
impressed.  The nameserver where I installed it was simply forwarding mail
to a handful of accounts at other ISPs, so relied on their own spam and
virus filtering.  However one of them started to institute sender
verification itself (very simple if you are using Exim, but not if you are
using sendmail and can't afford a commercial milter).  The result was huge
numbers of undeliverable and unbounceable spam messages in the mail queue.  
That has now stopped almost completely.

I would not recommend it for a production mail server at the moment,
simply because it has no facility for whitelisting.  However the developer
says that whitelisting with a cache will be incorporated in the next
version to be issued in a week or so.  As the previous correspondent 
indicated, it will be important to be able to whitelist mailing lists etc.

Clearly the more obvious junk that can be stopped by the MTA the better,
leaving MailScanner etc with more processing power to fine filter the 
remainder.

Regards

Jim Holland
System Administrator
MANGO - Zimbabwe's non-profit e-mail service


First updated to latest sendmail

Installed package libmilter-dev, which also installed libmilter0


Downloaded smf-sav-1.2.0 from:

http://prdownloads.sourceforge.net/smfs/smf-sav-1.2.0.tar.gz?use_mirror=kent

Unpacked smf-sav-1.2.0.tar.gz in /usr/src/smf-sav-1.2.0

Made following changes to Makefile:

< DATADIR = /var/run/smfs
< CONFDIR = /etc/smfs
---
> DATADIR = /var/smfs
> CONFDIR = /usr/local/etc/smfs

Ran make, then make install

Created directory /usr/local/etc/smfs

Created the following link:

    ln -s /usr/local/etc/smfs/smf-sav.conf /etc/smfs/smf-sav.conf

(The above two steps seem to be required if you don't use the default 
location /usr/local/etc/smfs - I have reported this as a possible bug)


Edited /etc/smfs/smf-sav.conf:

< # /etc/smfs/smf-sav.conf
---
> # /usr/local/etc/smfs/smf-sav.conf

< Connect       ^127\.
---
> Connect       (^127\.|^192\.168\.|^10\.)

< PublicName    test.mango.zw         # should be corrected carefully
---
> PublicName    yourhost.yourdomain.tld # should be corrected carefully

< SafeCallBack  root at test.mango.zw    # should be corrected carefully
---
> SafeCallBack  postmaster at yourdomain.tld  # should be corrected carefully

< Socket        unix:/var/run/smfs/smf-sav.sock
---
> Socket        unix:/var/smfs/smf-sav.sock


Add this line to /etc/syslog.conf file:

    local2.info     -/var/log/sav.log

If you want to exclude the successfully verified e-mail addresses from
logging, set the syslog priority to notice instead the info.

Run /etc/init.d/sysklogd restart


Edit sendmail.mc file by adding:

    define(`confMILTER_MACROS_HELO', confMILTER_MACROS_HELO`, {verify}')dnl
    INPUT_MAIL_FILTER(`smf-sav', `S=unix:/var/run/smfs/smf-sav.sock, T=S:30s;R:4m')dnl

Regenerate sendmail.cf


Create startup script (there are some examples in the source init 
directory, but I based mine on a standard Debian script):

    Create /etc/init.d/smfsav based on /etc/init.d/ssh
    Runlevels 0, 1, 6:  ln -s /etc/init.d/smfsav K20smfsav
    Runlevels 2-5:      ln -s /etc/init.d/smfsav S20smfsav

It must start before sendmail, stop after it.


Then start up smf-sav and restart sendmail.


Check the log file /var/log/sav.log


Test by sending mail from an invalid address at a third party server.