Subject: [Extra] Spam Reporting?

From: Bron Gondwana <[email-masked]>
Date: Tue, 27 Feb 2018 11:37:59 +1100

Digging through my very old FLAGGED emails to see if there was anything
I should be looking at, this sprung up:
https://datatracker.ietf.org/doc/draft-ordogh-spam-reporting-using-imap/
In a discussion from Alexey following on from my Fosdem report at the
time:
https://www.mail-archive.com/search?l=cyrus-devel%40lists.andrew.cmu.edu&q=subject%3A%22FOSDEM+Report+%5C-+Saturday%22&x=0&y=0
Is there any appetite for reviving discussion of a standard way to
report spam/phishing/whatever from clients such that the server knows
that a user has explicitly made the determination?
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Stephan Bosch <[email-masked]>
Date: Wed, 28 Feb 2018 09:20:35 +0100

Hi Bron,

Op 2/27/2018 om 1:37 AM schreef Bron Gondwana:
> Digging through my very old FLAGGED emails to see if there was
> anything I should be looking at, this sprung up:
>

I haven't yet fully read this draft, but this is definitely useful
functionality to have. For Dovecot, solutions that monitor the spam
folder have been used for years now. This automatically triggers spam
learning activities when a mail is either moved into or moved out of the
spam folder. Historically, this was performed by an external plugin, but
more recently this is done using IMAPSieve. Additionally, using a sieve
language extension, MARF reports (RFC 5965) can be sent:
https://raw.githubusercontent.com/dovecot/pigeonhole/master/doc/rfc/spec-bosch-sieve-report.txt

The Ordogh draft adds a new command instead. I am not sure what I prefer
more. Adding a new command is problematic in that it requires client
support, which some clients will never attain. The problem with the
implicit reports based on folder events is that you're never quite a
100% sure it is what the user intended, and moving lots of messages can
produce problems.

Regards,

-- 
Stephan Bosch
Senior Developer 

Phone: +49 2761 75252 00  Fax: +49 2761 75252 30
Email: [email-masked]

-------------------------------------------------------------------------------------
Open-Xchange AG,  Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein 
Chairman of the Board: Richard Seibt

Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland
Managing Director: Markku Kentta
Chairman of the Board: Timo Sirainen
Board Member: Carsten Dirks

-------------------------------------------------------------------------------------

---

From: Brandon Long <[email-masked]>
Date: Wed, 28 Feb 2018 19:29:06 +0000

We currently have two mechanisms with some amount of usage, the $Junk
keywords (which I guess never made it to an RFC) and the \Junk folder
special-use defined in RFC 6154.

An IMAP server can certainly trigger whatever it needs off of applying the
keyword or having a message moved/copied to the junk folder, so I'm unclear
on the need for an explicit command.

Sure, bulk application of either of these should be interpreted with some
level of skepticism, I know our original implementation had a cut-off for a
max number we'd allow in a single command, and it's had to evolve over time
based on information about the client used and the reputation of the user,
at least in regards to using the spam labeling to enform the larger
anti-spam system, local changes such as personalized blocked sender lists
or personalized learning seem fine even in bulk.  Given the potential for
bad actors, these types of requirements will come up even if you have a
specific command, of course.

Even in the Gmail API, we went with just adding the spam label instead of
having an explicit command.

Brandon

On Wed, Feb 28, 2018 at 12:21 AM Stephan Bosch <[email-masked]>
wrote:

> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
>

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2018 15:46:48 -0500

>> 100% sure it is what the user intended, and moving lots of messages can

Even when a mail program has an explicit SPAM or JUNK button, you
never really know what the user intended.  It might be "this is an
evil phish" or it might be "I subscribed to this legit list but don't
want it any more" or it might just be "there's too much mail in my
inbox so make it go away."

Since we already have a \Junk folder, it seems to me that the way one
puts messages in it is a user interface issue and not one we should
try to solve.

R's,
John

PS: $Junk may not be a standard but it seems to be a favorite example.
See RFCs 5182, 5267, and 5465.

---

From: Robert Mueller <[email-masked]>
Date: Thu, 01 Mar 2018 11:50:42 +1100

> See RFCs 5182, 5267, and 5465.

It is a registered IMAP keyword along with $NotJunk

-----
https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml

Purpose (description):
The user (or a delivery agent on behalf of the user)
may choose to mark a message as definitely
containing junk ($Junk; see also the related keyword
$NotJunk). The $Junk keyword
can be used to mark (and potentially move/delete
messages later), group or hide undesirable messages.
-----

-- 
Rob Mueller
[email-masked]