Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing

[Ned Freed <[e-mail]>]

> Ned Freed wrote:

> >> I have no desire to argue against my own proposal! sorry if I
> >> misunderstood the tenor of some comments to this suggestion.
> >
> >> The original posting asked about two things
> >
> >> 1) spam/ham
> >
> >> 2) white/black
> >
> >> so far, people seem to be focussing on 1). I acknowledge problems with
> >> 1), I appreciate that people are trying to address 1) as a possibility.
> >
> >> I asked about 2). I asked you if, ignoring 1), it was possible or
> >> plausible to send white/black information about sender, if 1) was hard
> >> or intractable.
> >
> > Of course it's possible, but this has no business being in IMAP. IMAP
> > is a
> > message access protocol, not an address handling protocol. It is also
> > already
> > quite complex, and extending its function to include what amountss to a
> > specialized address book capability is a really bad idea IMO.
> >
> > In fact a pretty good case can be made that it's inappropriate to use
> > IMAP for spam/ham classification, but at the spam/ham classification is
> > intrinsicly tied to messages in the store. The same cannot be said for
> > address white and blacklisting.

> +1

> >> Does that make more sense? I do realize white/black listing is a
> >> different PROBLEM to spam/ham marking, but neither of them currently
> >> have support directly in imap, and I imagine both of them would use
> >> IMAP extensions to pass information client-server.
> >
> > The place where I'd like to see white and black listing done is in
> > CARDDAV, not
> > IMAP.

> Or LDAP :-).

That's actually how we do it now. We're hoping to move to CARDDAV in the
future.

> There is also a Sieve extension for making use of whitelists/blacklists
> during mail delivery. See draft-melnikov-sieve-external-lists-02.txt.
> It can work with CARDDAV, LDAP and other things.

Interestingly, this extension in its current form is not compatible with
at least one of the proposals that was made here. The issue is one I've
raised before - the fact that :list is separate argument and not a match type.

Where there is clearly some utility in being able to say stuff along the
lines of:

    header :contains :list "subject" "tag:dirty-word-list"

The problem is that in order for this to work the list has to be enumerable.
Not all lists are enumerable, and even some that are are so large even though 
oyu can enumerate them in theory you can't afford to do so in practice.

One use case where this matters is when the list is a set of hashed values. The
way you find if something is "on the list" is to hash it and see if that value
appears. And even if the input string is short enough that you can enumerate
all the unique substrings, how about :matches and :regex? Good luck with
those.

Hashed lists have in fact been proposed in the present discussion as a means of
avoiding giving your address whitelist to the mail server. I happen not to
think this is a useful thing to do for a variety of reasons, mostly having to
do with address canonicalization (or lack thereof), but there are other
use cases where hashed lists make more sense.

So, although it reduces functionality, I believe :list should be a match type
and the underlying comparison type that's done should be a property of the list
itself.

				Ned