I don't know how you define "slowing down" but we've effectively
deployed a technology at http://www.titankey.com using early verions of
the "Recipient-Defined Consent" approach that is slowing bubbling
through this group. Users can define one or more email addresses and a
policy (i.e. Consent) of how that email address can be used. This policy
may include Challenge/Response, at the user's option. Users then use
these email addresses as they see fit.
If an email address is not used according to the policy defined by the
user, The Titan Key Servers respond with a 550 No Such User before the
DATA command. This effectively solves the spam bandwidth problem
(contents are never transmitted) as well as rendering the recipient
email address as useless. In addition, some (not all) bulk-emailers
stop sending bulk email after receiving the 550 which has the desireable
side-effect of reducing spam attackes over time, hence the "slowing
down" you asked about.
I've posted detailed 3 spreadsheets to this group before that have shown
the rate of "spam attacks" over time. One of them shows an actual
decrease in spam attacks over time. The 2 others show a slight increase.
I'd love to see how this slight increase compares w/ the average
Internet-wide increase in spam as I'd be willing to bet $1 that we have
in fact "slowed down" spammers when you compare the grown of spam
attacks to these test accounts vs. the growth of spam attacks overall.
Spreadsheets are at:
http://www.titankey.com/misc/logs/logLes.xls
http://www.titankey.com/misc/logs/logScot.xls
http://www.titankey.com/misc/logs/logPK.xls
Have fun.
Peter Kay, President
TitanKey Software
The only technology that stops spam BEFORE it's even sent
-----Original Message-----
From: C. Wegrzyn [mailto:wegrzyn(_at_)garbagedump(_dot_)com]
Sent: Friday, July 11, 2003 3:41 AM
To: Bill Cole
Cc: 'asrg(_at_)ietf(_dot_)org'
Subject: Re: [Asrg] Slowing down spammers - thoughts?
As I said in my original email I was looking for solutions to
slow them
down. You seemed to think I was suggesting examining or tightening up
the return codes. Nothing code be further from the truth.
I do believe that we shouldn't leave a stone unturned to find answers
for halting spam.
Chuck
Bill Cole wrote:
At 6:39 AM -0400 7/11/03, C. Wegrzyn wrote:
I've been giving more thought to how to slow down
spamming. It seems
we should just follow 7.3 of RFC2821 - return either 250 or 252 to
VRFY and EXPN commands. In this way the sender can't find out if
someone is really on a system.
I don't know what sort of mail servers you work with, but the ones I
do see insignificant amounts of VRFY and EXPN requests and already
return the same meaningless responses for all such queries
regardless
of their arguments. This has been common practice for many years.
RFC2821 was written to describe existing practice more than
it was to
recommend new security tactics.
Second I would kick back a 551 to every message being sent by a
domain/user I don't recognize or wanted to reject as SPAM. In the
former case I would send the email to the real recipient allowing
them to decide what to do with it.
1. If you kick back a 5xx code of any sort to any mail, you have
decided 'what to do with it' permanently and irrevocably.
2. Any system that generates a message to the recipient for each
message detected as spam is at least as bad as the spam for the
recipients behind it.
In any case, this sort of thing is well-established
practice. The only
utility I see in discussing details of response codes to various
conditions would be to standardize them for various meanings in the
area of spam. I may be misunderstanding the current state
of IETF/IRTF
affairs, but I think that's someone else's job. [2]
I the latter case I would just toss it or fill in the subject with
SPAM:.
Modification of existing headers by an MTA for any reason other than
address re-writing is fundamentally wrong.[1] Adding headers (as
SpamAssassin does) makes far more sense and prevents multiple such
strategies from colliding with each others' efforts. There are
certainly practical arguments for doing the conceptually
wrong thing
given the shortcomings of the world's dominant worm transmission
vector^W^W^W desktop mail client, but it would be a bad
precedent for
an IRTF process to accommodate ephemeral and easily overcome
shortcomings at the cost of making a 'hack' recommendation like
subject line mangling.
[1] Many have disagreed with that exception, but between
tradition and
pragmatic concerns it is hard to really swear off that arguably bad
habit. I think the battle was lost when the revival of
sendmail with
v8 kept header address rewriting alive.
[2] It's also arguably not all that useful. Many sites already have
concerns with using 5.7.x extended status codes because they reveal
policy detail to parties believed to be malicious.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg