[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Policy based spam filtering - bug ?
> Please take a look at the following:
> 14799# connection from riva.koti.com.pl ident: root [port 11097]
> 14799w 220 sunsite.icm.edu.pl ZMailer Server 2.99.49p8 #9 ESMTP+IDENT ready at Thu, 1
> 3 Nov 1997 11:11:36 +0100
> 14799# remote from [22.214.171.124]
> 14799r EHLO riva.koti.com.pl
> 14799w 250 HELP
> 14799r MAIL From:<firstname.lastname@example.org> SIZE=799
> 14799w 453-4.7.1 Access denied due to excessive spamming from your domain
> 14799w 453-4.7.1 or address. If you are a customer of a spam-friendly ISP,
> 14799w 453-4.7.1 we recommend changing to a different ISP.
> 14799w 453-4.7.1
> 14799w 453 4.7.1 We apologize for the inconvenience.
> 14799r QUIT
> 14799w 221 2.0.0 sunsite.icm.edu.pl Out
With this example I am more and more convinced that we
need an interactive tool to test the policy database,
and the decission analysis within it.
That report message in itself may have been somewhat
errorneous. You apparently (*) have rule checking:
which yields "spam" report (because it is the only report)
possibly due to a timeout at the DNS lookup.
(*) The "how" I did find that out was simply telneting
to your SunSITE, and:
and watching the reports.
(I don't think this "debug" command is a security threat, but
it sure reveals the policy setup, which you may consider
sensitive. I think I will add a set of smtpserver.conf options
to control the availability of EXPN/VERY/DEBUG commands.)
The problem in here is, the system has already done TWO
policy lookups at the connection acceptance BEFORE it
presents the initial "220" greeting banner, and we have
no way of knowing what those decissions were.
That is where I think an interactive debug tool would help;
equip to it a set of commands:
Anybody willing to write such simplified "smtpserver" to
help to test policy functions ?
This is one of the reasons the policy routines are somewhat
modularized -- they are easier to plug into other main programs.
> 292:ROOT@SunSITE:/local/lib/mail/db#grep aku smtp-policy.spam
> Some subsequent testing has shown that indeed the string matching seems
> to be very "fuzzy" -- akuaku.com.pl for example gets rejected as spam,
NXDOMAIN -- yeah, the message is -- somewhat misleading.
> I'm using btree as the db type. Anything I'm doing wrong here, or is it
> a real bug ?
/Matti Aarnio <email@example.com>