Subject: Re: [Asrg] Adding a spam button to MUAs

From: Franck Martin <[email-masked]>
Date: Thu, 17 Dec 2009 07:34:49 +1200 (FJT)

Yes this is my point, people use the SPAM button to mean "I don't want to see that message again" and you know what? It works!

See this survey: http://www.scribd.com/doc/16345924/SPAM-What-Consumers-Really-Think There are few others around...

Should we relabel the button? I think it is too late, we have to take into account this current meaning.

Now I was rethinking about this SPAM button in the MUA. I don't think it is a problem for this group but it should be brought to IETF mail WG. Seriously all (or nearly all) the Mail clients that I know of have a spam/junk button. The problem is how to communicate this information to the IMAP server?

It seems to me an extension to IMAP needs to be developped, to flag to the server a message as spam or non-spam. We should let the IMAP server decide what it wants to do with it.

Some servers/clients use a special folder to move the junk mail to. Unfortunately, there is no naming convention. Should the IMAP client request where the junk folder is, and then use this information for its junk button? The server could then detect new mail there and run whatever it has to run? It could detect the move of mail between this junk folder and the inbox (both ways for junk/non-junk).

Should the IMAP server, indicate to the client, two email addresses to send junk and non-junk email for classification?

It seems to me, it is an IMAP extension issue. We should not focus on what the server wants to do with this information.

For me the easiest way is to add a capability to IMAP (http://www.iana.org/assignments/imap4-capabilities) this capability would indicate to the client where is the junk folder. Up to the server to detect move commands by the client from and to the junk folder.

PS: there is no convention either on the location of the sent folder, draft folder, contact, calendar, etc... Which obliges the user serious fine tuning when using different clients. This capability could indicate basic folders to the client for automatic set-up.

Franck Martin 
http://www.avonsys.com/ 
http://www.facebook.com/Avonsys 
twitter: FranckMartin Avonsys 

----- Original Message -----
From: "Paul Russell" <[email-masked]>
To: "Anti-Spam Research Group - IRTF" <[email-masked]>
Sent: Thursday, 17 December, 2009 6:08:43 AM GMT +12:00 New Zealand
Subject: Re: [Asrg] Adding a spam button to MUAs

On 12/15/2009 20:50, Steve Atkins wrote:
> On Dec 15, 2009, at 5:48 PM, Rich Kulawiec wrote:
> 
>> I think allowing end users access to such a button is a terrible idea.
>> This is the same population that routinely replies to spam, falls for
>> phishes, and fails to correctly execute rudimentary tasks like unsubscribing
>> from a mailing list or trimming quoted material from replies.  It would
>> be simpler and about as accurate to simply check a random number generator's
>> output for a "spam?/not-spam?" opinion.
> 
> Data from actual reality contradicts your (otherwise plausible) reasoning.
> 

Our "actual reality" includes an AOL feedback loop stream that consists
primarily of:

* spam complaints about personal messages from family members or friends;

* spam complaints about replies to messages initially sent by the user who
  subsequently reported the reply as spam;

* spam complaints about messages posted to COI lists to which the user had
  previously and explicitly subscribed.

None of these messages should have been reported as spam, but they were, and
they outnumber legitimate complaints by a wide margin.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 17 Dec 2009 16:24:18 +0000

--On 17 December 2009 07:34:49 +1200 Franck Martin <[email-masked]> 
wrote:

>
> PS: there is no convention either on the location of the sent folder,
> draft folder, contact, calendar, etc... Which obliges the user serious
> fine tuning when using different clients. This capability could indicate
> basic folders to the client for automatic set-up.
>

There isn't even a convention that you should have different mailboxes for 
any purpose. Gmail broke that, when they decided that tags (mathematically 
"sets") were more useful than mailboxes (mathematically "categories"). 
Mailboxes are logically equivalent to restricting emails to carrying a 
single tag.

As I said earlier in the thread, registration of some new IMAP flags is 
probably a better way to do this. The NAME of a mailbox is language 
dependent, so it should not be standardised. The NAME of a flag need not be 
presented to a user, so it can be standardised. It would also allow richer 
semantics, and on a per-message basis.

Of course, the presentation to the user could be as if the messages were 
all filed in a separate mailbox.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Franck Martin <[email-masked]>
Date: Fri, 18 Dec 2009 08:18:09 +1200 (FJT)

Ian,

My feeling is that this is a feature badly needed now for IMAP. How to implement it? Seems your solution reasonable.

I'm just dealing with a case of different clients storing sent messages in different "Sent" folders. People use different clients because sometimes they use a web interface and sometimes some piece of software.

Franck Martin 
http://www.avonsys.com/

---

From: Ian Eiloart <[email-masked]>
Date: Sun, 20 Dec 2009 12:14:18 +0000

--On 18 December 2009 08:18:09 +1200 Franck Martin <[email-masked]> 
wrote:

> Ian,
>
> My feeling is that this is a feature badly needed now for IMAP. How to
> implement it? Seems your solution reasonable.

I think that what's required is registration of new IMAP flags, and an RFC 
to define their meanings.

>
> I'm just dealing with a case of different clients storing sent messages
> in different "Sent" folders. People use different clients because
> sometimes they use a web interface and sometimes some piece of software.
>
>
> Franck Martin
> http://www.avonsys.com/
> There isn't even a convention that you should have different mailboxes
> for  any purpose. Gmail broke that, when they decided that tags
> (mathematically  "sets") were more useful than mailboxes (mathematically
> "categories").  Mailboxes are logically equivalent to restricting emails
> to carrying a  single tag.
>
> dependent, so it should not be standardised. The NAME of a flag need not
> be  presented to a user, so it can be standardised. It would also allow
> richer  semantics, and on a per-message basis.
>

---

From: Ian Eiloart <[email-masked]>
Date: Sun, 20 Dec 2009 12:18:32 +0000

> implement it? Seems your solution reasonable.

PS, I guess it might be sensible to define an IMAP extension, so that the 
client knows there's some point in setting the flags.