ietf-asrg
[Top] [All Lists]

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>