ietf-asrg
[Top] [All Lists]

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

2003-08-15 13:41:13

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: asrg(_at_)ietf(_dot_)org

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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg