Subject: [Extra] Spam reporting via IMAP

From: Bron Gondwana <[email-masked]>
Date: Tue, 29 May 2018 12:27:29 +1000

Is there any interest in reviving this thing?  (found by looking at
an email thread from 5 years ago as I cleaned up pinned conversations
in my email)
http://datatracker.ietf.org/doc/draft-ordogh-spam-reporting-using-imap/
It looks like it might have some IPR issues after a quick internet
search... so maybe we don't want to go down that path...
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 29 May 2018 09:08:02 +0200

On Tuesday 29 May 2018 04:27:29 CEST, Bron Gondwana wrote:
> Is there any interest in reviving this thing?  (found by 
> looking at an email thread from 5 years ago as I cleaned up 
> pinned conversations in my email)

It would be nice to have a flag or special-use mailbox defined such that if 
the client sets that flag or moves a message to that mailbox and the server 
has a webmail UI, then the server carries out the same action as the 
webmail UI's "this is spam" button, whatever that action may be.

> It looks like it might have some IPR issues after a quick 
> internet search... so maybe we don't want to go down that 
> path...

It has extra moving parts, which means extra opportunities for IPR. Sigh.

I'd prefer to have no reporting. Just a capability from the server and a 
unilateral action from the client. Full freedom for the server to act now 
or later, in whatever manner seems suitable.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 29 May 2018 11:19:13 +0300

(Speaking as a participant)

> On 29 May 2018, at 10:08, Arnt Gulbrandsen <[email-masked]> wrote:
> 
>> Is there any interest in reviving this thing?  (found by looking at an email thread from 5 years ago as I cleaned up pinned conversations in my email)
> 
> It would be nice to have a flag or special-use mailbox defined such that if the client sets that flag or moves a message to that mailbox and the server has a webmail UI, then the server carries out the same action as the webmail UI's "this is spam" button, whatever that action may be.

We already have \Junk, I think this is what you are asking for.
>> It looks like it might have some IPR issues after a quick internet search... so maybe we don't want to go down that path...
> 
> I'd prefer to have no reporting. Just a capability from the server and a unilateral action from the client. Full freedom for the server to act now or later, in whatever manner seems suitable.

I tend to agree. There are existing reporting formats, which might already be suitable or close enough.
But it would be good to have a short document describing how the overall system should behave, listing some implementation options.

---

From: Michael Slusarz <[email-masked]>
Date: Wed, 30 May 2018 13:03:12 -0600 (MDT)

> On May 29, 2018 at 2:19 AM Alexey Melnikov <[email-masked]> wrote:

[snip]

> > On 29 May 2018, at 10:08, Arnt Gulbrandsen <[email-masked]> wrote:

[snip]

> But it would be good to have a short document describing how the overall system should behave, listing some implementation options.

What about a simpler system/definition that simply informs a client (via CAPABILITY?) that messages moved into \Junk folder(s) by explicit user action will be reported as Spam and messages moved out will be reported as not spam?

That gives a hint to the client that they do not need to do any re-classification themselves, and leaves the details of the reporting mechanism entirely up to the server.

michael

---

From: Michael Peddemors <[email-masked]>
Date: Wed, 30 May 2018 12:54:45 -0700

> That gives a hint to the client that they do not need to do any re-classification themselves, and leaves the details of the reporting mechanism entirely up to the server.

Given all the incorrect 'feedback' reports we see, where end users 
incorrectly use the 'This is spam' buttons, instead of delete, or the 
end user who thinks they are training what kind of email they like, say 
from an advertisors mailing list, hard to support any automatic 
'response' mechanism, but in context, the end users generally intent is 
providing an indication about how they want future emails from the 
sender treated.. eg 'Allow Sender' or 'Block Sender', depending on the 
IMAP move from the 'Junk/Spam' folder to the inbox, and vice versa.

It might be 'handy' that a structured way for that action to be reported 
to a backend service, but afraid that will result in a continual 'ask' 
to pass more information through.

This seems to be really something that should be dealt with in the 
actual IMAP processor, rather than a a client/server interaction

You would think that this is an administrative situation.

What 'might' be in order, is a standardized mechanism for IMAP server 
implementations to be able to send a notice to a 'service', which 
includes a reference to the actual message it self, and the action 
performed..

eg...

On Move, if destination is Inbox and Source is folder with Junk 
desigation, do callout(SPAM_TO_INBOX, msgid)..

vice versa..
             do callout(INBOX_TO_SPAM, msgid)..

Get the community to write a standardized service model, which can 
listen for events, and then handle in a method best suited..

Service reads the msgid if it exists, plus the flag, and processes the 
actual email as it sees fit..

(Changing Headers, Contents, adding to personal blacklist, whitelist, or 
passing to a baysein analyzer, OR sending a 'report')

Is there ANY reason to make the email client specifically send a flag 
that says it is okay to make this classification?

Also, not to be the one mentions it *cough* GDPR, reporting by an end 
user, is there going to be privacy issues that an end user would not 
realize, eg the sender information is being possibly sent/shared to 
third parties with their knowledge?

What about WHAT information is 'reported'.

Personally, thinking you are opening a can of worms on this one, when we 
can already effectively do what you are describing, in IMAP code itself..

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 31 May 2018 18:53:36 +0200

That is what I too meant to suggest.

Except that I do not really care 
whether it the junk mailbox or a flag. Either way is fine.

Arnt