[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: .49, spam
> 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: email@example.com, firstname.lastname@example.org, and some such bogus ones.
Of course <email@example.com> and <firstname.lastname@example.org> 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 <email@example.com>, 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
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 ( firstname.lastname@example.org )
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.
- Re: .49, spam
- From: Arnt Gulbrandsen <email@example.com> (Wed, 2 Jul 1997 00:17:50 +0300)
- .49, spam
- From: Arnt Gulbrandsen <firstname.lastname@example.org>