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

Michael Peddemors <michael@linuxmagic.com> Thu, 04 April 2019 01:12 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 5E2F6120357 for <extra@ietfa.amsl.com>; Wed, 3 Apr 2019 18:12:59 -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 P-tQKcyr9nw3 for <extra@ietfa.amsl.com>; Wed, 3 Apr 2019 18:12:56 -0700 (PDT)
Received: from fe1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 989F11201B1 for <extra@ietf.org>; Wed, 3 Apr 2019 18:12:56 -0700 (PDT)
Received: (qmail 18891 invoked from network); 4 Apr 2019 01:12:55 -0000
Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (AES128-SHA encrypted) SMTP (c6d31c96-5676-11e9-91f4-ab704c62840a); Wed, 03 Apr 2019 18:12:55 -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> <1003410466.3899.1554328149896@appsuite.open-xchange.com> <a2c72491-03f9-b08d-0db0-edea22ec7e4f@linuxmagic.com> <34412433-fa56-490c-860e-4d923ac5e3df@beta.fastmail.com>
From: Michael Peddemors <michael@linuxmagic.com>
Organization: LinuxMagic Inc.
Message-ID: <942d0f1b-f164-a015-9c6f-de94358e9b23@linuxmagic.com>
Date: Wed, 03 Apr 2019 18:12:55 -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: <34412433-fa56-490c-860e-4d923ac5e3df@beta.fastmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-MagicMail-OS: Linux 3.11 and newer
X-MagicMail-UUID: c6d31c96-5676-11e9-91f4-ab704c62840a
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/Q1MvpZvRcP4gsTyZsnEjz4Xigp0>
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, 04 Apr 2019 01:12:59 -0000

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
> Extra@ietf.org
> 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.