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

[Yakov Shafranovich <[e-mail]>]

At 07:02 PM 5/11/2003 -0400, Eric Dean wrote:

>Per the request to put together ideas regarding C/R systems below is a brief
>inventory of some possible areas for a C/R standardization effort.  I'm not
>advocating standardization of any of these...but rather identifying areas
>that to some are obvious.  The MUST, SHALLs, and MAY's can follow later:

We probably cannot recommend any specific implementation details like which 
filters should be used for message scoring,  just general guidelines. 
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. We need some 
input from live C/R systems.

>There are a few general components to C/R or any email system
>1) Message receipt:
>-Permit: Whitelist sender, message scoring...automatically delivers to
>user's Inbox
>-Drop: Blacklist, message scoring...drops message
>-Pend: Hold message in queue for further C/R validation

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?

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.

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)?

>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.

>-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.

>-Actions: Should a sender be allowed to merely confirm or can they also
>report that they did not originate the message..or possibly report to an
>authority

Implementation-specific but at the least an admin email should be provided 
(that DOES NOT need C/R) where the users can email for with questions.

>-Challenge Bounce: There are a variety of SMTP errors that can be
>returned...should some be considered to result in an automatic message drop?
>Blacklisting a sender may result in a later valid user actual taking that
>user namespace.

A C/R system should whitelist a sender when response received, not do 
anything otherwise. Blacklists should be used when the receiver wants to 
block an already verified sender.

>3) List Detection
>-Sender Header: What methods other than the sender header should be used to
>detect a mailing list thus disabling C/R messages?

For starters look for "List-Id:" and other "List-*" headers. Perhaps a 
standard way can be setup for a C/R system and mailing list software to be 
able to talk to each other automatically without a need for a human being 
to reply. Of course that will allow a hole for spammers to sneak through.


>4) Sender Response
>-HTTP: Are there recommended methods for producing verification URLs?
>Certainly they should be unguessable.  Should they have a short TTL or have
>a persistent convention?

No persistent convention since that might allow spammers to build automated 
software. TTL is implementation specific, we cannot force everyone to use 
the same value. Preferably the challenge message should not be in HTML but 
plain text since not everyone has HTML or displays it differently. The 
response message might not via an HTTP url but could be just a response 
email - some people might only have email and not http (think mobile 
devices). It is best to support both - an HTTP url and a return email. 
Recommended methods for producing verification should utilize secure random 
generators with a large enough number of bits.

For verification purposes, special graphic images that are not parsable via 
OCR should be used on web pages much like the ones used by HotMail and 
Yahoo on account signups.

>-Access Codes: Should a barely legible, anti-bot access code also be
>supplied?


Explain.

>-SMTP: Should SMTP responses be supported?

Perhaps but we should probably avoid making changes to basic protocols as 
much as possible.

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <[e-mail]>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------  

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