Having a class/state assertion rather than a
quality assertion makes for a simpler
solution. ...
Doug makes a reasonable case for this extension. Dave,
I think, is less enthusiastic. How do others feel?
... Also, I
think there is an important technical constraint, namely
limitations on what is reasonable to expect of a receiving
SMTP server to perform in real-time, when there is a
potentially large flow of incoming messages.
The affiliation indication offers a means to request
consideration before a filter is applied. I would not expect
this work group to define policies implicit in the
indication, only that the indication be accommodated as a
first step.
Doug, I am not understanding your response.
First, the ability to refer to a specific 'affiliation' does not
strike me as affecting the efficiency of the mechanism, other to
enable the mechanism at all.
Second, my point was about processing within the accreditation
mechanism, rather than being with respect to mechanisms outside
it. So pre-/post-filtering isn't the issue I was raising.
The issue I was raising was on the nature of computations that
must be done. The current DNA proposal essentially provides a
ranking number. The alternative that I am hearing is to supply
some potentially large set of attribute/value pairs and let the
receiving SMTP server wander over them using some unknown
algorithm.
A rating system is of no value for determining disposition of
mail.
And yet, that is what modules in spamassassin, et al, do today.
They return a rating and the calling program does some sort of
running total.
It provides no clear indication when to refuse mail
nor what an 'A' rating versus a 'B' rating means from one
rating system to the next.
It leaves some room for variable behavior by the requesting SMTP
server, yes. But not a lot.
The "state" proposal rather than "rating" was to avoid the
uncertainty of appropriate action.
Rather than avoiding it, it would maximize it. Imagine trying to
check out of the grocery store and having them swipe your card.
What they get back is a long printout that they must then review
and consider. Note that each store will have different criteria,
so that you will never be particularly certain when a purchase
will be approved and when it won't.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker(_at_)(_dot_)(_dot_)(_dot_)
brandenburg.com