[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 []
> 14799r  EHLO riva.koti.com.pl
> 14799w  250 HELP
> 14799r  MAIL From:<andrzej@aku.com.pl> 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:
		senderokwithdns +
	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:
		ehlo nic.funet.fi
		MAIL From:<andrzej@aku.com.pl> 
	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:
		mail from:<....>
		rcpt to:<....>
	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
> @teakusa.com
> @tweakusa.com
> 293:ROOT@SunSITE:/local/lib/mail/db#
> Some subsequent testing has shown that indeed the string matching seems
> to be very "fuzzy" -- akuaku.com.pl for example gets rejected as spam,
> too.

	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 ?
> --J.

/Matti Aarnio <mea@nic.funet.fi>