From: "Eric Dean" <eric(_at_)purespeed(_dot_)com>
Trying to come up with the right place to shim in the CRI control headers.
It seems we can do the following:
1) Use SMTP headers: beyond the deployment issues, CRI is not limited to the
envelope and there are often many mail relays in the path that could remove
such headers. We do not want to restrict mail clients from implementing
CRI.
2) Use RFC 2822 headers: we could possibly introduce a new field altogether
or use an optional field as spec'd in 3.6.8
3) Use MIME headers (registered or private): though CRI has little relavancy
with MIME. Private headers can not become a standard. There isn't such a
limitation on 2822 3.6.8
Thoughts?
If the goal is to get a CRI protocol defined and deployed to stop some
spam, why do you care about the fact that private headers (presumably
X-whatever) cannot become a standard?
I thought you guys were clever to use MIME for more than one reason.
Pushing a new official RFC 2822 header (other than an ad hoc X-whatever)
through the IETF would take a year or more and you might fail. That
you are sure challenge/response systems will be effective against spam
will be a weak response to Last Call criticisms. However, I've the
impression that MIME headers don't have that bureuacratic problem to
the same degree. That should be checked.
MIME in either or both directions might allow you to pass more data
than a header. For example, do you have cryptographic authenticators
of either the challenge or the response? What about an authenticator
of the original sender for the receipient/challenger's whitelist for
subsequent mail?
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg