ietf-asrg
[Top] [All Lists]

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

2003-05-12 13:47:27
I have been in touch with a company called MailCurcuit.com, who currently operates a C/R system. They are willing to provide information on their own experience with different aspects of C/R systems, as well as statistics. I will be passing along some statistical information from them.

Yakov

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:

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

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

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?

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?
-Access Codes: Should a barely legible, anti-bot access code also be
supplied?
-SMTP: Should SMTP responses be supported?

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>