Subject: Re: [Extra] Fwd: Personnel change for extra WG

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 02 Apr 2019 22:09:59 -0400

On Sun, Mar 31, 2019, at 18:58, Arnt Gulbrandsen wrote:
> On Friday 29 March 2019 19:44:53 CET, Bron Gondwana wrote:
> > In this particular case, there's a pretty good piece of prior 
> > art for the name in RFC5232, plus multiple mentions online.
> 
> Oh, that was easy to misunderstand, wasn't it. Sorry. I didn't mean to say 
> that this particular flag was a bad candidate for standardisation. Rather 
> that we already have two many piecemeal standardisations. If there's 
> another RFC, it should make some attempt to cover most of the flags that 
> ought to be standardised at this point in time.

Yeah, I was more tempted to just do an IANA registration for it.

> > That sounds reasonable. I'd be happy to help with a document 
> > like that, or find someone else at FastMail who might want their 
> > name on an RFC in exchange for doing the work :)
> 
> I can edit, iff two big providers will produce flag lists. Alone or with a 
> co-editor.
> 
> I like the way Neil has used github.

I can do one for FastMail. Anyone from one of the other providers here able to get such a list?

There's a handful of flags which FastMail use internally which may or may not have any interest ourside, so I'll account those separately.

Bron.

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

---

From: Michael Slusarz <[email-masked]>
Date: Wed, 3 Apr 2019 15:11:56 -0600 (MDT)

> On April 2, 2019 at 8:09 PM Bron Gondwana <[email-masked]> wrote:
> 
In Dovecot, we recently introduced an option to do server-side attachment detection which sets either "$HasAttachment" or "$HasNoAttachment" for each message processed.

Jeff already did most of the legwork on standardization text here:

https://mailarchive.ietf.org/arch/msg/imapext/MVE5eNHOaNIVGUvN1RKtBL8b278

michael

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 03 Apr 2019 17:16:48 -0400

> https://mailarchive.ietf.org/arch/msg/imapext/MVE5eNHOaNIVGUvN1RKtBL8b278

We do the same in FastMail and ship an implementation with open-source Cyrus as part of the annotator. It's also used by the JMAP code to populate the JMAP data.

We don't use $HasNoAttachment any more though, we just set a flag to say "the server did the processing". It would be easy to switch to a more standard processing for new messages, or even go back and re-process existing messages.

Bron.

---

From: Michael Slusarz <[email-masked]>
Date: Wed, 3 Apr 2019 15:49:09 -0600 (MDT)

> On March 28, 2019 at 10:11 AM Bron Gondwana <[email-masked]> wrote:
> 
>     Regarding the IMAP flags, it sounds like you are asking for the $JunkRecorded flag to be standardised, as a keyword which is only set on user action?
> 
Similar keywords were part of the IMAP keyword registry draft (eventually RFC 5788), before it was taken out:

https://tools.ietf.org/rfcdiff?url2=draft-melnikov-imap-keywords-04.txt

Maybe Alexey can comment on the reasoning.

(I'll note that $AutoJunk, along with $NoJunk, made it into some RFC 4551/5162/7162 examples...)

For our customers, the much more interesting question is a method to inform mail clients *how* to report messages as Junk (or Not Junk).  RFC 6154 is as close as there is to a standard, with its "\Junk" label, but it doesn't explicitly provide details on whether messages moved to the \Junk mailbox, (or moved out of it) are definitively reported to an AV/AS provider.

A SPECIAL-USE label of something like "\JunkReporting", with an explicit definition that messages moved into this mailbox by user action are reported as Junk and messages moved out of this mailbox by user action are reported as Not Junk, would be tremendously useful.

michael

---

From: Michael Peddemors <[email-masked]>
Date: Wed, 3 Apr 2019 16:40:41 -0700

On 2019-04-03 2:49 p.m., Michael Slusarz wrote:
>> Regarding the IMAP flags, it sounds like you are asking for the 
>> $JunkRecorded flag to be standardised, as a keyword which is only set 
>> on user action?
> Similar keywords were part of the IMAP keyword registry draft 
> (eventually RFC 5788), before it was taken out:
> 
> For our customers, the much more interesting question is a method to 
> inform mail clients *how* to report messages as Junk (or Not Junk).  RFC 
> 6154 is as close as there is to a standard, with its "\Junk" label, but 
> it doesn't explicitly provide details on whether messages moved to the 
> \Junk mailbox, (or moved out of it) are definitively reported to an 
> AV/AS provider.
> 
> A SPECIAL-USE label of something like "\JunkReporting", with an explicit 
> definition that messages moved into this mailbox by user action are 
> reported as Junk and messages moved out of this mailbox by user action 
> are reported as Not Junk, would be tremendously useful.
> 
> michael

We would support this idea, but want to of course mention, that we have 
to work with email client providers who still want their own use of a 
flag, eg for training etc.. that the client would be responsible for 
setting both flags, instead of just mucking with the \JunkReporting 
flag.. or using it for purposes other than what it is intended.

Of course, it would be nice to define from an IMAP side, a 'hook' 
mechanism, so that on detection of the change in that flag, a server 
defined action could be called.

And should marking a message with that flag, mean that IMAP should move 
it to the special use junk folder?  Or if it is in the junk folder, 
should IMAP move the message to inbox?

We would of course like to see a 'hook' mechanism, that can be used so 
we can also use that information for adding to the users 
blacklist/whitelist natively via IMAP, instead of only through our 
webmail implementations, no matter what email client the end user is using.

-- 
"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: "Neil Jenkins" <[email-masked]>
Date: Wed, 03 Apr 2019 19:52:16 -0400

At FastMail, we plan to simply add hooks on the IMAP server side so if an email is moved to the Spam folder it is learned as spam, and if moved out of the spam folder (except to trash) it is learned as non-spam. Also if an email is moved to the Archive folder it would be learned as non-spam.

Client-side filtering seems to be universally garbage from what we've seen with customer support tickets. I don't know we need a flag to indicate to clients that the server will learn based on folder movement, as hopefully most clients already move messages in/out of the spam folder when you report spam/not-spam from a client and so this will Just Work™️.

Neil.

---

From: Michael Peddemors <[email-masked]>
Date: Wed, 3 Apr 2019 18:12:55 -0700

For us, that is one option, so right now we are looking at all the 
arguments, however it does seem people like the big button 'This is 
Junk' more, they won't bother 'training', and don't really understand 
the concept.  Training is something techies understand, but not the 
average user.  They would rather click 'delete' than remember to move it 
to junk, IMHO..

So, it is about standardizing how/what should happen when a person 
clicks the big button.. We 'could' use that to trigger a move to Junk, 
which would trigger other things.. or we can use flags.

Our concern, is that things other than user interaction could trigger a 
MOVE, eg an email clients own internal spam detection methods.. which is 
not what we want to know, we want to know when the 'human' makes that 
decision.

Make sense?

On 2019-04-03 4:52 p.m., Neil Jenkins wrote:
> At FastMail, we plan to simply add hooks on the IMAP server side so if 
> an email is moved to the Spam folder it is learned as spam, and if moved 
> out of the spam folder (except to trash) it is learned as non-spam. Also 
> if an email is moved to the Archive folder it would be learned as non-spam.
> 
> Client-side filtering seems to be universally garbage from what we've 
> seen with customer support tickets. I don't know we need a flag to 
> indicate to clients that the server will learn based on folder movement, 
> as hopefully most clients already move messages in/out of the spam 
> folder when you report spam/not-spam from a client and so this will Just 
> Work™️.
> 
> Neil.
> 
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
>