My thoughts on spam, filtering, and solutions...
There is already mass-marketing software out there that will randomly use a
wide range of smtp servers to dump it's load... even hitting each relay with
only a single outgoing message if the open list is broad enough, and
metering it's output rate to stay below any thresholds that might be
established, and even altering each message automatically to thwart
filtering schemes.
This makes it essentially impossible to block open relays by IP, or even
domain... the sender uses essentially all of them at once. It also makes
filter and list based methods useless because it reduces the consistency of
each message so that by the time spam is identified for filtering, the
messages have already been delivered.
With that kind of technology at their disposal, the counter attack must get
far more sophisticated. I envision a network of intelligent filtering
systems, more stringent authentication for senders, and even router-level
trapping through the use of packet watching... but all of this will also be
counteracted some day.
It's a lot like the electronic espionage game the NSA has been playing all
these years... one technology against the other in perpetuity.
I think that ultimately only content-based filtering will hold up - coupled
with sophisticated source blocking techniques (the original message must
come from somewhere). Even that will be an enormous undertaking though -
especially with networking practices, such as those at AOL, on the rise
where potentially every connection can appear to come from a different IP.
There is another more robust counter method which is far too restrictive
right now but may be expanded technologically to be viable in the near
future... The "subscription model" would work so that each email user had a
subscription list of sources they were willing to accept messages from...
They would provide trusted users with access codes which allowed them to
send their messages and also to subscribe the user to additional
addresses... for example, if I were to begin working with a company, I would
provide my main contact at that organization with codes to subscribe me to
their mailing list so that all of their internal users (but nobody else)
could send me mail...
The mail servers would communicate frequently to alter the codes so that
lists of access codes could not be easily collected or exploited, and the
servers would even manage most of the subscription processing and list
management... In the most restrictive configuration, the user would simply
not receive any mail that they did not pre-authorize by providing their
email address to a trusted user along with a subscription code... that user
would only need to use that code once and from that point on, the servers on
both ends would maintain the subscription and authentication through the use
of a "chaotic stream authentication" scheme. (If that blew by then email me
privately and I'll explain.)
If the user wanted to be even more secure, they could simply subscribe the
sender themselves rather than giving out their code... they would do this by
sending a simple subscribe message to user they wanted to authorize, or to
the user's server... At some point I would expect that mail clients would
begin to manage this process more effectively.
Rejected mail, and anonymous or unauthorized subscription requests could be
handled according to a rule set so that they would be either rejected,
dumped, or sequestered for later review. This would include anonymous
subscription requests that the receiver could review and authorize (or not),
after which all queued mail from that source would be delivered and that
source would be subscribed (or not).
With a subscription model, only businesses with open inboxes (like info,
sales, etc...) would be subject to large volumes of spam. They would also be
more likely to have the resources to plow through it and filter it, and less
likely to be interested in much of content thereby reducing the
effectiveness of spamming.
This technology would ultimately reduce the potential gains of spamming, and
it would remove (in large part) the problem of identifying spam by content -
that hard problem where one person's spam is another person's legitimate
mail.
Anybody interested in developing this technology with us?
_Pete
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of ## Dusty Carden
Sent: Wednesday, March 15, 2000 1:42 AM
To: [EMAIL PROTECTED]
Subject: Re: [IMail Forum] Getting Spammed to death...
I wish it did generate a text file. I use the Admin Web interface
to enter mine in. Cuts down on having to enter them twice
plus I am able to add them from anywhere. The service restart
is a killer at time from the Web interface though.
With many of the mailbombs we get coming from dialups
it would be nice to have a hook to at least the MAPS DUL.
I was testing an external SMTP server the other day with
DUL support and turned away almost 300 in a 8 hour period.
That is 200 that would be able to connect to the Imail box.
On a side note I ran across a software developer page today
that sells software which will test a very broad range of addresses
in search of SMTP servers. It will identify them as available for
relay, etc. SO when anyone wonders how they found you
hiding in the corner.... If you are running a open relay you have
been caught with your pants around your knees.
Dusty
At 11:46 PM 3/14/00, you wrote:
>These are just very annoying mail bombs. The embedded outside addresses
are
>not getting out, shut down by the fact that we relay only for our
addresses.
>
>I noticed another thing, to enter an address in the control access list, I
>have to enter it twice. Does this generate a text based file we can add to
>easier, then just restart smtp?
>
>It's been real active lately with mail bombs and spam attempts. I've
>blocked the IP's of the major offenders, but they are much more persistant
>then in the past.
>
>[EMAIL PROTECTED]
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
