RE: [Asrg] C/R Thoughts: Take 1

["Eric Dean" <eric@purespeed.com>]

> We probably cannot recommend any specific implementation details
> like which
> filters should be used for message scoring,  just general guidelines.

ok..again, I'm merely inventorying the potential areas of interest..not
advocating anything in particular

> However, one problem with C/R systems is that spammers do not currently
> have an incentive to break them since there are many other ways to send
> spam. If C/R systems become wide spread, spammers will have an
> incentive to
> attack them and perhaps (gasp) even manage to break them.

Well, we better build something they can't break.  There are many, many
smart people on this list that can surely put something  together over time

> We need some
> input from live C/R systems.

We have a live C/R system and Mailcircuit is also a good source...not sure
how many other people on the list use C/R...but just about everyone knows
the vulnerabilities and limitations...often standards are discussed prior to
implementation...we have an advantage here.  I believe all would agree that
C/R should probably be tighter than current implementations..what that
results in..don't know.

> Would message scoring automatically drop messages below a certain
> threshold? Spam filters are not fool-proof and some messages
> might be lost.
> Perhaps all incoming email should be challenged or giving that as
> an option
> to the user?

ok..not trying to jump into the pool yet...just trying tom set
dimensions...not looking to take anythign off the table..jsut determing what
should be on the table

> Also, maybe a C/R system should be combined with a rDNS/RMX
> system to weed
> out invalid email addresses BEFORE a challenge is sent, in order
> to save on
> the use of computer resources.

Not sure any measures would be in conflict with one another.

> How would a whitelist handle mailing lists? What about automated computer
> programs that notify users, like Ebay's auction bots? And what about
> anonymous email, if C/R is implemented everywhere, can anyone send
> anonymous email anymore? What about opt-in email that the receiver forgot
> about the original opt-in? And email that is sent from different email
> addresses everytime (like some mailing lists)?

All of these are important tactical issues..any more?

> >2) Sender Challenge
> >-Sender name: Should the original sender's name be sent in the
> reply to of a
> >challenge message or should a common name be used.  For examples, bounces
> >use <>.  C/R systems might avoid C/R loops using a convention.
>
> It is not important to send the sender's name back, the email address is
> sufficient. As for bounces, a header might be used to catch that like the
> "X-BeenThere:" header used for our mailing list.

ok..that's one approach

> >-Subject header: Should the original subject header be preserved or a new
> >subject header be sent.  C/R systems might avoid C/R loops using a
> >convention.
>
> The challenge should contain at the least a copy of the header somewhere
> within the message so the sender can figure out what the challenge is in
> relation to. As for loops, use headers.

ok..as for the rest of your contributions.  I'm not particularly interested
in debating issues but rather discuss what issues we should debate.  I'm
sure  there will be spirited discussions to come..but for now..I want to
know what should get included within in a draft framework.



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg