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

Michael Peddemors <michael@linuxmagic.com> Thu, 28 March 2019 22:34 UTC

Return-Path: <michael@linuxmagic.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCBE1203C3 for <extra@ietfa.amsl.com>; Thu, 28 Mar 2019 15:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXMf2B2bGshc for <extra@ietfa.amsl.com>; Thu, 28 Mar 2019 15:34:00 -0700 (PDT)
Received: from be.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 89D42120041 for <extra@ietf.org>; Thu, 28 Mar 2019 15:34:00 -0700 (PDT)
Received: (qmail 1137 invoked from network); 28 Mar 2019 22:33:59 -0000
Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (AES128-SHA encrypted) SMTP (94410594-51a9-11e9-bce4-33aa48ae3ef1); Thu, 28 Mar 2019 15:33:59 -0700
To: extra@ietf.org
References: <49b87029-7cc2-4324-9d97-f7fa2b8762ce@www.fastmail.com> <25ed8a44-6fce-4778-d9cd-d732b7cb91f6@linuxmagic.com> <533a9f07-80c6-4cbc-b7af-fe10ce62580c@www.fastmail.com>
From: Michael Peddemors <michael@linuxmagic.com>
Organization: LinuxMagic Inc.
Message-ID: <65658e34-f95b-e8c0-9340-8b3c9c8c4037@linuxmagic.com>
Date: Thu, 28 Mar 2019 15:33:58 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <533a9f07-80c6-4cbc-b7af-fe10ce62580c@www.fastmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-MagicMail-OS: Linux 3.11 and newer
X-MagicMail-UUID: 94410594-51a9-11e9-bce4-33aa48ae3ef1
X-MagicMail-Authenticated: michael@wizard.ca
X-MagicMail-SourceIP: 104.128.144.8
X-MagicMail-RegexMatch: 0
X-MagicMail-EnvelopeFrom: <michael@linuxmagic.com>
X-Archive: Yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/t9tIQkLu8IXGJMf1Gcjyq15ydxo>
Subject: Re: [Extra] Fwd: Personnel change for extra WG
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2019 22:34:03 -0000

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



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