At 10:58 AM 5/15/2003 -0400, Eric Dean wrote:
>
> 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.
Perhaps just mention or reference the relevant documents 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.
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
I would be more comfortable with naming it an "token" not "URI".
> >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
We can keep this as a suggestion - that implementators should have SMTP as
well.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg