On Wed, Apr 09, 2003 at 11:49:45PM -0700, J C Lawrence wrote:
People are free to run C/R systems.
Which doesn't answer the question.
To be more specific, since these are endpoint systems, they can be run
without much need for standardizaton on the other end. One can imagine
laying down some standards for other ends that would like to do something
special but it's not a big pressing demand. Normally we would see some
established implementations and look to standardize there. If an MUA
did challenge response, it could have other copies of the MUA recognize
and do "something" with the challenge, though of course autoresponse is not
normally the course on turing test challenges.
b) Never challenge a reply to an E-mail you sent, even if you sent it
from elsewhere and a different account which aliases over to the real
mailbox.
There's some ambiguity there. Consider:
Bubba email Bruce and Bruce replies (the simple case).
That should always work or you have a broken system. That includes however,
that bubba mails bruce's alias, and the real bruce replies. Ie. simply
whitelisting bruce's alias is not enough.
Bubba emails a list and several list members reply.
This is under the "it would sure be nice" category, but in general not as
much of a mandatory. Most designs in this area effectively let replies come
in to a public message for some period of time, then challenge it after that
amount of time. You run the risk of spammers harvesting mailing lists
and replying to every message with some spam during the window, making it
look like a reply. Though that bridge should be crossed when we come to it.
For private lists, this is more doable, and more desireable.
Bubba emails Boffo, Boffo forwards to Bernie, and Bernie replies.
I presume you mean not forward but what some mailers call a bounce, where
it looks like the mail came from Boffo. This is similar to the above.
Nice to do. Easiest solution -- all private mail comes from an unfiltered
address.
Which means:
1) There has to be some way that transient consent it copied to the
receiver
Not really, because as I said, you don't need to use a filtered address
in mail that's not going to be exposed to the public.
2) That there needs to be some form of copy control on the consent
token which is copied by the receiver (so that it can't be freely used
as a get-spam-in-free token.
As long as this is rare, you just turn off such addresses.
While I agree as a user, that seems like an implementation choice, not a
question for a standards definition. Certainly if we go so far as to
arrive at or give the nod to a reference implementation it wouldn't hurt
if this were present...
None of this is standards stuff, actually. Just best practices. And
not causing mail to vanish without a trace is good practices.
What about subscribing to a list? I'm tending to think that the
subscription negotiation for a list should also establish the
appropriate consent tokens (and perhaps filtering defaults?), and if
dated consent tokens are supported, a means for refreshing consent
This comes back to the question of whether this is about consent or not.
You want to rescind consent to somebody or mail containing some token?
Just program your mailer to reject their mail. The rest of the world
does not need your consent to mail you, at least not for person to person
mail. This is a hard truth that some people in the anti-spam community
don't wish to embrace, unfortunately.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg