Re: [Asrg] C/R Interworking Framework

[Yakov Shafranovich <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg