Re: [Extra] Spam Reporting?

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 <stephan.bosch@dovecot.fi>
wrote:

> 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:
> >
> > 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?
>
> 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: stephan.bosch@dovecot.fi
>
>
>
> -------------------------------------------------------------------------------------
> 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
>
>
> -------------------------------------------------------------------------------------
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra
>