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