Subject: RE: [Asrg] 6. Proposals - Challenge/response - CRI

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 17 Aug 2003 22:34:13 -0400

At 04:40 PM 8/15/2003, Eric Dean wrote:
>.............
> > My other "first reaction" to the proposal is that the SMTP idea is
> > interesting although the use of a 4xx temporary failure code for a
> > challenge will of course result in non-compliant sender MTAs
> > retrying and repeatedly failing. Of course in the end they'll
> > give up and then will the sender's original message bounce back?
>
>I'll let Yakov reply

[Sorry guys for the delay, but with the blackout my company's mail servers 
went offline and I missed the message.]

The CRI proposal itself proposes the use of SMTP in addition to MIME 
headers in order to facilitate easier interoperability between two systems 
that already support CRI. By using the SMTP extension, the receiver's 
system can forgo the expense of storing the email while the verification 
process takes place - instead that burden remains on the sender's system.

However, I am assuming that you are referring to "GreyListing" 
(http://projects.puremagic.com/greylisting/) which rejects the email with a 
temporary code. While GreyListing rejects email from specific 
IP/sender/recipient combinations, in C/R systems that would take place for 
any non-whitelisted message. This is in fact what Peter Key's TitanKey 
system does, although it rejects the message with a 5xx code.

A normal Internet email system will keep on retrying to send the message 
depending on settings set by administrator for quite some time (I have seen 
email systems that go on for over seven days). In the end they will fail 
and bounce the message to the sender. However, in that case the sender has 
an option to resend the message once he replied to the challenge. In that 
case, his email will go through.

NOTE: Keep in mind that the ESMTP extension in the CRI proposal only 
applies to two systems that both supports CRI. If one of the parties does 
not support CRI, then everything falls back on MIME headers.

> > I'm interested here in the interoperability issues between MTAs
> > which support CRI and those which don't. Some more discussion in
> > that area would be helpful.
>
>Well..the MIME headers should be transparent...then you still have to write
>a clear email message explaining what to do.

One of the things mentioned in the CRI proposals is the possible use of 
DSNs. DSNs have a human-readable message as well for system that are 
non-compliant. In CRI enabled systems, the human readable part will contain 
response directions for non-compliant systems. The machine-readable part 
will contain CRI headers for systems that support CRI.

Yakov  

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Andrew Akehurst <[email-masked]>
Date: Wed, 20 Aug 2003 09:48:40 +0100 (BST)

Hello everyone

Some forwarded further reaction to the CRI proposal here from David.
I've had a few ideas myself over the past couple of days and I'll be
posting them shortly.

Thanks

Andrew

----- Forwarded message from david nicol <[email-masked]> -----
>
> I think it's too complex and fiddles with too many preexisting
> protocols.
>
>
> Recently someone on the djbdns mailing list wrote an autoresponder
> to reply to the challenges that that mailing list sends out on every
> list posting.  Someone else forged messages from the autoresponder
> author's return address and the forged messages appeared on the
> list.  So the autoresponder in question was merely operating at
> level one and not level two of the three levels defined in the draft,
> which I found to be a good set of definitions.
>
> I am opposed to level three.  As computing power keeps increasing,
> as well as the availability of human brains, when properly organized,
> turing test systems become useless.
>
> I think a good thing to agree on might be an XML DTD for challenges
> and responses, which could be embedded into a human-readable
> challenge message that states the same thing as the XML challenge,
> for those users (initially everyone) who do not use a CRI-enabled
> MUA.
>
> What information would beed to be in there, to have level two
> functionality?  Last night I came up with what I believe is a
> workable set:
>
> 1: message-ID of the message in question.  Message-IDs are generated
> by the MUA (well they can be) and the MUA can remember which ones it
> generated.  Message-ID alone allows a valid Message-ID to be attached
> to an invalid message, so Message-ID is not sufficient.
>
> 2: MD5 hash of the body of the message.  By including this information,
> it is only possible to forge a message that was actually sent.
>
> 3: subject line.  It appears in the header, not the body, and it
> is good to include the subject line in human-readable forms.
>
>
> So when [email-masked] sends a message to [email-masked],
> the abigail's MUA might generate a challenge like follows and
> send it to tom before accepting tom's message (and perhaps
> caching tom's return address and the smtp server the message
> arrived from as valid and not warranting future challenges)
>
> envelope-return-address: [email-masked]
> evelope-recipient: [email-masked]
> X-Asrg-Cri-Status: Challenge
> Message-Id: <[email-masked]>
> From: <[email-masked]>
> Date: ...
> Subject: Challenge re: Beans?
>
> This message is a challenge to verify that [email-masked]
> sent a message with subject line <<Beans?>> to
> [email-masked].
>
> If you sent the message in question, please forward this
> challenge message to [email-masked] (replying to
> it should work)
>
> If you did not send the message and would like to report
> an abuse incident, please forward this challenge message
> to [email-masked].
>
> The following XML block is included for people using
> CRI-enabled e-mail software.
>
> <challenge>
> <challengeid>847568276345.24958793287</challengeid>
> <messageid>[email-masked]</messageid>
> <bodyhash>c5fb7d43ba68c638b75485220a3c3372</bodyhash>
> <subject>Beans?</subject>
> <forwardifgood>[email-masked]</forwardifgood>
> <forwardifbad>[email-masked]</forwardifbad>
> </challenge>
>
> __END__
>
>
> I suppose this could all be done with headers instead of
> a block in the message body, but headers often get lost.
>
>
>
> I think the only really significant semantic suggestion I'm making
> is that a hash of the body of a message should be included to
> prevent forgeries of level-two systems.
>
>
> How would it interact with mailing lists?
>
> * the CRI-enabled MUA would have a way to turn off challenges for
> known-good sources (guest-list, known-good mailing lists) without
> presuming a source good simply due to the appearance of some header
> or other.
>
> * the CRI-enabled listserv would recognize the challenge as such
> (instead of as a bounce, assuming it is a VERPing listserv) and
> respond correctly, possibly using a to-be-defined extended
> syntax for declaring "I am a listserv! You can recognize traffic
> from me because it comes from 192.0.2.174 and it always contains
> a header "List-ID: [email-masked]"
>
>
>
>
>
>
> ps. the hash in the example is a hex MD5 hash of "fee fi fo fum!"
>
> David Nicol / If at first you don't succeed, use a bigger hammer.
>                                        http://gallaghersmash.com