Subject: RE: [Asrg] Slowing down spammers - thoughts?

From: "Peter Kay" <[email-masked]>
Date: Fri, 11 Jul 2003 06:41:26 -1000

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:[email-masked]] 
> Sent: Friday, July 11, 2003 3:41 AM
> To: Bill Cole
> Cc: [email-masked]'
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
> 
> 

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "C. Wegrzyn" <[email-masked]>
Date: Fri, 11 Jul 2003 17:56:11 -0400

Thanks Peter. You answered my question - the 55x approach will work. 
That is what I thought.

Chuck Wegrzyn