[unisog] sendmail spam filtering
stauffacher at chapman.edu
Fri Jun 7 18:55:59 GMT 2002
Nice idea, but it seems to me the overhead would kill some servers.
Right now my mail servers process somewhere on the order of 17k messages
a day, I couldn't see doing a lookup on each one to verify the sender
exists...that would be overkill, now if you could add a config option to
specify certain domains (or top levels ... ".kr" ".cn" come to mind)
that would be cool.
stauffacher at chapman.edu
From: John Callahan [mailto:jcallaha at willamette.edu]
Sent: Friday, June 07, 2002 11:35 AM
To: unisog at sans.org
Subject: [unisog] sendmail spam filtering
I have been toying with a sendmail milter that checks that an envelope
sender address (SMTP
MAIL FROM) actually exists and will receive e-mail before accepting
e-mail for delivery.
It does this by connecting to an MX for the foreign addresses domain and
initiating a SMTP
transaction with the address as the recipient address. It then aborts
the message with a
RSET before any message body is transferred.
What do you folks think of this as a concept?
I was surprised that I didn't seem to find anyone else working on such a
thing or thinking
about it, which makes me think it is either a revolutionary idea or a
very bad one. It sort
of violates SMTP RFCs, but so do things like domain lookups and some
other spam blocking
I have written up a basic description of the idea and the protocol flow
Some of the problems I can think of are:
- some SMTP servers are just broken
- an increase of SMTP traffic (theoretically could double global SMTP
traffic if deployed
- non-compliant SMTP servers that and take some permanent action on
RCPT TO (?)
- legitimate senders with typos in their e-mail client configuration
could be blocked from
- legitimate senders that send from domains that have partial/poor
connectivity to the
Internet might be delayed
I am interested in any feedback, positive or negative about this idea.
I do have somewhat
working milter code at this point.
John P. Callahan <jcallaha at willamette.edu>
Director, Network Services
900 State St, Salem OR, 97301
Phone: 503-375-5495 Fax: 503-375-5456
"Michael D. Sofka" wrote:
> I've been running tests with MIMEDefang+SpamAssassin+Razor.
> is a sendmail milter. The latest versions make using SpamAssassin
> Generally, you have to be careful about false positives. Adding your
> institution to the whitelist is advised.
> You may also want to check out MailScanner
> which has some anti-spam provisions (using internet black lists).
> has a product which is also a Perl Milter. I haven't had a chance to
> I am not aware of any Exchange specific products, but ActiveState does
> distribute ActivePerl, which runs under windows so they may have a way
> to tie this all together with Exchange. (You could, for example,
> all incoming mail through sendmail, taking advantage of the various
> RBL's, as well as milters.)
> Catching Spam is difficult. Whatever method(s) you use, even with
> expect surprises and complaints. But, for some users it is going to
> At 05:26 PM 6/4/2002 -0400, Andre Earl Paquet wrote:
> > I am looking for an (incoming-)Spam-filtering program, that
> >attached to our Exchange server, centrally managed AND user
> > Does anybody out there have suggestions about such a beast ?
> > I know the "user selectable" part is difficult.
> > Background : we are in a University setting.
> > Some people are very fed up about SPAM. It is
> > true that it is getting difficult to bear :
> > for some, almost 50 % of their email is SPAM.
> > Some of these people would be willing to
> > support us if we subscribed to a third party
> > spam signatures provider to pre-filter their
> > incoming mail for them (with the appropriate
> > software). They DO NOT want to
> > maintain their own individual filters.
> > On the other hand, other people don't want to
> > hear about any content/source filtering for their
> > email. "One person's SPAM is the other person's
> > essential email", they say. And Big Brother, and
> > all that.
> > I tend to believe that SPAM is a fact of life,
> > even if I hate it, and I tend to agree with the
> > no-central-filtering crowd.
> > Nonetheless...
> > We would like to offer a non-compulsory
> > managed (third party maintained signatures)
> > filtering for those who want such a thing. People
> > would choose to opt-in.
> > Our official EMAIL platform is now
> > so it would have to integrate with that.
> > I will summarize.
> >Thank you,
> >Andre Earl Paquet,
> >Security Officer,
> >Universite de Montreal
> Michael Sofka sofkam at rpi.edu
> CCT Sr. Systems Programmer email, webmail, listproc, TeX,
> Rensselaer Polytechnic Institute, Troy, NY.
More information about the unisog