Mailing List Message #6422
From: Daniel Solomons <>
Subject: Re: (not so) Obvious spam address
Date: Thu, 6 Jul 2000 12:08:55 -0700
To: SIMS Discussions <>
Hello -

At 8:51 AM -0500 7/6/00, Dave Martin wrote:
I've been getting them, too. Mainly the forged and
fake addresses, and a few from yahoo. Some, however, are traceable to (the real source of many of these spams). I went ahead and
blocked all msn and hotbot through router error, and check the logs now
and then to make sure REAL things aren't being denied--no false positives
so far.

You blocked msn and hotbot!!!!

(I would if I could, but I regularly deliver legitimate messages from both services.)

Key thing is to notify the postmaster/abuse at (or
whatever site DELIVERED to your SIMS machine--do a lookup on the IP to
verify if needed) that they have an open relay. Blocking that relay in
your blacklist probably won't help--too late, they've moved on to another
by then anyway.

Exactly. And too late to notify about an open relay. Not that they seem to care. I spoke to exodus and pacbell, where a number of the messages were relayed. They told me there was nothing they could do at their end. Why don't I block nonsense senders? :>

I also pass the spam messages on to the host being slighted...some of
these big commercial sites have the resources and the PR interest in
ensuring nobody disses their reputation by sending forged spam with their
service implicated as an accomplice.

I regularly do this myself, and have no evidence it succeeds. Quite the contrary. I have sent the big companies summaries of ongoing floods from their networks, yet the spam continues unabated.

It might be nice if SIMS could do some "Received" backtracking, but that
would require accepting the connection to read headers, and would add to
overhead as each IP address/hostname in the Received path (part of which
may be forged, too) was DNS/revDNS inspected for possible blacklist or
RBL matches. I know when our university "forced" a secondary MX on us,
tons of spam which SIMS would have stopped came through, because the
secondary was a "trusted" host, and it was accepting the spam
unconditionally. If SIMS could have checked the received's (maybe even
just the previous one), and do checks on that, a lot of stuff would have
been blocked.

Unless I'm misunderstanding what you're saying, SIMS checks all received IPs against its internal blacklist, and checks RBL only for the immediate connection. You raise an interesting point. Because of this and certain other complications, I run SIMS without seconding. <gasp!>


I would point out that the address on the first example you sent DOES NOT
match your multiple groups of numerics rule, though it would match an
"embedded" numerics.

Sorry, I thought I made that clear.

 I'll also mention that accounts here at my
university typically use the student's initials and part of their ID
number as the default username--and if they have no middle initial (as
with many of our international students), a zero is put in that position
instead. Thus "ABC1234" or "A0C1234" are very common account names here,
and if the initials and ID segment are duplicated (more frequent than
you'd think), the last digit is replaced with a letter ("A0C123B").

Good point. You have successfully defeated the simplest traps :)

I think you'd need a fuzzy logic algorithm for best filtering

A0C123B and uDj09qXpq, while closer than I'd like, can still be distinguished by simple rules. The strange mix of caps, for instance.

and a
means for SIMS to sideline questionable items for admin inspection.

Yes, this makes sense.

some of it would be nice, there's obviously some limits to what a
computer program can reasonably be expected to do (especially for

True :) Nevertheless, my sendmail servers block spam that SIMS has been passing with regularity. Since regx passed its 40'th birthday, I felt that it should be the weaker of the two systems.

It just means we have to pay more attention as admins, and deal
with things as they happen, which is exactly why we are here in the first

If suspect messages could be sidelined for "manual" delivery, filtering could be more aggressive and less interfering at the same time.

One question regarding "proper" RFC formatting of messages and
headers...where does the requirement or responsibility for the Message-ID
field lie?

 >>Message-ID: <IntmSCKG280o>

It is generated by the client, and should end @host. The only messages I see that don't end @host are spam.

Most of the ones I've paid attention to have the @host, though perhaps
it's not a strict enough rule that SIMS could flag messages which either
do not have a Message-ID line, or have one like the above. Unfortunately
on some of these spams the @host has been provided by the open relay

It would have caught the spams in question...seems like a good idea :-)



Daniel Solomons
Internet Central

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster