On Mon, 2004-10-04 at 20:50, Dave Crocker wrote:
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.
I was attempting to describe a means of indicating an affiliation with a
group ensuring adherence to some level of practice. This group could be
the reputation service or some other entity. The details of this
affiliation would be outside of this work group. As example, there are
some countries what require 'opt-in' for commercial mail. To avoid
being mistaken for a mailer using 'opt-out', make such an assertion
together with the "reputation" information to help ensure the avoidance
of being "filtered." Those creating filtering rules would be less
likely to include the mail in that category when provided some assurance
to the contrary. I suggested it might be good to include a level for
this function based upon a BCP proposal that establishes the
guidelines. This BCP would be outside this work group.
This is only an example, and not a proposal for any actual definitions.
The draft can indicate only 0 is defined to leave the door open.
BCP-LEVEL '0' : No affiliation
BCP-LEVEL '1' : opt-in and audit
BCP-LEVEL '2' : opt-in
BCP-LEVEL '3' : opt-out
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.
The actual entity establishing the assertion is not provided by this
mechanism. Only the level of practices would be provided when there is
an affiliation.
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.
I did not add any additional states to the reputation information nor
does this allow any "contemplation" as levels of ratings will require.
'A' Accept
'B' Temporary Refuse or Filtered Accept
'C' Quantity Limited Accept
'D' Temporary Refuse
'E' Reject
No additional settings and constrained actions.
The actions that could be expected from the currently proposed rating
system would require greater knowledge of the underlying algorithm to
decide what rating would be a suitable choice. The 'state' proposal
makes the expected action explicit and does not require knowledge of the
rating system. This approach also adds a temporary refusal treatment as
a new mechanism. This is something that can be supported, but not
required of each service.
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.
Filters return a rating per message based on many parameters detected
fully understood by the filtering program. You are offering numbers
without any basis however. What does an 'A' versus 'B' mean? What
should be done differently? Does this scheme require a filtering
program for this information to be useful? If so, how are these numbers
derived and how can they be calibrated for these filtering equations? A
rating system is not simple nor obvious.
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.
Is the difference between 'A' and 'B' 3% or 30% more abuse? I would say
there is a fair difference possible. The ratings provide three known
acceptance ratings, so do these evenly divide the full range or at the
first sigma? It is impossible to know if the difference is 3% or 30%
without greater knowledge of the algorithm. What I am proposing does
not require any knowledge. This was your complaint, but it seems to
condemn your approach.
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.
Imagine the clerk swipes your card and sees a 'B'. This does not
directly indicate an action as it does with my proposal. The clerk is
left to ponder what the 'B' means when using a particular scanner. The
clerk also knows the scanners are not consistent which makes matters
worse. All the clerk wants to know is the required action, but a rating
does not offer that information.
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.
You seem to be arguing for my proposal.
-Doug