[Asrg] RE: C/R Framework

["Eric Dean" <eric@purespeed.com>]

> >
> >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?

It can be argued that we do both with C/R.  It's not a strong authentication
but an authentication nonetheless.

> 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?

I used what we have in our taxonomy.  If you have a more representive word,
do tell.

> 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."

Good to keep in mind


> 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.

This is an excellent point and one that requires more research.  After going
through the different RFCs, I was leaning towards 1894 as C/R most closely
resembles Delivery Status...and really doesn't resemble that much at all.
It was just the closest thing I could come up with..so I just took a shot in
the dark...this protocol specific value is completely subject to revision
and is most likely wrong.


> 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.

Yes, thanks for keeping me honest.

>
> Its more like guidelines then a method. We cannot enforce implementation
> details.

Edit made

>
>
> 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.

Yes, I distinctly believe we should avoid discussing methods or anything
implementation specific.  A guideline and protocol set is my intent.

> >   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.

If a C/R mail system (or client) maintained the state of all outgoing mail
then it would know if a sender really sent the message.  Intent is a bad
word..agreed...personalizes it.

> 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.

Definitely should be part of the protocol but open to implementation.
Compliance is always an option.

> >  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.

Yes, much needs to be made clearer

>
> 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.

ok
>
> 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?

Many mail systems do this today.  There are all sorts of RFC checks..we need
not focus there.

>
> >   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).

Yes, the incoming MX server will issue the challenge message which will be
sent in return to the sender.  The sender's MX server can then issue the
challenge response.  How would a sender's MX server know of outgoing mail
(especially is SMTP gateway and MX are split)?  That's not our problem.
Vendors would need to maintain state in the way they do for other systems.
I'm not trying to be hand-wavy here but rather just trying to set forth the
minimum mandatory criteria without restricting implementations.


> >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.

ok

> >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.

URI is probably not the best name..and I don't care about the format...it
should just be long and unguessable.  In practice, many people encode all
sorts of things in their URI..so we shouldn't restrcit

> >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.

In practice, most people use multipart messages.  I'm not sure we want to
restrict whether someone has to be able to respond to a challenge via HTTP
or SMTP.  I'm just saying the process should be "clear and descriptive".
I'm not trying to build a product but rather establish guidelines

> >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?

I changed it to V for valid and I for invalid.  This msot certainly will
change to something more appropriate..just tried to think of something...in
fact, the state should move to the header.

> We need to rethink this a bit - maybe we should
> have "X-CR-Challenge" and "X-CR-Response" fields?

That'll work too.



> >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.

Some mailing lists post with the original sender.  Therefore, everyone tha
tposts gets hit with C/R messages.

> >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."

Excellent

>
> >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.

Yes


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg