[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing
hang on.
The MS has the message. It presumably has some held state of it,
specific to its implementation.
Actually, that's highly unlikely. There is some amounts of state IMAP requires
that's associated with the message - flags/keywords, annotations, some remnants
of the envelope. But beyond that there's little point in keeping a bunch of
implementation-specific state. Why? Because there's no way to expose such state
through the IMAP protocol. So when messages are FETCHed the state stays behind.
And more to the point, when a client moves a message, implementation-specific
state tends to get lost, because the client doesn't know how to access it in
order to move it.
The result is that in most csaes IMAP servers don't store much beyond the
things the standard requires them to store. The differences between servers lie
in how the standard stuff is stored and to what extent metainformation, like
body structured, is cached instead of being recomputed.
I don't want deep knowledge of that
model, I really just want to be able to override it with my explicit
knowledge.
I simply want to pass the toggle:
If you class this as spam, please class as ham
or
if you class this as ham, please class as spam
This is exactly what we're trying to accomplish. The question is what mechanism
to use to do it.
what it means, semantically, is of course MS specific. I don't care
how its held, or what the effect on the weighting is, in the re-class
as spam. In the class as ham, I care quite a lot that its sender is
removed from hard blocks of course.
I'm afraid you cannot count on that happening either. The problem is that
such blocks are often outside the control of the service provider to change.
In many cases the provider has subscribed to some sort of spam filtering
service.
Whitelisting may be an alternative in such cases, but you have to be careful
lest the amount of whitelisting information grow to the point where it is
unmanageable. (I've seen this happen.)
Yes, I see that moving this state between servers requires the entire
message flow. But, if we forget that for now, and just consider that I
have some mail in my local client cache, which I feel is now worthy of
a state change, why do I have to pass full-state baysian model
information?
You appear to be arguing against a straw man of your own construction here,
because AFAIK nobody has suggested such a thing.
I just want to tell an MS "change your own flags to match
my flags" in the hard sense: yes-or-no, not some qualitative weighting
model.
The only "weight" people have mentioned in any of this is storing a spam score
rather than a yes/no indicator. I've already responded that while there is a
place for such information in spam handling, it makes no sense in this
particular context.
How it acts, is up to it. I don't see why I need a complex flag
model to say what I think, as the consumer of the mail.
Again, you appear to be arguing against a proposal nobody has made. (Perhaps
some proposal was made in an earlier thread not on the imapext list.) I'll also
point out that flags are binary by definition in IMAP - you cannot implement
even a single-valued spam score using them. If you want to store a reviseable
per-message score, you have no choice but to use message-level annotations.
If I moved off SPAM/HAM to white/black on sender, would that be easier
for you to consider?
Whitelisting and blacklisting is actually a fairly different problem.
Ned