Re: [Asrg] C/R Framework
2003-05-15 08:52:24
At 10:23 PM 5/14/2003 -0400, Eric Dean wrote:
Attached, you'll find a proposed framework I have put together for a C/R
discussion. Please excuse the formating..I'll groff it soon..assuming it
lives.
I have attempted to capture some of the key areas and concerns that have
been discussed over the past couple of weeks as well as incorporate some of
my own ideas. My intent is to throw something down on the table that's at
least wrong and allow for an exchange of ideas regarding how to proceed if
at all.
Below is a copy of some of the comments on this proposal that I previously
emailed to Eric. He agreed that they should be posted to the entire list.
--------------------------------
Abstract
RFC821 was not designed to authenticate sources or senders of email
messages. In an effort to reduce spam on the Internet, this document
defines a method by which email senders may be authenticated and
determined if that sender originated a message to a designated recipient.
In the purposes section, we state that this is "-Not an authentication
method for email delivery or security protocol". Is our intent to make sure
that the sender's email address is valid but not to authenticate the actual
identity of the sender? I am not readily understanding the different
between this statement and the conflicting statement in the purposes
section. Is making sure that the original sender exists called
"authentication" or perhaps a different term should be used?
Also, I came across an interesting quote in section 7.1 of RFC 2821:
"Efforts to make it more difficult for users to set envelope return
path and header "From" fields to point to valid addresses other than
their own are largely misguided: they frustrate legitimate
applications in which mail is sent by one user on behalf of another
or in which error (or normal) replies should be directed to a special
address. (Systems that provide convenient ways for users to alter
these fields on a per-message basis should attempt to establish a
primary and permanent mailbox address for the user so that Sender
fields within the message data can be generated sensibly.)
This specification does not further address the authentication issues
associated with SMTP other than to advocate that useful functionality
not be disabled in the hope of providing some small margin of
protection against an ignorant user who is trying to fake mail."
This document proposes the use of MIME experimental content-type values
for automated C/R control.
We need to define more precisely exactly which header we are using. We ARE
NOT using the "Message-Context" defined in RFC3458 since that is
presentation logic, and not the "Content Disposition" header either (RFC
2183) for the same reason. So are we using the "Content-Type:" header
defined in RFC 2045? If so should we be suggesting a custom type starting
with "X-" or should we specify a new type: probably something like
"message/challenge" (see
http://www.iana.org/assignments/media-types/message/ for current
assignments in the "message" category)? The "message" type is defined in
RFC 2046.
In general the purpose of MIME as outline in RFC 2045 is:
"This set of documents, collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other than US-ASCII,
(2) an extensible set of different formats for non-textual message
bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than US-ASCII."
All of these do not apply in our case, all of our information is stored in
headers only (for the automatic protocol, the manual protocol includes
links in the message body. Headers are defined in sections 2.1 and 2.2 of
RFC 2822 and we must decide if we are going to define standard headers or
extension headers ("CM: or X-CM"). If we are using custom headers, then
reference to sections 4.7.4 and 4.7.5 of RFC 822 should be made.
In addition, this document proposes a manual C/R method that interworks
with existing mail systems and clients.
Its more like guidelines then a method. We cannot enforce implementation
details.
Introduction
This document identifies a MIME experimental content-type that may be used
by a message as well as a user interaction method for authenticating
sender identity and determining whether a sender originated a message to a
recipient.
Same as above - we need to define more precisely - are we using a MIME
type, custom headers, etc. And we are not giving a method, just suggesting
some guidelines. Do we authenticate or determine sender - we need a better
definition here.
A Challenge/Response system can be used to determine whether a sender
exists and whether that sender intended to send a message to a designated
recipient.
We need a more clear view - there are two things being defined in this
document - one is an automated protocol for machines and two - a set of
guidelines for manual systems. An automated protocol will only allow
machines to check is the sender exists, whether he wanted to send a message
or not, is not really for us to decide unless you intend on using the
"X-CM-Recipient:" header field for that purpose. However in that case the
sender's system would have to keep track of all the people he sent mail to
and then check that against the "X-CM-Recipient:" field in the challenged.
I do not know if this should part of the protocol - may be more of an
optional feature.
A C/R system or client software supporting the C/R MIME experimental
content-type values would have the option of automatically responding to
the challenge message or forwarding to the original sender to perform the
action.
What does "forwarding" to original sender mean? That only applies to the
case of an MTA doing handling the C/R, not the user client. We need to make
this paragraph more clear - a system or MTA would have such option, the
client software would either responde automatically or do nothing.
This document identifies the C/R MIME experimental content-type values
for possible automated C/R systems as well as provides guidelines for a
manual user C/R method.
Good, we probably should split the document into two parts -one to
automatic protocol and second for manual guidelines.
Purposes
-Used to dynamically build user whitelists. In some implementations, the
C/R system is used to determine is a sender is real and allow for that
sender to verify that he intended to send a message to the
recipient. Upon responding to the challenge, the sender will then get
added to the user's personal whitelist.
Again - sender being real and sender sending the message are different
goals. We need to make that more clear. And also, "some implementations"? I
am not getting that - aren't we defining guidelines for all implementation.
Rather we should list required features and optional features of the protocol.
-Reduce spam from spoofed senders. In the event that a challenge message
is without an response for an extended period of time,
-Reduce spam from invalid senders. In the event that a challenge message
rejects or bounces via one or more SMTP errors, some C/R implementations
will automatically drop the message.
We should move the implementation details from the purposes section -
things like "what C/R system does in case A", are not a purpose - they are
the solution.
-Not an authentication method for email delivery or security protocol
As mentioned above, we need to clarify this.
Challenge Response Model
The C/R model is based upon an approach whereby a sender sends a message
to a recipient's SMTP server. The recipient's SMTP server either
produces a challenge message or forwards the original message to a
recipient's client system that produces a challenge message. The resulting
challenge message is sent to the original sender.
Perhaps we should check if the original's sender's domain actually exists,
before sending the message? Also, if that happens do we drop the message
automatically?
If the sender's C/R SMTP server supports C/R methods, then the original
sender's SMTP server may automatically respond to the challenge request.
This line bothers me - restricting to SMTP. Who will implement
challenge/response - the incoming SMTP server or system that is actually
storing the mail? The incoming SMTP server might not possess a list of all
the recipients and may not be able to automatically decide if the "
X-CM-Recipient" matches someone that the sender sent mail to (if we are
doing that).
Otherwise, the original sender's server should forward the message to
the original sender. If the original sender's client system supports C/R
methods, then the original sender's client software may automatically
respond to the challenge message. In the event that neither the server
nor client software are C/R compatible, the C/R message should contain
clear instructions to the original sender describing how to appropriately
respond to the challenge request.
Good.
-------------------------------------------------------------
----------------------------------------
| |
| v
v +----------+ +----------+
+------+ | | | | +------+
| User |<-->| | C/R | |<-->| User |
+------+ | Sender- |Commands/Replies| Receiver-| +------+
+------+ |SMTP/HTTP |<-------------->|SMTP/HTTP | +------+
|Client|<-->| | | |<-->|Client|
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
Sender-SMTP Receiver-SMTP
Model for C/R Use
Figure 1
-------------------------------------------------------------
Challenge Message
The Challenge Message should contain both the MIME experimental
content-type values defined herein. The following MIME experimental
content-type values are required for C/R interoperability:
X-CM-Recipient: - This C/R header should identify the original recipient
of the message that is issuing the challenge.
What format, is this in a standard email address format? Then the relevant
section of RFC 822 or 2822 should be referenced here.
X-CM-URI: - This C/R header identifies an authentication string unique to
that sender-recipient pair that ensures that the challenge response is
from the original sender.
What format? Is this simply a URI? or some kind of code? Or implementation
specific? Should we be naming it "URI" if it is not.
If an original sender sends to multiple recipients on the same C/R server,
then the server can issue the challenge message with each X-CM-Recipient
listed with corresponding URIs.
The sender of the C/R message must be a valid sender address. In the
event that a server-based mail system is performing C/R, then the
challenge should be sent with an email address local to that server. If
multiple servers are used, then the Challenge Message can be forwarded to
peer servers if other synchronization mechanisms are not in place.
If client software is performing the C/R, then the challenge should be
sent with an email address local to that email client. If neither the
original sender's server or client software support C/R interoperability,
then the challenge message should contain as well as a message that
clearly instructs the user how to perform a manual challenge
response. Typically, clicking on an embedded HREF or a simple reply-to is
sufficient for the original sender to manually reply.
The reply-to ability MUST BE present - not everyone who has email,
necessarily has HTTP. Also, for the same reason, the challenge message
should not be MIME encoded, or in some form of HTML format - just simple text.
As someone mentioned on the mailing list, there should be an email address
of the recipient's administrator included just in case. That address SHOULD
NOT issue challenges. Perhaps we also need a custom header or use a
standard one defined somewhere like "Errors-To" for this.
Challenge Response
For C/R compatible systems that support the MIME experimental content-type
values, the challenge response mechanism could be automated. The
following MIME experimental content-type values are required for C/R
interoperability:
X-CR-URI: V=X-CM-URI This C/R header is sent to the originating C/R
system to validate that the original sender had sent a message to the
X-CM-Recipient. The X-CM-URI authentication string that was supplied with
the challenge message is sent along with a key "V=" to signify that the
original sender is intending on delivering a message to the recipient.
X-CR-URI: U=X-CM-URI This C/R header is sent to the originating C/R
system to invalidate that the original sender had sent a message to the
X-CM-Recipient. The X-CM-URI authentication string that was supplied with
the challenge message is sent along with a key "U=" to signify that the
original sender did not intend to deliver a message to the recipient.
What's V and U stand for? We need to rethink this a bit - maybe we should
have "X-CR-Challenge" and "X-CR-Response" fields? The sender will add the
response field. Should there be a standard token format? What about
possible support for hashcash type systems via these tokens?
Mail Lists
Proper identification and handling of user subscribed mailing lists is
essential for C/R deployment. While no standard exists for identifying
lists, many common methods include using the following headers:
"sender:",
"X-BeenThere:",
"mailing-list:",
"list-help:",
"list-unsubscribe:",
"precedence: bulk",
"precedence: list",
More research into this is needed, I think some RFCs provide guidelines on
this.
Challenge messages should not be sent to mailing lists.
Why not? If we have an automated protocol and the mailing list supports
C/R, then it should be able to detect the incoming challenge. This is not
so simple, we need more work on this.
Loop avoidance
C/R systems should use a local address on the C/R system or an actual
email address within client software. In either case, the C/R system
should remain stateful in monitoring outstanding Challenge Messages and
should not continue issuing challenge messages when an existing request is
outstanding. Additional methods used for double-bounces and vacation
responders would also be appropriate.
Perhaps using "X-Been-There" header or something like that. This is also
interesting - section 6.2 of RFC 2821:
"6.2 Loop Detection.
Simple counting of the number of "Received:" headers in a message has
proven to be an effective, although rarely optimal, method of
detecting loops in mail systems. SMTP servers using this technique
SHOULD use a large rejection threshold, normally at least 100
Received entries. Whatever mechanisms are used, servers MUST contain
provisions for detecting and stopping trivial loops."
Security
URI length to prevent brute force attacks
Also how to prevent spammers from spoofing an address on the white list. If
the sender checks the "X-CR-Receipient" field against the list of people he
sent email to, that might be avoided.
Privacy
-Data Collection
There are plenty of messages on that in the list. Legal issues must be left
aside, although we may mention them. Like I mentioned perhaps some form of
a checksum should be used, to avoid storing real email addresses in the
database. Also, perhaps the "X-CR-Recipient" header above should be a
checksum (MD5?) instead of the real email address.
References
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, USC/Information Sciences Institute, August 1982.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
These were supplemented by RFCs 2821 and 2822.
[RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message
Encapsulation", RFC 934, Delaware and NMA, January 1985.
What are we getting from RFC-934 or is this is here just in case for the
future?
[RFC-1049] Sirbu, M., "Content-Type Header Field for Internet
Messages", STD 11, RFC 1049, CMU, March 1988.
[RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet
Mail Extensions): Mechanisms for Specifying and Describing the Format
of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.
These was obsoleted by RFC 1521, which in turn was obsoleted by RFC 2045
which I think is current. We should probably reference the most recent one.
Also take a look at the whole MIME series of RFCs: 2045 through 2049 (2047
is not relevant to us, it deals with non-ASCII text,
[RFC-1344] Borenstein, N., "Implications of MIME for Internet
Mail Gateways", RFC 1344, Bellcore, June 1992.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: RE: [Asrg] C/R Framework, (continued)
- RE: [Asrg] C/R Framework, Yakov Shafranovich
- RE: [Asrg] C/R Framework, Eric Dean
- Re: [Asrg] C/R Framework, Yakov Shafranovich
- Re: [Asrg] C/R Framework, Jon Kyme
- Re: [Asrg] C/R Framework, Yakov Shafranovich
- Re: [Asrg] C/R Framework, Jon Kyme
- [Asrg] C/R Interworking Framework, Eric Dean
- Re: [Asrg] C/R Interworking Framework, Yakov Shafranovich
- Re: [Asrg] C/R Framework,
Yakov Shafranovich <=
- Re: [Asrg] C/R Framework, Kee Hinckley
- Re: [Asrg] C/R Framework, Vernon Schryver
- Re: [Asrg] C/R Framework, Kee Hinckley
- RE: [Asrg] C/R - What people say, Vernon Schryver
- Re: [Asrg] C/R - What people say, Dave Crocker
- RE: [Asrg] C/R - What people say, Eric Dean
- RE: [Asrg] C/R - What people say, Vernon Schryver
- RE: [Asrg] C/R - What people say, Yakov Shafranovich
- RE: [Asrg] C/R - What people say, Vernon Schryver
- RE: [Asrg] C/R - What people say, Daniel Feenberg
|
|
|