At 10:34 AM 5/18/2003 -0400, Eric Dean wrote:
> 2. C/R systems need to have a standard way of identifying themselves
> as such. This avoids loops, and it let's us shunt them into an
> appropriate handling queue.
Yes, if a message has the C/R headers..it shouldn't be challenged. Only
challenge messages should use C/R headers. We've discussed the issue
regarding spammers using them...not using them. The other recommendation is
that the system be stateful and not constantly return the challenge
messages. If you send my demo account 20 messages, you get one challenge
back. Now, that's implementation-specific. I would not suggest that a
protocol require a system to be stateful..if mentioned at all. However, I
would recommend that C/R headers result in a suppressed challenge to avoid
loops.
One thing I wanted to mention is that a C/R system that has a white-list of
verified senders, should probably verify the senders again every X months.
> 3. As I've said before--any system that requires you to do something
> other than just reply (e.g. read a graphic) needs to meet
> accessibility standards.
Yes, agreed. And therefore, vendors that do stupid things will not sell
their product and Darwinian nature will run it's course. I'm not sure that
we want to address the body or content of the challenge message..just the
challenge headers. Again, these are just my thoughts and am widely open to
counter-thoughts.
A Turing test may not be able to meet accessibility standards but again are
we seeking to distinguish between man and machine, or verify the email address.
> 4. If you have a web based confirmation system, you should also have
> an email-based one. The fact that I can send you email does not mean
> that I can access your web site. (Think China, think road-warrier,
> think third world.)
Agreed. I'm not trying to specify a web-based authentication method here or
an SMTP-reply one. I agree there should be such methods. I guess, if the
industry is naturally going in a certain direction, I would not intrude on
their liberties. However, if we all want to interwork...which is really
what I am looking to define...an Interworking for C/R Systems...then we
should identify the criteria. Come to think of it, that's ALL I'm
considering. I just to provide an interworking method and not dictate to
vendors how they should build their own systems...the market will figure
that out.
As a result, I will probably rename the draft to a C/R System Interworking
document.
Since the C/R systems operate over SMTP, all parts of it should operate
over SMTP including the replies.
Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg