CRI-Sender-Exempt: asrg(_at_)ietf(_dot_)org
That way the recipient could whitelist the header for now and
always.
This seems like a reasonable suggestion.
I'm not sure what would be reasonable software behaviour when
such a header is seen in an incoming message. To whitelist
automatically based on the presence of such a header would open
the system to abuse by spammers. I suppose well-behaved software
would ask the user whether they want to whitelist the address
and let the user decide.
Yes, whitelisting could be easily abused. The intent is to prevent a
challenge message from being returned...adding a mail list identifier
would be convenient for identifying subsequent messages for whitelisting
per user request.
In general, when a CR-compliant MTA receives an incoming message
which claims to have been challenged and accepted... how can the MTA
at this stage ensure that such headers were not forged?
You have to respond with a corresponding string that is either static or
algorithmic.
I suppose it comes down to which systems have access to the consent
tokens for that specific sender/receiver pair: only the systems which
have access to those tokens can verify if they are valid. This could
be done using a cache scheme such as that raised recently by Danny
Angus:
http://article.gmane.org/gmane.ietf.asrg/5760
We are not trying to be restrictive as to which algorithm to use...but
instead produce a protocol that would accommodate many different
approaches.
Therein lies a major problem for CRI and indeed CR systems in general.
To find a way around the issue, it might be worth thinking about
the possible format of mailing list messages.
We have an archive of such a detailed discussion a few months ago
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg