RE: [Asrg] 6. Proposals - Challenge/response - CRI

["Eric Dean" <[e-mail]>]

> >
> > CRI-Sender-Exempt: [e-mail]
> >
> > 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg