--On 9 December 2009 00:35:03 -0500 "John R. Levine"
<johnl(_at_)iecc(_dot_)com> wrote:
Most web mail systems have a spam or junk button that lets a user report
unwanted mail to his ISP. The ISP does whatever it does, typically tune
their spam filters, and perhaps send a feedback report if the message is
from someone with whom they have an FBL agreement.
Lots of us don't use web mail. We use POP or IMAP to pick up our mail,
and SUMBIT to send it. How would we add a spam button in our MUAs work?
...
For IMAP
accounts, a simple approach is to have an IMAP spam folder, and move the
message there.
Apple Mail already has a "Junk/Not Junk" ("In/désirable","No
deseado/Conservar", etc) button. It uses it to feed it's internal content
filter. When enabled, the action taken when spam is detected can be (a)
mark the mail as spam (it appears brown in the list) or (b) file into a
Junk mailbox (which can be any mailbox designated for the purpose), or (c)
custom actions which include redirecting (eg to a spamcop address) or
running an AppleScript.
On an IMAP server, it would probably be better to file the message into a
designated junk mailbox, and have some process on the server take whatever
action the service provider thought reasonable. The only new thing required
here is a way of communicating either (i) to the user; which mailbox should
be used as for junk, or (ii) to the server; which mailbox I'm actually
using for junk.
The latter is probably the more principled approach, especially given
language concerns; my server is at a University with a high proportion of
international students! Perhaps some RFC5464 METADATA attached to the
mailbox could be used. It would require a new entry at
<http://www.iana.org/assignments/imap-metadata/imap-metadata.xhtml>
A more flexible approach would be the definition of a new standard IMAP
flag: \Junk or similar. That would permit GMail style monolithic mailboxes,
and even use of multiple mailboxes for junk (cf Twitter's "Block" and
"Report" buttons).
So, the user might see a "junk" mailbox, but the client would need to flag
every message that was filed in there. It might even be sensible to define
a \Notjunk flag for training purposes, and you might want to do something
different with user-designated junk than with automatically filed junk
messages, so that might require an additional flag, say \Userjunk or
\Autojunk in order to make the distinction. IANA don't seem to maintain a
list of flags, so this might require a change to the RFC, or a new
extension.
Any bright ideas? Is there a way to make this work with POP that isn't
an utter kludge?
No ideas here, I'm afraid. This is the sort of thing that stops us offering
POP to users.
R's,
John
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg