At 12:21 PM 6/3/2003 -0600, John Fenley wrote:
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.
Eric Dean's draft primarily concentrates on the first two items.
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.
RFC 2505, section 2.11:
"Both SMTP VRFY and EXPN provide means for a potential spammer to test
whether the addresses on his list are valid (VRFY) and even get more
addresses (EXPN). Therefore, the MTA SHOULD control who is is allowed to
issue these commands. This may be "on/off" or it may use access lists
similar to those mentioned previously."
The main problem with VRFY is that it allows the spammer to verify addresses.
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".
This would require the sender to keep track of all sent email. This raises
some privacy issues and generally increases the burden on the receiver.
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 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).
What stops spammers for using CR subjects in order to bypass C/R systems?
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.
Checksums are better, anything else would have privacy implications.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg