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

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

>
> Out of these headers, this one caught my eye:
>
>   "CRI-Sender-Exempt: identifies that the sender desires to not
>    receive a CRI message. i.e. mailing list"
>
> I'm glad you've included support for mailing lists. I'd like to
> know how you envisage this being used in practice. In section 4.2
> you state that:

Most CR systems support a variety of mailing list identification methods
that have been discussed in prior threads.  For example, sender header

>
>   "Mailing lists may include CRI-Sender-Exempt headers to
>    indicate that challenge messages should not be posted to
>    the mailing list..."
>
> What will be the content of such a header?

Good question...it could be blank..like an HTTP no-cache header..or maybe
have some content.

It should probably identify the mailing list i.e.

CRI-Sender-Exempt: [e-mail]

That way the recipient could whitelist the header for now and always.

> Is it just a flag
> such as "CRI-Sender-Exempt: 1"? If so, what would stop a
> spammer from adding such headers to their messages?

Nothing.  However, a well-implemented CR system should simply suppress a
challenge message to the sender...but should probably not forward the
message as a trusted source unless the recipient whitelists.

I'm not trying to dictate how a CR system should be designed..but am trying
to provide a basic set of interoperability procotol messages to automate
interaction

> Is it true that a spammer who used such headers simply wouldn't
> be sent a challenge message?

Possibly..it's probably not a must...but is the intention

> If so I guess they wouldn't have the
> opportunity to answer a challenge and thus get themselves
> permission to send to the receiver. So maybe it's not in their
> interests to try and use such a header.

That's what I'm thinking

> The need to rewrite mailing list software to generate such headers
> is potentially more of an issue. Supposing I decided to use CRI
> yet subscribed to some mailing lists which didn't generate such
> headers.

Yes, however, many CR systems today identify lists.  Also, mailing lists
would eventually add the header..it's not necessary day 1.  There are other
uses...a CR system should also add the header to it's CR
messages...ecommerce receipts too...

> How could I ensure such messages got through?

I don't believe you can.

> My other "first reaction" to the proposal is that the SMTP idea is
> interesting although the use of a 4xx temporary failure code for a
> challenge will of course result in non-compliant sender MTAs
> retrying and repeatedly failing. Of course in the end they'll
> give up and then will the sender's original message bounce back?

I'll let Yakov reply

> I'm interested here in the interoperability issues between MTAs
> which support CRI and those which don't. Some more discussion in
> that area would be helpful.

Well..the MIME headers should be transparent...then you still have to write
a clear email message explaining what to do.

>


_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg