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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg