RE: [Asrg] CRI Header

["Eric Dean" <[e-mail]>]

> At 09:43 AM 6/3/2003 -0400, Eric Dean wrote:
>
> >Trying to come up with the right place to shim in the CRI
> control headers.
> >It seems we can do the following:
> >
> >1) Use SMTP headers: beyond the deployment issues, CRI is not
> limited to the
> >envelope and there are often many mail relays in the path that
> could remove
> >such headers.  We do not want to restrict mail clients from implementing
> >CRI.
>
> As I mentioned before, SMTP would be a good solution only for those cases
> when two C/R systems are inter-operable and there is a need for
> the sender
> to take the burden of storing the message. Otherwise, plain email
> should be
> used so us humans can read the challenge message.

Split MX incoming from SMTP outgoing relay may or may not pose an issue.
Some mail servers allow for P2P clustering..like with SMTP VRFY, LDAP, or a
common database.  A CRI message could be queried against other servers..but
may be annoying.

> >2) Use RFC 2822 headers: we could possibly introduce a new field
> altogether
> >or use an optional field as spec'd in 3.6.8
>
> Using RFC 2822 headers would limit the amount of information since each
> header is limited to 998 characters (as per section 2.1.1).

Uh..998 is probably enough...and they really prefer 78 chars anyway

> Vernon Schryver
> (https://www1.ietf.org/mail-archive/working-groups/asrg/current/ms
> g05168.html)
> has already pointed out that MIME headers can store more
> information which
> would be a factor in case some kind of PKI signatures are used..

ok

> Additionally, some C/R systems might want to combine several challenges
> into one message and that would be awkward to do with RFC 2822
> headers. On
> the other hand, if such headers are used for single sender-single
> receiver
> C/R headers are the simplest solution.

2822 just seems more broad than MIME...I'm not leaning either way..it seems
that most people like to stick flotsam and jetsam in the MIME headers...but
I am not sure how the registration spec'd in 2048 will respond to us

> >Thoughts?
>
> Some of the purposes of MIME as stated in RFC 2045 and look perfectly
> suited for us:
>
> "(2) an extensible set of different formats for non-textual
> message bodies,
> (3) multi-part message bodies, and"

In 2048, we should fit in one of two areas:

1) External Body Access
2) Transfer Encoding

The more I read 2048, the more I ask myself "why the hell am I considering
MIME private values?"
>
> In our case we can utilize MIME to create a multi-part message with one
> part containing a human-readable challenge and other parts containing
> machine-readable challenges (i.e. non-textual message bodies). The
> advantages to using MIME is that:
> 1. We can include both human and machine requests in one messages, NOT
> limited in size.
> 2. We can include PKI signatures, hashcash codes, etc.
> 3. We can include multiple challenges and responses in one message.

Let's hope that IANA also sees our approach this way

> I think that all three approaches are good and they fulfill different
> needs. I think all three should be used and we will allow C/R systems
> to  negotiate between themselves:
> 1. The basic CRI protocol should use RFC 2822 headers, with single
> challenge per each sender. This allows for easier use with existing email
> systems and non interoperable C/R systems. Such messages will have the
> regular challenge message for humans in the message body with additional
> information in the headers. Using custom MIME types can make
> email software
> choke and leave the information unreadable to a human being.

ok..optional headers or do we introduce a new one?  There isn't an RFC 2822
registration process that I am aware of.

> 2. IF a C/R system is used by the sender, then it can identify itself
> either via ESMTP or an RFC 2822 header. Then the two systems can
> negotiate
> on the use of RFC 2822 headers, MIME headers or plain SMTP. This would be
> similar to the way HTTP clients negotiate with "Accept-Encoding" and
> "Content-Encoding" methods. This would allow interoperable C/R systems to
> use MIME and SMTP methods for cases like challenges to multiple senders,
> custom PKI, burden of storage on sender, etc.

ok

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