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

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 27 Mar 2019 14:09:46 -0400

Thanks Alexey for your work as our AD, and welcome Barry!

Regards,

Bron.

----- Original message -----
From: IETF Secretariat <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Personnel change for extra WG
Date: Thursday, March 28, 2019 05:06

Shepherding AD added: Barry Leiba <[email-masked]>
Shepherding AD deleted: Alexey Melnikov <[email-masked]>

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

---

From: Michael Peddemors <[email-masked]>
Date: Thu, 28 Mar 2019 08:55:27 -0700

Ditto .. Thanks Alexey...

PS, can we get a bit of a review posted to the list to what was covered
at IETF by the working group?

And would like a discussion about anything that can be done to
standardize the use of reserved IMAP flags, or other methods via IMAP
that represent a definitive statement that the 'user' decided a message
was 'Junk' or 'Spam', rather than an automated system, say a spam
detection engine having set the flag.

Worth a conversation?

On 2019-03-27 11:09 a.m., Bron Gondwana wrote:
> To: [email-masked], [email-masked],
> [email-masked], [email-masked]
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
> 

-- 
"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: "Bron Gondwana" <[email-masked]>
Date: Thu, 28 Mar 2019 12:11:24 -0400

Thanks Michael,

I have notes - I just haven't had a chance to write them up yet. I'll post minutes for each session to the datatracker as well as a summary to the list.

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?

Cheers,

Bron.

---

From: Michael Peddemors <[email-masked]>
Date: Thu, 28 Mar 2019 15:33:58 -0700

On 2019-03-28 9:11 a.m., Bron Gondwana wrote:
> Thanks Michael,
> 
> I have notes - I just haven't had a chance to write them up yet.  I'll
> post minutes for each session to the datatracker as well as a summary to
> the list.

Thanks, appreciate that, I know you were kind enough to do this last year.

> 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?

Well, yeah.. Especially since email clients can set it automagically via
their own internal spam filtering for instance, it needs to be clear
when a 'user' explicitly makes an opinion on the content.

This would allow servers to use that change to for instance, do a
mailbox move to the Junk folder, or use it for a better input into
internal training systems etc..

And of course the idea that email clients can also set their OWN idea of
what flag means Junk.. Would be nice to see a universal flag that
effectively states "User Deems this to be Spam" or "User Deems this to
be Not Spam" in every IMAP implementation.  Would make it so a more
standardized method that every email client can implement, to have that
'Allow Sender' or 'Block Sender' implementation that works every where.

Dont' need several email clients all with their own machanism stepping
on each other, (eg they can use client specific flags) but all clients
and servers should respect human decisions.

Havent' seen anything new in RFC's on this subject for a while.. might
even be something to consider for Rev2?

Or does someone have a better idea than using flags?  Should be still
over IMAP

FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]

0 $NotJunk
1 unknown-1
2 unknown-2
3 unknown-3
4 $Junk
5 unknown-5
6 $cl_0
7 $Forwarded
8 Junk
9 NonJunk
10 $MDNSent
11 MMTicketed
12 $label1
13 $label4
14 $label2

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 29 Mar 2019 12:09:50 +0100

On Thursday 28 March 2019 17:11:24 CET, Bron Gondwana wrote:
> $JunkRecorded flag to be standardised, as a keyword which is 
> only set on user action?

Please don't define another small collection of flags.

If anything, then please a mostly-complete registration of the flags that 
are currently in use. Like 5530, which was written in three steps: a) 
surveying b) organising the results to avoid duplications c) defining each 
item.

In this case, getting the flags that are set on gmail and fastmail should 
be enough, ordered by the number of distinct users who've set each flag, 
with a cutoff after the first 50-100. Anything that's used enough to be a 
candidate for interop/standardisation should show up in one of the two 
lists.

Arnt

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 29 Mar 2019 14:44:53 -0400

> Please don't define another small collection of flags.

In this particular case, there's a pretty good piece of prior art for the name in RFC5232, plus multiple mentions online.

The oldest mention in my personal mail archive is:

* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen NotJunk 
Junk JunkRecorded $NotJunk $Junk $Forwarded \*)]

In an email to the Cyrus IMAPd mailing list in 2006 from somebody at columbia.edu. Of course clients are setting both $Junk and Junk because some systems use one and some use the other! Very annoying.

> surveying b) organising the results to avoid duplications c) defining each 

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 :)

> candidate for interop/standardisation should show up in one of the two 

Yep. I'd want to be a very careful to filter for anything obviously personal, but if it's used by more than 100 users who aren't related then it shouldn't be anything private! And they would make good candidates for optimising search on too.

Bron.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 31 Mar 2019 09:58:04 +0200

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.

...

> 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.

Arnt