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