Here is an informal C/R interworking system I have been working on lately:
I see 3 different types of C/R systems with varying levels of
verification based on what kind of information is wanted by the challenger:
1. Address verification. Challenge gets delivered therefore address is
valid.
2. Address + Message verification. Asks if system really sent the message
being challenged.
3. Address + Message + Human verification. Requires human response to
challenge.
These differences in motivations should be taken into account when working
to ensure interoperability because these types of challenges will take
different forms, and must be responded to differently.
1 is just an address probe. RFC 821 describes a VRFY command for this
purpose (does it work?). If this can be used I recommend it's use for
address verification to all makers of C/R systems.
2 could be done in SMTP time, but might be better done at the MUA. This type
of challenge could be answered automatically at the MUA. This type of check
would be useful to do to all messages, even ones for whom the address is
already whitelisted as it essentially authenticates the sender, and spoofing
a sending address becomes difficult or impossible, though there are
tradeoffs, and another form of authentication would probably be better.
This type of check would also eliminate the possibility that a spammer would
specify a random address to be challenged (see original message section) in
the hopes that the random party would answer the challenge, and help a spam
message pass through another person's system.
The challenged party should be able to say "no, I didn't send that".
3 must be done at the MUA. Hashcash and other proof of "x" checks would
require human agreement, and would fall under 3.
A person should only see challenge type #3 after the message passes type 2
verification.
This eliminates any advantage a spammer would receive from
faking a C/R subject to an auto answering C/R system, yet allows challenges
that require a human response to reach the inbox.
===============================================
The original message:
===============================================
The original message can have an optional machine/human readable top body
line requesting that the body either not be included in challenges, or that
it should be included. This line could be placed automatically.
This line can also specify an address that challenges should be sent to.
This will allow anyone to use an auto-answering services to automatically
answer the
challenges (you send a cc: or Bcc: to the company so they can check #2 type
challenges), and allow all challenges received at an address to be deleted
without processing (except type 3 challenges requiring human response that
come from the service, and could have a user defined subject line).
C/R systems should detect and respect this by never including the message
body if that request is made (even if a message checksum is not available),
and
by sending challenges to only the address listed here (to clear up confusion
about which address to use).
===============================================
The Challenge
===============================================
I see the following as the minimum necessary to ensure that no loops form:
Standard Subject deformation such as the addition of "CR#:" for all C/R
system challenges where # corresponds to challenge types 1,2, or 3 in the
list above.
The rest of the subject should be unchanged (may truncate overflowing
subject lines).
The top of the body should contain instructions for a human reading the
message, and outlining the mail handling procedure of the challenger in the
event of no response.
The date of the original message should be included.
A unique random identifying number to be repeated back in the response so
that the challenger can know that this is truly a response to the challenge
sent, and not a faked response sent at the same time as the message. This
also proves that the sender can answer challenges sent to the challenged
address.
A message specific identifier (such as an MD5 checksum of the body) so that
the challenged system can determine which message was challenged... the
entire body could be used, or the entire full message with headers could be
included.
===============================================
The Response to a "CR#:" message
===============================================
Once you have the right information, proper handling of the message is
necessary.
Messages with "CR(any #):" Should never be challenged.
Messages with "CR(1-3)" should be responded to in either the affirmative or
negative.(automatically if possible) The system should be smart enough to
realize when it doesn't know if it sent a message or not.
Messages with "CR(4-6)" should be Processed, and the original message(s)
should be delivered or deleted based on the response content, and the local
policy.
Responses to a challenge should retain the subject from the challenge with
one change.
The number in the "CR#:" tag should be increased by 3 to show that this is a
response to a challenge.
thus numbers 1,2, and 3 are challenges. And 4,5, and 6 are responses.
This should eliminate the possibility of loops.
If you receive a "CR7:","CR8:", or "CR9:" then a broken Challenge response
system on the other end would be detected. A "CR#:CR#:" Tag would indicate a
broken C/R system as well.
The identifying number should be included in the response.
And most importantly an answer to the challenge should be included (yes, no,
or unknown, plus Hashcash work/human response) if one is required by the
type of challenge being answered.
==============================
analysis:
==============================
These guidelines for C/R seem to me to solve a lot of the problems that C/R
would have normally:
Relative simplicity of implementation guidelines.
Provides support for varying goals of C/R systems.
Automatic responses to some challenges are possible, and would not
inconvenience the original sender at all.
Human responses are possible in old equipment, or C/R by proxy (for
automatic response) could be used..
Does not rely on any outside protocols in order to operate as it requires
only 2 way message transfer (does not require SMTP tweaks)
Header information not required.
Falsity in any part of the transaction is detected with C/R systems using
this method (spammers cannot use it to help reach users unless they are
stable enough to correctly answer the challenges themselves, and are thus
easier to track down).
Loops are virtually impossible between C/R systems using these methods.
Address to challenge confusion can be cleared up.
Local policy regarding un-cleared mail is up to the user.
Is open ended enough that it could be used as an unlimited proof of work
system (semi-equal access to all regardless of
language/handicap/education/Etc...except CPU power)
If Choicelist is used, then mailing lists would never be challenged, and
wanted automatic mailings would pass through this system with no problems.
Adoption population should rise rapidly as an auto-responding MUA will, most
likely, be demanded by many senders after they receive only a few
challenges. Such an MUA would probably be able to “play both roles” and
challenge mail as well, thus creating a feedback loop of increased adoption
pressure and C/R volume.
=============
Problems I see:
=============
widespread adoption would make it difficult or impossible to send or receive
truly anonymous email.
This does nothing to combat spammer evolution. In fact spammers may speed up
their evolution unless this evolution issue is addressed. I feel confident
that “ADV:” whitelisting could provide a solution to this, and would end the
escalating arms race against spammers.
=====================================================
Asrg Requirements from \x93draft-irtf-asrg-requirements-xx\x94 addresses here
=====================================================
2.1
I have not yet searched the RFCs for support or contradictions
2.1.1
MD5 and hashcash are accepted and established systems, and I believe that
randomly generated number comparisons are routinely used to prove that
message delivery has succeeded
2.2
The burden falls mostly on the recipient for storage until delivery, though
the sender would carry a small Checksum storage burden as well. The burden
imposed on the challenged party is there by design in C/R systems.
2.2.1
Avoidance of the manual burden of answering challenges might spur adoption
of auto-responding MUAs, and act as a support to adoption.
2.3
The proposed system would be mostly transparent for end users if an
auto-responding MUA is used. Mail providers would be pressured to implement
this system to remain competitive. This is a symptom of C/R itself, and
interoperability concerns would be decreased by a standard framework to
follow.
2.3.1
Not sure what atypical situations I should be evaluating, but in multiple
party messages, each recipient would independently challenge the message,
and the original sender would need to respond to each challenge individually
2.4
Only minor changes to most existing C/R systems would be needed, and
deployment of new C/R systems is already progressing without needing a push.
2.4.1
C/R already exists, this method would just allow interoperability between
them.
2.5
C/R would be interoperable under this method.
2.5.1
Old mailers are supported through Proxy Challenging to a service address.
C/R is already independent of SMTP, yet compatible with it.
I believe this method can be equally implemented on all platforms.
2.6
The subset of spam C/R will be most effective against will be anonymous mail
from unknown parties that cannot respond to the challenges.
2.6.1
I feel this interworking method is contiguous.
2.7
If C/R cannot be made workable then I see little hope for email.
2.7.1
Possible abuses are mentioned along with the solutions I have proposed.
2.8
Auto answering of minor challenges should be trivial, and would provide a
minimal barrier to legitimate message delivery.
2.8.1
this method does not limit content types, though it may introduce
significant delays in the delivery of email. Those delays are a part of C/R
and the auto response capability mentioned minimizes that delay in most
cases.
2.9
This proposal is not a C/R system, but a standard method that will allow C/R
systems to increase their interoperability
2.9.1
This has attempted to provide a solution that any party can use, and find
effective.
2.10
Legal aspects were not considered.
2.10.1
Patent law would be the only possible deterrent for this method, but that is
being discussed separately
2.11
This method is a simple as I could make it.
2.11.1
People can easily understand C/R on a basic level.
2.12
C/r is already being implemented.
2.12.1
I believe these have all been addressed
2.13
This method may be effective on SMS and other messaging platforms.
2.13.1
Specific implementations for other platforms have not been evaluated yet,
but seem possible to me.
2.14
Anonymity is reduced by this system, though through use of a third part
challenge answering service anonymity may be preserved through masking
challenge delivery through them.
2.14.1
Challenge forgery is addressed, and I feel solved.
Accountability consists of punishment of senders by possible message
deletion if a challenge is not received, and perhaps elevated status if a
response is received.
Preserving anonymity, and allowing sender tracing seem like contradictory
goals to me, and I can't think of any system that could do both well.
====================================================
John Fenley
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg