Re: .49, spam

[Matti Aarnio <mea@nic.funet.fi>]

> ZMailer 2.99.49 looks very good (thanks, Matti), but I'm feeling a
> little down at the moment.
> 
> The fourth message coming in after I upgraded my real mail server to
> 2.99.49p2 was spam.  1, 2, 3, spam.  Didn't even take a minute.

	I didn't feel very good either when at last weekend somebody
	at Santa Ana, California dialed in and did relay-hijack spam
	of marketing stuff all around with claiming source addresses
	of:   asdfg@utu.fi,  536533@utu.fi,  and some such bogus ones.
	Of course <abuse@utu.fi> and <postmaster@utu.fi> got hate-mail..

	The mechanisms we have are able to limit/block relay mailer
	hijack, but now that SPAMmers appear to have started individual
	message delivery straight off their machines to the destination
	addresses as per MX/A resolving, much isn't doable.

	One needs near instantaneous knowledge of spam sources, or a real
	AI system for message content analysis/spam filtering, but ...
	(if you can find this latter, I would adapt it into an auto-secretary
	 for me ;-)   I have been dreaming of it since 1986 when I go to
	 EARN/BITNET, and had 'mail flood' of 20 messages per day... )

	Of course we could consider similar approaces to the problem
	as virus scanner makers are using.  Just scan the message body
	for magic identification factors, and bingo...  but what will
	happen, if somebody forwards a message with matching string,
	but with legitimate content ?  Like when sending such a mail to
	postmaster, or abuse, or ...

> The message came from something like <1fvdf@ejfvsd.afhdjalf3.vmx>, and
> I don't see any way to reject things like that.  Could smtpserver do
> an MX/A lookup of the envelope sender domain?  Would that be a bad
> idea?

	Some sites already do, AOL.COM, for example.
	They seem to run massive amounts (10-20) parallel input
	systems all running sendmails to verify incoming MAIL FROM:<...>
	addresses per MX/A data, however ...

	... I have spent a day at fighting incoming FLOOD of error
	messages from some SMAP/sendmail pair sending same messages
	over and over again.  So far vger.rutgers.edu has received
	some 26 000 of those messages, several per second.

	The Vger did have several very high load bursts -- up to 170!
	with these incoming messages, until I realized that doing
	ident lookup (the '-a' option at the smtpserver) delays the
	server too much!   Also apparently the feeding system is a lot
	bigger one, than Vger.   Vger is a sparc-classic w/ 32 MB RAM!

	That has teached to me that MX/A resolving - while nice idea - is
	not necessarily something you can do without multiple external input
	front-end machines, or you soon run out of resources.


	By the way, we solved the problem to a large extent by defining
	the error receiving address ( owner-some-list@ver.rurgers.edu )
	to have policy attribute:  'freeze +'
	(and $POSTOFFICE/freezer/ directory had to be created there too)
	The smtpserver shunts all the most volumous errors into a freezer
	box, and leaves the system to process far fewer legitimate msgs.
	I had to patch the  smtpserver/policytest.c  to also test the
	full target address, and not just the target host.

	Noticing at Vger often even as much as 20 incoming smtpserver
	sessions from the SAME source IP address gets me wondering, if
	there would be sense to have a feature at the smtpserver, that
	it could refuse to server the client when there are already
	more than some [smtpserver.conf configurable] number of
	clients from the same IP address.

	... and it is clear that Gabor Kissigs original plan of running
	smtpserver, and router in tandem would have been terrible disaster
	at these loads...

> I know about -sf, but that seems like policy ("we ignore mail from
> such and such domain"), not a DNS query.
> 
> Btw, this patch ought to make policy-builder.sh a little better.
...
> The tr handles things like cyber-s-i-q.com vs. cyber-S-I-Q.com, the
> grep (untested, I did that by hand) should grep away stuff zmailer
> won't digest, "bhaffle,wuyffle.com" for example (note comma).

	Yeah, qmail allows any junk, while ZMailer preselects :-)
	Anyway, the  "makendbm -p ..." does translate all of the
	key strings into lowercase, and then complain duplicates,
	like in your  cyber-s-i-q.com  case above.  Also, the db
	gets visited at places of interest only, in which case a
	moderate amount of junk around the corners should not matter.

> --Arnt