ietf-asrg
[Top] [All Lists]

[Asrg] Several Observations and a solution that addresses them all

2003-03-10 10:38:27
Every good scientist makes observations first, forms a hypothesis, and then
tests it. It's the scientific method, and I think we should be using it
here.

Observations:
1) Spam only comes from those we don't know. (If it does come from those we
do, then it might not be spam)

2) We trust those that we know. The opposite is also true.

3) Content filters are unacceptable; 99% of the people don't know how to
work them, and you CAN'T install them for someone (I.e. Filtering on the
mail server by admins is not permissible- both privacy and reliability
concerns)

4) Spam pays because it's cheap

5) Spammers don't care who they are, or who you are - BUT the receivers do.

6) Spammers don't play fair, and bend the rules. Social engineering, filter
evasion, etc.

{Feel free to add some more}

Theory:
From all the above, but mainly 5, we can get a solution. If we make the
spammer at least appear credible, even for a short while, then they can be
limited (controlled).

Spamming involves sending out junk mail messages at a fast rate. The faster,
the better for the spammer. Rate throttling only works until they learn to
parallelism their operation(s)

However if we make the spammer identify themselves (and appear creditable)
we can rope them in and control them.

Here's how. Each message must have a valid from address. This address is
validated against and ISP's database. If the account exists, then the mail
is allowed to be received, otherwise it is thrown in the trash. It's very
much like putting a return address on an envelope, but since
computers/networks are so fast we can verify in real time that it is fast.
Any mail without a return address gets put in the trash (and this is
generally the case in real life too)

In my previous email, I suggested the idea of a "promoted" and "demoted"
char for email addresses to suggest this reverse "authentication" (for lack
of a better word) capability. If the promoted char is used, the messages is
reverse authenticated, if it passes, it keeps (or if all messages are
authenticated) the promoted char is used. Else it gets demoted to '@'. There
is no real functional reason aside form sorting that the new char is needed.
Indeed prompted char can equal demoted char.

Anonymity can still be protected. Anonymity at the very least proves
legitimate existence, which is all we need to know.

Example:
Yahoo.com (or whomever) will be getting all these requests for
32423(_at_)yahoo(_dot_)com and saying 'account does not exist', and the mail 
will be
demoted (with possible deletion)

Problem #1:
account(_at_)yahoo(_dot_)com is real, but did not send the message (spoofed 
addr).

Solution #1:
The outgoing mail server will have to see what addresses 
account(_at_)yahoo(_dot_)com
did send to that haven't been verified ("authenticated") yet. If it gets a
request from an account that was not sent to, then it sends an 'account does
not exist' message. This will cause the spoofed message to be rejected,
while not allowing the existence of an account to be determined by a
malicious entity.

Problem #2:
Spammer sets up a domain (or at least a server) to do his bidding. He sets
up 1 to 1000 accounts all to spam, or a rogue server to verify ANY auth
attempts.

Solution #2:
In order for any to get through to the recipient, they have to be
"authenticated"  (reverse look-up now comes to mind as a better term). If he
allows this, then he has identified himself as a source, (he can be traced
back) and measures by his ISP can force him off the net. Also note that
generally there are a fixed number of ISPs, and they can flag his credit
card/account as to not give that card an account. After a while, all the
cards will be used, and all the ISPs will know the all the cards/accounts.

Problem #3:
"Fly by night" or "dump" operations - spam and move

Solution #3:
The spammer has to be there long enough for the bulk of his messages to get
"authenticated". This puts him on the net and ties him down to an address
long enough to be caught/blacklisted/whatever. It also means that his
machine must be able to handle the stampede of "authentications" that will
be coming back. Spammers in this instance may actually throttle themselves
back, lest their incoming slow their outgoing.

This system seems easily implemented, and will go a long way to
eliminate/cut down/make filterable the spam.

Note: that once this "authentication" is implemented, it can be extended
with full-out crypto (where legal) or other capabilities. Example:
undeliverable messages. The advanced server can count the undeliverables
coming back for and address and flag the sender as a spammer. You can also
limit the number of messages sent or received per account rather easily once
this infrastructure is in place. (Note: this is now optional in my head)

The one argument against:
Resources- email addresses are short, and easily stored for a "short" time
(for solution #2). The authentication process need not be long or wordy. It
is anticipated that a few spam messages dropped by this scheme will more
than make up for hundreds of authentications (characters by volume)

One other wary point: A spammer can validate an email address by sending a
message and watch for the bounce back authentication request. Therefore all
queries must be as anonymous as possible, and preferably proxied outside the
recipient's domain. This doesn't "fix" the problem, but it does throttle
them back severely. Of course, most forums and newsgroups and email lists
already reveal your address...


Thoughts/comments welcome.

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg