On Tue, 30 Jan 2007, Stuart D. Gathman wrote:
The smaller the bin, the less effective the reputation system.
Well yes... But the opposite is also true - if you have mixup of
reputation data from when you see say aol.com in From header and
in EHLO data and somewhere else, you may well be polluting for
user who asks about reputation when he sees aol.com in EHLO.
The above list was fine tuned over 6 months to make the bins as
big as possible, while avoiding "unfair" comparisons (like
aol.com:SPF to aol.com:neutral) to minimize false rejections.
Good.
I specifically do *not* want to see all combinations of possible
authentication scopes, methods, and results.
Excellent.
I am looking for a validated ID. I'll take several kinds, but I need
one to track your reputation.
Correct, you want to see at least one id (ok, you don't necessarily want
to but you need it to actually do anything about reputation...).
Now the most interesting issues are when you have 2 or more ids and you
now need combine the data to produce one "answer" if its likely spam or
likely not-spam. There it may actually be of interest to do bayesean
filtering on data generated from these various checks (I've been working
on that lately on my spare time).
It would be reasonable to choose a qualifier naming scheme for the
chosen IDs that I accept that reflects your concern, if you think it
would make the system more attractive.
Attractive to who? Its fine if you choose very short ids for your own
internal debugging & logs, but if you add it as trace data into email
header then I think full name is better (but then again you may not
want to fill up the field with too much info either).
See below of what I (personally) would have preferred when trying
to think of what happened and analyzing the output
Old nam Trace Name
SPF | (mfrom) | SPF | (Pass) | MFROM/SPF:PASS
GUESS | (mfrom) | SPF-guess | (Pass) | MFROM/GUESS[SPF]:PASS
HELO | helo | (SPF/SPF-guess) | (Pass) | HELO/GUESS[SPF]:PASS
neutral | (mfrom) | (SPF) | Neutral | MFROM/SPF:NEUTRAL
softfail | (mfrom) | (SPF) | SoftFail | MFROM/SPF:SOFTFAIL
IP | ip-addr | (valid rDNS) | (match) | IP/RDNS:PASS
Also for HELO name you can add situation where the EHLO name matches
ip address (I guess you actually have it and just call it SPF-guess),
but I would actually consider it to be separate validation protocol
i.e. HELO/DNS:PASS. Of some interest would be when same identity
is confirmed (and even more interesting when its not) by more then
one protocol (for EHLO potentially SPF and CSV for example).
Rather cumbersome. I think the table belongs in the documentation,
not encoded in the qualifier. (Thanks for the table.)
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735