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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg