-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jesse Norell wrote:
> I just messed up an email confirmation (it was spam,
I missed it and
> confirmed it as ham), and was trying to figure out a
way to correct my
> mistake. Overall a little mistake like that now and
then won't matter
> much, but still, it would be a nice feature for a user
(or an admin) to
> be able to browse the queue of confirmed mail and
correct mistakes. Or
> does that sound like more hassle than it's worth?
This has been discussed before, and I think there's even a
feature
request ticket to that effect. In principle it's not that
difficult to
do; it would mainly just involve providing an additional
view in the
GUI, so that in addition to just seeing lists of
"suspected" items,
users could see lists of "confirmed" items as
well, and presumably
change their status the same way.
Something to be aware of, though, is that items that have
been
"confirmed" will only exist as such until the next
time the
process-quarantine script runs, which at most sites should
be once an
hour. If a user makes a mistake right after a
process-quarantine run
takes place, he might have at most an hour to correct his
mistake, but
conversely if he makes his mistake just before the
process-quarantine
script starts up, the item may be gone before he gets a
chance to make
his correction. It's also worth noting that before
process-quarantine
terminates, it checks to see if any new items have been
confirmed since
it started its run, and if it finds any it will process
those as well.
This makes it difficult to predict how much time a user
might have to
correct a mistake. But that might be an acceptable
trade-off for some
sites.
As I recall, however, the people requesting this feature the
first time
around were interested in guarantees that a
"confirmed" item would
remain changeable for some minimum amount of time. Doing
/that/ would
involve modifying the process-quarantine script to prevent
it from
processing items newer than that threshold time.
The snag there is that you don't generally want to delay
learning and
reporting operations too much, since these directly impact
the
performance of your spam filter. If you hold off on
teaching your Bayes
database for, say, 24 hours to give your users a day's grace
period to
correct mistakes, you leave your spam filter vulnerable to
zero-day
exploits in the meantime. Similarly, the reporting
mechanism relies on
timely submissions to be effective, and services like
SpamCop won't
accept reports more than 48 hours old.
In short, it's certainly a plausible and even practical
feature, but
implementing it both flexibly and /properly/ gets
challenging 
- --
Robert LeBlanc <rjl renaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamail
guard.com/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFYAGSGmqOER2NHewRAmL8AJ0QRUsVu9ZAe2bQUz30vW+i1cg1UACg
o8S8
yQCU+N7ta6zkrQKM6u0nJFY=
=oczU
-----END PGP SIGNATURE-----
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users
|