From nobody Thu Feb 8 08:30:13 2018 Return-Path: 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 ACF5212D856; Thu, 8 Feb 2018 08:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ohMPQ2jym6HE; Thu, 8 Feb 2018 08:30:06 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFDA12D7F4; Thu, 8 Feb 2018 08:30:05 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id f34so6383192ioi.13; Thu, 08 Feb 2018 08:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xQZ/HyGPd9GYtX1RIxb96Oz3Jpzn3eMXs8zIdEHqoDE=; b=dqfJbWsWsiCVnUOTAIoLf5cFz51zCGcHOuKD66sbLrrVIxgdhMMfVyv8WoVrD+H5pH NoInDUB6hg0YodDO07XXy/IE6zgrBNYZXaCaE8ujL7rTuLOJeGxyvyxe2AyaBczSsk6v DyxMn3/sYJYL8l2xCVQe5eythqnBWXHbw6aH5mVBk9sCBLli1MQm/nhsy97p4NiStwOh f4vMNep5LkG3c20kc6k1ALoupqcd2nCHl9xsx/D5UB7fQus124lQVpmcyx1Xu8c39ElQ Jj32lJrx1jC65M/gAGr3ayfe0XMCxxQOdxdXxyUUHNCU4kPV9XSJYniFgfLCu9kUTGoZ gQqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xQZ/HyGPd9GYtX1RIxb96Oz3Jpzn3eMXs8zIdEHqoDE=; b=iajqZkIxdWmYcsWWszUg0Pxg2yz6YDo1qPXrycCOKRifYh6iBHlRid2DvR/uEAz8Xw EaTg4a6Vko5GOZLfvwDorn9mk2LZtPoWyllPfyEcccp7jEgbKFuJVs5Shn8KvVHAe95x c/dWfK5cX8eMM55C2lR3E796ebZQh1B3GQ2CfVomlCUXJkgJYd2gIGBfO/UMNRQLoUzR N329DYmt/ttBDm+6wO3FvON4WuqBi7L6rEMk/CtiBiMF6JUfGlut8ttx4tQ4TLjWn1hK Amx0CbhO8w8p8K/Qj3+HH/ova+NPXeH3YF/GYYS+y9cO3fjDfpTJq8rTJWmsGtaXsQiz G33w== X-Gm-Message-State: APf1xPAZZc20V+/7qegprRxx2XUNIS8TXm6nysHzmcGC0Vtu2bggXkcf vFf3dbxCXuo81lk4m9GUOyaBsz4LS2NdhGjMVm8= X-Google-Smtp-Source: AH8x224TuOoDcNttWAcF+Ht6TjjBRqjfO8RM22NSYziEdSOxQC4sloAThVi43927Q1HOMld2A5+b5YqD3AuDBnH36Ic= X-Received: by 10.107.137.104 with SMTP id l101mr1548181iod.179.1518107404856; Thu, 08 Feb 2018 08:30:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.159.20 with HTTP; Thu, 8 Feb 2018 08:29:44 -0800 (PST) In-Reply-To: <150920513831.2701.15502817713484537916.idtracker@ietfa.amsl.com> References: <150920513831.2701.15502817713484537916.idtracker@ietfa.amsl.com> From: "Jayantheesh S.B" Date: Thu, 8 Feb 2018 11:29:44 -0500 Message-ID: To: internet-drafts@ietf.org Cc: Alexey Melnikov , extra-chairs@ietf.org, extra@ietf.org Content-Type: multipart/alternative; boundary="001a113eb13498f4c50564b5ec7d" Archived-At: Subject: Re: [Extra] New Version Notification for draft-ietf-extra-imap-64bit-02.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 16:30:13 -0000 --001a113eb13498f4c50564b5ec7d Content-Type: text/plain; charset="UTF-8" Hello All, Kindly review this draft (IMAP-64) and share your comments. Regards, Jay On Sat, Oct 28, 2017 at 11:38 AM, wrote: > > A new version of I-D, draft-ietf-extra-imap-64bit-02.txt > has been successfully submitted by Alexey Melnikov and posted to the > IETF repository. > > Name: draft-ietf-extra-imap-64bit > Revision: 02 > Title: 64bit body part and message sizes in IMAP4 > Document date: 2017-10-28 > Group: extra > Pages: 7 > URL: https://www.ietf.org/internet- > drafts/draft-ietf-extra-imap-64bit-02.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-extra-imap- > 64bit/ > Htmlized: https://tools.ietf.org/html/draft-ietf-extra-imap-64bit-02 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-extra- > imap-64bit-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap- > 64bit-02 > > Abstract: > This document defines an IMAPv4rev1 extension that extends the > existing IMAPv4rev1 32 Bit message and body part sizes to 63 bit. > Both the base IMAP specification (RFC 3501) and several extensions > are updated. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > --001a113eb13498f4c50564b5ec7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All,

Kindly review this draft (IM= AP-64) and share your comments.=C2=A0

Regards,
=
Jay

On Sat, Oct 28, 2017 at 11:38 AM, <internet-drafts@ietf= .org> wrote:

A new version of I-D, draft-ietf-extra-imap-64bit-02.txt
has been successfully submitted by Alexey Melnikov and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-extra-imap-64bit Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 64bit body part and message sizes = in IMAP4
Document date:=C2=A0 2017-10-28
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 extra
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-extra= -imap-64bit-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-extra-imap-64bit/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //tools.ietf.org/html/draft-ietf-extra-imap-64bit-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-6= 4bit-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-imap-= 64bit-02

Abstract:
=C2=A0 =C2=A0This document defines an IMAPv4rev1 extension that extends the=
=C2=A0 =C2=A0existing IMAPv4rev1 32 Bit message and body part sizes to 63 b= it.
=C2=A0 =C2=A0Both the base IMAP specification (RFC 3501) and several extens= ions
=C2=A0 =C2=A0are updated.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a113eb13498f4c50564b5ec7d-- From nobody Thu Feb 8 09:04:03 2018 Return-Path: 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 BABA412DA0D for ; Thu, 8 Feb 2018 09:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8hHaf9Bsa8L8 for ; Thu, 8 Feb 2018 09:04:00 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D8612D7F4 for ; Thu, 8 Feb 2018 09:03:59 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id d8so7069733qtm.0 for ; Thu, 08 Feb 2018 09:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-transfer-encoding; bh=1BoQatHxSkNx+bgQ1Z5AEV4E9hZkmk7/atWzoCW1xlE=; b=a+NEIcMnRAxdjnggkYrbNgvRuVajaH3PKtV0RJEiS9CSPr0iAqE3SVgxNV2fAZsiHs usX4fiaixFa9tqjB8pBuHBjSkry7jXg15dOqN9sQSv9/Ug7mikXMsR1RuAFbZJT560gK jyxOgXrS5ylan7aJV79Ec9+ZfFeRUwdFh8+qGLnuufFOdjxJVNoxTw3DqVh5v2em3v/w k9pUifaje7y2+sQxt6jrSDnhAnzDIieqkr3UBSoEbeKufbZg+2c3tGBmuTmq3qSM5+Zl IE0u0vc2vIBAvHB/pevtyHPgq/IhsQJoJ//t0nIjSMC0VrHq4hTFzRhSL0spjCWeCkNs mKDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-transfer-encoding; bh=1BoQatHxSkNx+bgQ1Z5AEV4E9hZkmk7/atWzoCW1xlE=; b=DnF31+HqxX6LXo6wB0d3tjvL0PwFYVlZzK9gvP+Og2LsP80J1IdLLTNFIUrHq9lPyw oCFQRXonzZR+AB5jxW5vnRIWXf3ERro2fb7YzsqJls7lHG0CyJC4eszIjiGO7vCWOMS9 ild8pZTylLkfrqk9pVh0q7UzH4uTZgUNZNMX/MJcgu12LFDDuqcoScJ4dW/ABQTKEqk9 c27Olu0kIJ8a9uMkH9LVLi7DOw8tmHPx6k9B0yn3wqaow24l2EOf4ganxxPgT2udvpFq gGSmPvsSDam+WA4wZs/EXLXioRwEkGplTfU5yVFn/zhf1+lMxM88p4+3ldczDLOz5dwo H/9g== X-Gm-Message-State: APf1xPCFeb07PJHfaA2aPxhzrORwhmc7zRHXxIHiiZZJi1AEEDotND5C DT1aCIieocbk8WutpXf57uCcY97l5cCP7qpOIoa8mw== X-Google-Smtp-Source: AH8x224UTrKVvpdByu+/LOCaVpT/j8UqG76/HG593S34qlTxn6AFJbK3VgHPKnJT7JBaOUR2NOc6ysxKD7qOpnsX6q4= X-Received: by 10.237.45.1 with SMTP id h1mr2126955qtd.34.1518109438880; Thu, 08 Feb 2018 09:03:58 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.35.199 with HTTP; Thu, 8 Feb 2018 09:03:58 -0800 (PST) In-Reply-To: <1510799355.3640467.1174131992.15AF5270@webmail.messagingengine.com> References: <20171115160621.GC17058@meili> <1510799355.3640467.1174131992.15AF5270@webmail.messagingengine.com> From: Barry Leiba Date: Thu, 8 Feb 2018 12:03:58 -0500 X-Google-Sender-Auth: rN75XoY8TNgg7zJ9c-7d1s5wKG4 Message-ID: To: extra@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] "IMAP $Important Keyword and \Important Special-Use Attribute" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 17:04:02 -0000 I'm coming back to this after some time: two comments in favour of moving forward, no one thinking it's a bad idea, and the only comment being that the distinction between \Flagged and $Important might not be clear enough. I'd also like to know if people will implement this if we publish it. On the distinction question, I really don't see what I can say that's clearer than the contents of Section 2, which I reproduce here for convenience: --------------------------------------- 2. Definition of the '$Important' Message Keyword The "$Important" keyword is a signal that a message is likely important to the user. The keyword can be set by the user, or automatically by the system based on available signals (such as who the message is from, who else the message is addressed to, evaluation of the subject or content, or other heuristics). This is distinct from the "\Flagged" system flag in two ways: 1. "$Important" carries a specific meaning of importance, as opposed to urgency. It is meant to be used for a form of triage, with "\Flagged" remaining as a designation of special attention or particular urgency. 2. The setting of "$Important" is expected to be based at least partly on heuristics, whereas "\Flagged" is intended to be set by the user. --------------------------------------- What Neil suggests isn't quite right, because we *do* want the user to be able to set $Important, even if we don't expect it to be the primary way $Important is set. Maybe if I change the way the explanation is focused it will help. How's this new version look to people?: --------------------------------------- 2. Definition of the '$Important' Message Keyword The "$Important" keyword is a signal that a message is likely important to the user. The keyword is generally expected to be set automatically by the system based on available signals (such as who the message is from, who else the message is addressed to, evaluation of the subject or content, or other heuristics). While the keyword also can be set by the user, that is not expected to be the primary usage. This is distinct from the "\Flagged" system flag in two ways: 1. "$Important" carries a specific meaning of general importance, as opposed to follow-up or urgency. It is meant to be used for a form = of triage, with "\Flagged" remaining as a designation of special attent= ion, need for follow-up, or time-sensitivity. In particular, the sense o= f "$Important" is that other messages that are "like this one" accordi= ng to some server-applied heuristics will also be $Important. 2. The setting of "$Important" is expected to be based at least partly on heuristics, generally set automatically by the server, whe= reas "\Flagged" is only intended to be set by the user with some sort of "flag this message" or "put a star on this message" interface. --------------------------------------- Does that help? Barry On Wed, Nov 15, 2017 at 9:29 PM, Neil Jenkins wrot= e: > On Thu, 16 Nov 2017, at 12:06 AM, Josef 'Jeff' Sipek wrote: > > My only concern here is that the distinction between $Important and > \Flagged is a bit confusing. > > > I agree the naming is a bit annoying, but I think the difference can be m= ade > clear: > > \Flagged: the user explicitly marked this as important. > $Important: the server (using some unspecified algorithm) marked this as > important. > > > (Of course, clients may be able to help train the server by allowing user= s > to toggle the $Important flag on messages the server miscategorised, whic= h > does blur the distinction somewhat=E2=80=A6) > > FWIW, the \Flagged definition in RFC 6154 doesn't help this at all: > > This mailbox presents all messages marked in some way as > "important". > > This is an unfortunate wording. > > > Ouch, agreed. > > Overall though I'm in favour of this draft, and an IANA registry for > special-use names is definitely a step forward (we'll use it for JMAP too= ). > > Neil. From nobody Thu Feb 8 12:57:37 2018 Return-Path: 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 8EB001270A3 for ; Thu, 8 Feb 2018 12:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 fUewHy6ozSav for ; Thu, 8 Feb 2018 12:57:34 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 13242126C3D for ; Thu, 8 Feb 2018 12:57:34 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id CA3702A6900; Thu, 8 Feb 2018 22:57:32 +0200 (EET) From: Stephan Bosch To: Ned Freed Cc: extra@ietf.org References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <01QNNBB3GEW0000051@mauve.mrochek.com> <990a2344-d003-5a05-6b5c-c9d72a259753@dovecot.fi> Message-ID: Date: Thu, 8 Feb 2018 21:57:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <990a2344-d003-5a05-6b5c-c9d72a259753@dovecot.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 20:57:35 -0000 Op 1/17/2018 om 12:14 AM schreef Stephan Bosch: > I hope I have time make a new version by the end of this week. We'll see. All is taking a bit longer. Addressed one point so far (see Git). 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 ------------------------------------------------------------------------------------- From nobody Fri Feb 9 03:27:01 2018 Return-Path: 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 99F33126D0C for ; Fri, 9 Feb 2018 03:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 K4IPqKebJZ7E for ; Fri, 9 Feb 2018 03:26:58 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8A1126BF6 for ; Fri, 9 Feb 2018 03:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1518175617; d=isode.com; s=june2016; i=@isode.com; bh=QhxPWmQCL2yXYWq9ZJH9FxviV+gLge3ZMJGXrWihZNE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=eCR5wDptCI7PvhxjeeMbyHtArBICWRpmpBcz9AZ9T5SglL5RaUGfwQNY/oBlWtTmapNq/z 3bJiOaL5TtxGkD9tQpIdJ+Tchbjj2B1n/eu0nmEgISSvIKNlnNrcqKuIg0iFqZsN/M/HnJ nOJgAPgyIUH+ODWEB8Rs6zU2yxiikiE=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 9 Feb 2018 11:26:57 +0000 To: Barry Leiba , extra@ietf.org References: <20171115160621.GC17058@meili> <1510799355.3640467.1174131992.15AF5270@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: <1e08751e-eb51-7fc6-eb39-214eca7f48af@isode.com> Date: Fri, 9 Feb 2018 11:26:29 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Extra] "IMAP $Important Keyword and \Important Special-Use Attribute" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 11:27:00 -0000 Hi Barry, With my implementer's hat on: On 08/02/2018 17:03, Barry Leiba wrote: > I'm coming back to this after some time: two comments in favour of > moving forward, no one thinking it's a bad idea, and the only comment > being that the distinction between \Flagged and $Important might not > be clear enough. In case I didn't say this earlier: I am somewhere in between "this is=20 useful" and "this is not harmful and other people implemented it, so we=20 should at least document it". > I'd also like to know if people will implement this > if we publish it. Maybe :-). > On the distinction question, I really don't see what I can say that's > clearer than the contents of Section 2, which I reproduce here for > convenience: > > --------------------------------------- > 2. Definition of the '$Important' Message Keyword > > The "$Important" keyword is a signal that a message is likely > important to the user. The keyword can be set by the user, or > automatically by the system based on available signals (such as who > the message is from, who else the message is addressed to, evaluation > of the subject or content, or other heuristics). > > This is distinct from the "\Flagged" system flag in two ways: > > 1. "$Important" carries a specific meaning of importance, as opposed > to urgency. It is meant to be used for a form of triage, with > "\Flagged" remaining as a designation of special attention or > particular urgency. > > 2. The setting of "$Important" is expected to be based at least > partly on heuristics, whereas "\Flagged" is intended to be set by > the user. > --------------------------------------- > > What Neil suggests isn't quite right, because we *do* want the user to > be able to set $Important, even if we don't expect it to be the > primary way $Important is set. Maybe if I change the way the > explanation is focused it will help. How's this new version look to > people?: > > --------------------------------------- > 2. Definition of the '$Important' Message Keyword > > The "$Important" keyword is a signal that a message is likely > important to the user. The keyword is generally expected to be set > automatically by the system based on available signals (such as who > the message is from, who else the message is addressed to, evaluation > of the subject or content, or other heuristics). While the keyword al= so > can be set by the user, that is not expected to be the primary usage. > > This is distinct from the "\Flagged" system flag in two ways: > > 1. "$Important" carries a specific meaning of general importance, as > opposed to follow-up or urgency. It is meant to be used for a for= m of > triage, with "\Flagged" remaining as a designation of special atte= ntion, > need for follow-up, or time-sensitivity. In particular, the sense= of > "$Important" is that other messages that are "like this one" accor= ding to > some server-applied heuristics will also be $Important. > > 2. The setting of "$Important" is expected to be based at least > partly on heuristics, generally set automatically by the server, w= hereas > "\Flagged" is only intended to be set by the user with some sort o= f > "flag this message" or "put a star on this message" interface. > --------------------------------------- > > Does that help? I think this version is much better. Thank you, Alexey > Barry > > On Wed, Nov 15, 2017 at 9:29 PM, Neil Jenkins wro= te: >> On Thu, 16 Nov 2017, at 12:06 AM, Josef 'Jeff' Sipek wrote: >> >> My only concern here is that the distinction between $Important and >> \Flagged is a bit confusing. >> >> >> I agree the naming is a bit annoying, but I think the difference can be m= ade >> clear: >> >> \Flagged: the user explicitly marked this as important. >> $Important: the server (using some unspecified algorithm) marked this as >> important. >> >> >> (Of course, clients may be able to help train the server by allowing user= s >> to toggle the $Important flag on messages the server miscategorised, whic= h >> does blur the distinction somewhat=E2=80=A6) >> >> FWIW, the \Flagged definition in RFC 6154 doesn't help this at all: >> >> This mailbox presents all messages marked in some way as >> "important". >> >> This is an unfortunate wording. >> >> >> Ouch, agreed. >> >> Overall though I'm in favour of this draft, and an IANA registry for >> special-use names is definitely a step forward (we'll use it for JMAP too= ). >> >> Neil. > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Fri Feb 9 06:18:37 2018 Return-Path: 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 5242912946D for ; Fri, 9 Feb 2018 06:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FFtS2-2XREUL for ; Fri, 9 Feb 2018 06:18:26 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9309E124205 for ; Fri, 9 Feb 2018 06:18:26 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id d26so233278qtk.10 for ; Fri, 09 Feb 2018 06:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vdM5xJ3ThaI1acko3+VL2yTQ8VJx6o+YaBYTbBX5YDU=; b=Oks8bTRPh6lER/B0dWDsYqc7IiNKl3AonLd50B9S6qU2EnQbzdPoenVgK8mIYVLort GeaLV4BJ5MK2r0Wgg4S8MA343F/NKlRIsO0Fj6aM5ZrciaD8HIg8YhEQUSSrinucBemI XdTLW+k2zf0kGFBI7vTtvo8qnnXP7S2xWMekAlTy7cdnVo7XEqo639vlaFxmU5Kjz9V3 +K2ha4PQvOC+DD0ObhtilCF8todgXctvmBvPYf+xLQNLmCIL99I+VrBvPVQ5ijC9eTlI yHv2NVeVyoaOjLDZkRAO18uC6FPEdAuTKZHxcoxJAb4y/iFDXqSp9JzCnQWEqM7PSF0M wbQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vdM5xJ3ThaI1acko3+VL2yTQ8VJx6o+YaBYTbBX5YDU=; b=MbO8eW8tQqL6NMEW/4D3nqsd7nmYegGT9UiUWy3vyQadhcRE+6h6gpyg/Hb5TuVb6x L/Q3ne95FuM1AvRXHVkAM0TuLdyehWqHRg63wM6/xsqoDbUzOelC2AO8nfL5dBpmboxL pPKglahNgTiA0S40kAaGgen0sxf6739bd9TmTibnI3bhKWHHYAnrYd8fPWUrhM8/GvpN 0bQYPmEqL8vEWUo2Jw61rd2MAZWmL0AViNKEoLexqvR5PKl5xOBvBSjV+R+uYfhxDP52 k5q2PQtzRnvC5L9IGX0QYIe5GYYpHQgA7Pd2qn5URZrk52SxeaXRJOGzYs0Qy0OkdKS2 3h3g== X-Gm-Message-State: APf1xPDM4dDV8CUBcNrgmiShlNYSvlg+nw9L+xZk5GbwbQImR6uKTtO/ CciQ71g9QnGhXVdBTNoOYU4xSPO/fQ1l2mT+EPs= X-Google-Smtp-Source: AH8x227QioR4aCSY42tRYTK6QXJTeSBIVc1O64mdBz6/ZblbQrnudITsXBGUKWJqe3jjpCZqVuwy6co8geWEbBi450I= X-Received: by 10.200.97.86 with SMTP id d22mr4525102qtm.217.1518185905683; Fri, 09 Feb 2018 06:18:25 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.35.199 with HTTP; Fri, 9 Feb 2018 06:18:25 -0800 (PST) In-Reply-To: <1e08751e-eb51-7fc6-eb39-214eca7f48af@isode.com> References: <20171115160621.GC17058@meili> <1510799355.3640467.1174131992.15AF5270@webmail.messagingengine.com> <1e08751e-eb51-7fc6-eb39-214eca7f48af@isode.com> From: Barry Leiba Date: Fri, 9 Feb 2018 09:18:25 -0500 X-Google-Sender-Auth: dXlSo3PqEApJPKJIopCXSHyjbVo Message-ID: To: Alexey Melnikov Cc: extra@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Extra] "IMAP $Important Keyword and \Important Special-Use Attribute" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 14:18:35 -0000 Thanks for the input, Alexey. > In case I didn't say this earlier: I am somewhere in between "this is > useful" and "this is not harmful and other people implemented it, so we > should at least document it". >> >> I'd also like to know if people will implement this >> if we publish it. > > Maybe :-). I'd prefer " Probably :-) ", but I'll take it... Barry From nobody Fri Feb 9 07:25:21 2018 Return-Path: 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 77012124205 for ; Fri, 9 Feb 2018 07:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 0KVGPeFIE1M9 for ; Fri, 9 Feb 2018 07:25:18 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA061200F1 for ; Fri, 9 Feb 2018 07:25:17 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 474E2FA0088; Fri, 9 Feb 2018 15:25:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1518189915; bh=+li4Vi71wVYW7A+W1I/GFRzlSEWYYg7TgQwhtBXP0jY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QVyl2YkfszcxZK9iMndpXZZEqWSeSOAtD6KuLSe6u3MAjo2zFgUFmHWWFKhFOomFD iBvKkKiDi6LEJyEYJAzQWQ1l0IbNUoVwK64JUcV0ZjK+e7eCTmX4ienhAvKmeAKOoK xhoqXHv2j+D9UhEliDHCfIt6o3MNWZHSnAGF/G/4= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1518189914-31495-31493/11/3; Fri, 9 Feb 2018 15:25:14 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Fri, 9 Feb 2018 15:25:13 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20171115160621.GC17058@meili> <1510799355.3640467.1174131992.15AF5270@webmail.messagingengine.com> <1e08751e-eb51-7fc6-eb39-214eca7f48af@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] "IMAP $Important Keyword and \Important Special-Use Attribute" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 15:25:20 -0000 Barry Leiba writes: > I'd prefer " Probably :-) ", but I'll take it... As I see it, the distinction between \Flagged and $Important is too subtle to be reliably implemented and understood. But I'll accept the registration. The subtlety not a blocking problem IMSNHO. Arnt From nobody Fri Feb 9 08:34:47 2018 Return-Path: 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 9BD8C127058 for ; Fri, 9 Feb 2018 08:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sQ_8B2K_9QMt for ; Fri, 9 Feb 2018 08:34:44 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468831200FC for ; Fri, 9 Feb 2018 08:34:44 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id u6so10819667qtg.13 for ; Fri, 09 Feb 2018 08:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XqTJ+EvEWzVnEug+Tgg99QT/zTBXnhwDzZtdkkn7F7E=; b=T5xf5ZL/e7Glkp6iIlTpC8Dk3YcEkOvNjy8zImgVGsLhbujUM+HbscCr4UC4UluQeo w7TOeLj6lR1nKsCqzYqpm0x64GjIc1Kd7KSTQfFsu0WDt4RYaoGkEfqcTrKxaJA06rzo 46bvYqDYKYDm1zR7KgrBL0Mqzpoau80OusgUBTPkr6GTQlrl7+4Vc9Vqt9+6Pv80L9du mfMYLn9RAHqvUq04YS+EcSL0AJlFs8NPkLc6dCaKNTABuymZfxKQdrZQdUpfwNzPTfG/ HvcncMwrV9cZH0VQInXKpwjj0lgsHmZ1wIqM2ndB71JsgtUmVM8jFymcDGgfohwX6G1t nc8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XqTJ+EvEWzVnEug+Tgg99QT/zTBXnhwDzZtdkkn7F7E=; b=t66MyYmXcsQI6ETavH0f+zoVXyKULKLVvw9CyP3XjhhCQoMQoJb8OF01F6Alcbsrxg bKWHafmWQeXU5ZWCUEdHRvxPny8zh31DHbxp+EYKU12OojQU7rBJwl1TFcbVGhGiGW6d i9icTP8SSy6CQZoaueTG+96qsGZt0DjKxGuRpjxu4q95hqMhaRVVjlBDIyaMRBbhBQKQ VTMoi4bo2fd2kCqd0xki/+wz8N/XIgSg+cIeUQR6/I8SLdWXPGWaFlUnDsV3qlinppT2 pAMawRiB6htvtF+0lbqxIwRjRlbXdb25Cha6Pif8G5FGdJZLek5fw/mhH1MppYOPPtrK Z0/g== X-Gm-Message-State: APf1xPBalrHvq27c4f/aPVgU4ZfqZagQvJMiQrB96UTskwrqkf2BMYWb cd1clskzXPfE5165NKlyM+Dl0Y3giaP95C3xrcQ= X-Google-Smtp-Source: AH8x226vJ1QiCyv/U5ousTZXK7A63jKrDJQo47lo77jik3XRw2EA8SP/pfY0RzSdYN3i8upDxdJAAmbL2FLxtxDVE/U= X-Received: by 10.200.54.10 with SMTP id m10mr5473583qtb.304.1518194083256; Fri, 09 Feb 2018 08:34:43 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.35.199 with HTTP; Fri, 9 Feb 2018 08:34:42 -0800 (PST) In-Reply-To: References: <20171115160621.GC17058@meili> <1510799355.3640467.1174131992.15AF5270@webmail.messagingengine.com> <1e08751e-eb51-7fc6-eb39-214eca7f48af@isode.com> From: Barry Leiba Date: Fri, 9 Feb 2018 11:34:42 -0500 X-Google-Sender-Auth: xsVhJM7mpH_BS-j4aQxxeF67RLs Message-ID: To: Arnt Gulbrandsen Cc: extra@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Extra] "IMAP $Important Keyword and \Important Special-Use Attribute" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 16:34:46 -0000 > As I see it, the distinction between \Flagged and $Important is too subtle > to be reliably implemented and understood. Hm. The intent here is this: On the server side: - \Flagged is set or cleared in response to an explicit command from the client. - $Important is set via a heuristic process performed by the server, usually involving analysis of header fields, what mailbox the message is filed in, perhaps message content, attachments, and such. It may then be set or cleared in response to an explicit command from the client, and the server may use that to adjust the heuristics in the future. It's also possible that the server will re-evaluate this and make a message $Important later if the user accesses the message frequently, for example. On the client side: - Typically, an icon such as a flag or a star, or an indication such as red or bold text, is associated with \Flagged, and the UI provides a way for the user to turn that icon or indication on or off. Manipulation of the this results in a command to the server. - Typically, a lesser indication is used for $Important. The client might or might not provide the user with a way to manipulate it. If it does, manipulation results in a command to the server. Does that help you make an implementable distinction? Would it help to include a non-normative section of the document describing how this is typically handled? Barry From nobody Tue Feb 13 18:12:31 2018 Return-Path: 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 8A54E1242F5 for ; Tue, 13 Feb 2018 18:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=WxtXmWyK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h3Ive6Ig 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 ccRXx-ermMui for ; Tue, 13 Feb 2018 18:12:28 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED75912708C for ; Tue, 13 Feb 2018 18:12:27 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 2A6EC20CEB for ; Tue, 13 Feb 2018 21:12:27 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 13 Feb 2018 21:12:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bVdytZTqaxJzjisLU i1i2KQSfSVyn8yiyQjDhhMkXN0=; b=WxtXmWyKiy4/sn/Gh28QdcMBAQgWTkdb8 cz0/Kgq1pU1Mnd5VYF4K9jX5IXtPOmztdDpbmIrs5IL7/jOfK4wcIzgPIX4uJL3b E2pnkn21NtdozpYm6UB8qwhlCSZrpxC16w/SjBDexC/Vaw1vET+cpHJQPP3tsSqx RJLb3isJ5VERqVDYBhimmMig8rod7Prxw6SBPB6BhjltmiIqjK428aIQ/DgiGYQ8 ARTlytirHpL/TE1YdGELXPZAAoVjbGfMiW13+BrEBqAYTqWpo5kXdCkYBYzntSB4 Obu/FuSz/4H7T255YdkhuG3ydOvNZbe5/2b6a3xSTecx+Y5RgAICQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=bVdytZ TqaxJzjisLUi1i2KQSfSVyn8yiyQjDhhMkXN0=; b=h3Ive6IgoQyWEwHkgVTFt1 7/AmKS9D4zXunTgpoIBwhfSH4l8/JU5yyWhtWV0izq6cqsvSCcLa6jVYDtzLjERi 3zyO4ebSms43OIi2Twp8KX4FrA9pwZqAIKFbFqBB5JkpiAUmNu+aiWD/GfRkzqyJ Xy47rtX+SOsgfsvr3EMEFu3dffaKGEhqt9O/OncI7Tp9SHn+hAKH2UheCtEfUrrt GN1w5yVW7ICpRfJMjb103XbFgj3uL72ehg1Fpx7qSkG6fovfZhoMQpO5oYnPICrH IR115rsVN0AThW7CFHEET9IrWEiQVasZ9Gd5WjvOuTDXAenQEux2NgJLztCH1RPA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DAD78E2218; Tue, 13 Feb 2018 21:12:26 -0500 (EST) Message-Id: <1518574346.3262472.1270085616.6BB1CF11@webmail.messagingengine.com> From: Neil Jenkins To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151857434632624720" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5f8580fe References: <20171115160621.GC17058@meili> <1510799355.3640467.1174131992.15AF5270@webmail.messagingengine.com> <1e08751e-eb51-7fc6-eb39-214eca7f48af@isode.com> Date: Wed, 14 Feb 2018 13:12:26 +1100 In-Reply-To: Archived-At: Subject: Re: [Extra] "IMAP $Important Keyword and \Important Special-Use Attribute" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 02:12:30 -0000 This is a multi-part message in MIME format. --_----------=_151857434632624720 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" This description (intent on server and client) seems clear to me, and I feel adequately distinguishes the two. Neil. --_----------=_151857434632624720 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
This description (intent on server and client) seems clear to me, and I feel adequately distinguishes the two.

Neil.
--_----------=_151857434632624720-- From nobody Thu Feb 15 14:30:09 2018 Return-Path: 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 75B0B12D947 for ; Thu, 15 Feb 2018 14:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 I3q4QjDMfwTd for ; Thu, 15 Feb 2018 14:30:07 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id F2B7412D866 for ; Thu, 15 Feb 2018 14:30:06 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id BA4122B3CD0; Fri, 16 Feb 2018 00:30:05 +0200 (EET) From: Stephan Bosch To: Ned Freed Cc: extra@ietf.org References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <01QNNBB3GEW0000051@mauve.mrochek.com> <990a2344-d003-5a05-6b5c-c9d72a259753@dovecot.fi> Message-ID: <8affa07e-7e2f-ef54-fcbd-e450b5636eed@dovecot.fi> Date: Thu, 15 Feb 2018 23:30:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <990a2344-d003-5a05-6b5c-c9d72a259753@dovecot.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 22:30:08 -0000 Op 1/17/2018 om 12:14 AM schreef Stephan Bosch: > Hi Ned, > > Op 1/9/2018 om 10:44 PM schreef Ned Freed: Slowly making progress on this one. I just gave the point below a fresh look: >>>> The other aspect of the many-many mapping is the fact that a single mailbox can >>>> have multiple special use attributes. The draft supports this in the context of >>>> specialuse_exists but not in the context of fileinto. I think this is fine, but >>>> I want to make sure everyone is happy with this limitation, including the fact >>>> that because of this you won't be able to create mailbox with fileinto with >>>> multiple special use attributes. >>> Good point. For sake of discussion, let's assume we allow a string list >>> for the :specialuse parameter. The semantics for creation of a mailbox >>> would be quite clear: all of those flags are assigned to the new >>> mailbox. >> Seems reasonable. >> >>> But what would that mean for the mailbox lookup? Are we looking >>> for a mailbox that has all of these flags, one of these flags or just >>> the first flag listed? >> The convention elsewhere seems pretty clearly to be for it to be an AND rather >> than an OR. > I agree. > >>> Another question is whether mailboxes with several special-use flags are >>> really that useful. >> Apart from \All, which I would hope is not up to clients to set, I don't see >> them as being useful. But I may be missing some use cases, which is why I >> brought it up. > Ok. Now my question to everyone is: do I need to change anything or is the fileinto limitation acceptable? 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 ------------------------------------------------------------------------------------- From nobody Thu Feb 15 14:31:43 2018 Return-Path: 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 8DB2C12D96C for ; Thu, 15 Feb 2018 14:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 sDo5OBH5lqjN for ; Thu, 15 Feb 2018 14:31:39 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAAB12D947 for ; Thu, 15 Feb 2018 14:31:39 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 6D4282B3CD0; Fri, 16 Feb 2018 00:31:38 +0200 (EET) From: Stephan Bosch To: Bron Gondwana , extra@ietf.org References: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> <1515362666.2687647.1227253816.726EA133@webmail.messagingengine.com> <7d5e0617-cba4-c19c-8426-64f2a9e8f1eb@dovecot.fi> Message-ID: <64ce2646-958d-0a0c-c63a-8e15641380b0@dovecot.fi> Date: Thu, 15 Feb 2018 23:31:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7d5e0617-cba4-c19c-8426-64f2a9e8f1eb@dovecot.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: nl Archived-At: Subject: Re: [Extra] SAVEDATE updated required X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 22:31:42 -0000 Hi Bron, Any word on the questions I asked below? Op 1/28/2018 om 3:51 PM schreef Stephan Bosch: > Op 1/7/2018 om 11:04 PM schreef Bron Gondwana: >> On Mon, 8 Jan 2018, at 00:04, Stephan Bosch wrote: >>> Hi Bron, >>> >>> Op 1/4/2018 om 1:54 AM schreef Bron Gondwana: >>> >>> 2: if the mailbox doesn't support storing save date, the SEARCH >>> extensions should return an error if used, rather than a result, >>> since >>> there's no way to calculate a sensible answer to any of those three. >>> >>> >>> Ok, for the sake of discussion, I added text with this effect in the >>> last version. However, I am not quite happy with it yet. Returning an >>> error seems a bit harsh. Do we need to provide some means for the client >>> to find out whether the mailbox supports the save date attribute before >>> trying to use it? >> That could be done: >> >> TAG select "foo" >> * 1 EXISTS >> * 1 RECENT >> * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) >> * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Seen \*)] Ok >> * OK [UNSEEN 1] Ok >> * OK [UIDVALIDITY 1515362059] Ok >> * OK [UIDNEXT 2] Ok >> * OK [HIGHESTMODSEQ 7] Ok >> * OK [URLMECH INTERNAL] Ok >> * OK [ANNOTATIONS 65536] Ok >> TAG OK [READ-WRITE] Completed >> >> Another line in there that said something like: >> >> * OK [SAVEDATE] Ok >> >> Would probably work fine. > Yes, that could work. Although, when the SQL NULL semantics (discussed > below) are implemented, this would likely no longer be necessary/useful. > >>> Also, there's the MULTISEARCH extension (RFC7377), which adds an ESEARCH >>> command that allows searching across a wide selection of mailboxes, some >>> of which may in fact lack support for the save date attribute. What is >>> to be done in that case? Fail the whole ESEARCH command? Ignore the >>> mailboxes that lack support? Make the SAVED* search items yield a false >>> result for that mailbox? None of these options seem very appealing. >> There are three choices: >> 1) reject the command if any folder doesn't support SAVEDATE >> 2) reject the command if none of the folders support SAVEDATE >> 3) succeed regardless of the support for SAVEDATE >> >> And if there are folders that don't support SAVEDATE for case 2 or 3, >> you can: >> a) use the INTERNALDATE instead >> b) don't match the message >> >> I think (a) is clearly wrong here - if you're deleting everything >> that's SAVEDBEFORE 1 month ago from a Trash folder, then INTERNALDATE >> will purge things before you want to. > Yes, indeed. > >> The alternative is to treat SAVEDATE as NULL in the same way SQL does, >> and I think that's the right choice.  So you can say "SEARCH NOT >> SAVEDAFTER {X} BEFORE {X}" if you want to get the behaviour of >> deleting everything that was SAVEDBEFORE a time, or fallback to >> INTERNALDATE if it's not supported. > I see what you're trying to do here and I agree that something like that > would be a good idea. However, we need  to be very careful about the > semantics. With SQL 3-valued logic, I think (with my rather limited > SQL-fu) your example would evaluate to Unknown: > > `NOT SAVEDAFTER {X} BEFORE {X}' logically translates to: > > (not `SAVEDAFTER {X}') and `BEFORE {X}' > (not Unknown) and `BEFORE {X}' > Unknown and `BEFORE {X}' > Unknown > > So, how did you expect this example to work? Or am I doing something > wrong in this inference? 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 ------------------------------------------------------------------------------------- From nobody Sun Feb 18 02:04:06 2018 Return-Path: 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 F41C0126DEE for ; Sun, 18 Feb 2018 02:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=n6I71NuX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d7jNu+Xu 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 wq3IMy8P-JcU for ; Sun, 18 Feb 2018 02:04:03 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE34124D6C for ; Sun, 18 Feb 2018 02:04:03 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 676CD20CD2 for ; Sun, 18 Feb 2018 05:04:02 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 18 Feb 2018 05:04:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hucA51iz70db2jZaO 34FDp+lpDj0Xv5aG0TDMyOPpNM=; b=n6I71NuXXq1eXzezq5Vzw9tr2wQaYqdtY zdvH0lec4sToWUVyPGq6/RN36g2cki9EYylpefrVvFP6bdHwsNTM/NHHn1gMUaxl JGdWQ7oPi5a9sjr9R409F4CaOezai7pHYKahjpok1nhAVcNTKBkWDxGZOZSxiasd 6ZancTKUtz41WyerN/R8j/nZnqJ6geyXIrW+z8RUg8Eo1do6IrESePoEqidwFzg3 9z/RYnLJfoskKkxUAzAnJZ4GrFXuVokwqvM5BKdEVZMl2i9jUDXa/Es3f925OnFH J9Mt5Pi7Kg3S0pXK8U1TquYVruBc5dBKLpTYESyLB3hHMJub9RgIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=hucA51 iz70db2jZaO34FDp+lpDj0Xv5aG0TDMyOPpNM=; b=d7jNu+XuhSDmH/Cwi6Wmpy JhUTa4o+ILgzHF/zLIw/0+oxJt3yljgjrain7xccgKqLQ4ugFAjjw8T+6NVCtQ3P d+YOZAMnwWKJp0GicOXpeX84o6yfjs4ZrKJx8j/gHhUXmjElzdxOpwH2ob15kZdm 1/nsMVz8yi3glrvKWezrYMckd5yXLu4eb5jI2wr5auk232vqJu25i5lNehezkx55 VlxKerF3NNvcEAHgxo3fJK73d8zit8tcx3lD4K79b1/oWdaQA42wQXjDYjcY4xAg SjjzlC82yChaR/vUUVoGE8/1KZpwWA9RCNMYc8BCWtCYXsMj0cCq/h7vkDrO0RXQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 45054621DC; Sun, 18 Feb 2018 05:04:02 -0500 (EST) Message-Id: <1518948242.1810703.1274657584.3EEDD661@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151894824218107030" X-Mailer: MessagingEngine.com Webmail Interface - ajax-1b99b2df References: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> <1515362666.2687647.1227253816.726EA133@webmail.messagingengine.com> <7d5e0617-cba4-c19c-8426-64f2a9e8f1eb@dovecot.fi> <64ce2646-958d-0a0c-c63a-8e15641380b0@dovecot.fi> Date: Sun, 18 Feb 2018 21:04:02 +1100 In-Reply-To: <64ce2646-958d-0a0c-c63a-8e15641380b0@dovecot.fi> Archived-At: Subject: Re: [Extra] SAVEDATE updated required X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 10:04:06 -0000 This is a multi-part message in MIME format. --_----------=_151894824218107030 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi Stephen, sorry about missing replying on this - it came through in the week I was really sick and I didn't get back to it! Let's look at it with SQL (sqlite in this case): id|internaldate|savedate 1|2018-01-01|2018-01-01 2|2018-01-01|2018-02-01 3|2018-02-01|2018-02-01 4|2018-01-01| 5|2018-02-01| table 'foo' - with rows 4 and 5 having NULL savedate. We want to select rows 1 and 4 without getting row 2. Yeah, you're right: sqlite> select * from foo where not savedate > '2018-01-30' and sqlite> internaldate < '2018-01-30';id|internaldate|savedate 1|2018-01-01|2018-01-01 sqlite> select * from foo where (savedate is null or not savedate > '2018-01- sqlite> 30') and internaldate < '2018-01-30';id|internaldate|savedate 1|2018-01-01|2018-01-01 4|2018-01-01| sqlite> Well, that's a pain. I definitely want a way to say that second expression - because that's what I would be working with if I wanted to be able to select "old" messages regardless of whether SAVEDATE was supported. I guess in this particular case, the idea of "fall back to internaldate only if savedate isn't defined" would be exactly what I wanted, but then maybe I'd want SAVEDBEFORESTRICT and SAVEDBEFORERELAXED :p Horrible names though. Mind you, with IMAP semantics you don't have Undefined, so having SAVEDBEFORE and SAVEDAFTER both always evaluate false if you don't have support would give the behaviour that my expression wants. Bron. On Fri, 16 Feb 2018, at 09:31, Stephan Bosch wrote: > Hi Bron, > > Any word on the questions I asked below? > > Op 1/28/2018 om 3:51 PM schreef Stephan Bosch: >> Op 1/7/2018 om 11:04 PM schreef Bron Gondwana: >>> On Mon, 8 Jan 2018, at 00:04, Stephan Bosch wrote: >>>> Hi Bron, >>>> >>>> Op 1/4/2018 om 1:54 AM schreef Bron Gondwana: >>>> >>>> 2: if the mailbox doesn't support storing save date, the SEARCH >>>> extensions should return an error if used, rather than a result,>>>> since >>>> there's no way to calculate a sensible answer to any of those >>>> three.>>>> >>>> >>>> Ok, for the sake of discussion, I added text with this effect >>>> in the>>>> last version. However, I am not quite happy with it yet. >>>> Returning an>>>> error seems a bit harsh. Do we need to provide some means for the >>>> client>>>> to find out whether the mailbox supports the save date attribute >>>> before>>>> trying to use it? >>> That could be done: >>> >>> TAG select "foo" >>> * 1 EXISTS >>> * 1 RECENT >>> * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) >>> * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Seen \*)] Ok >>> * OK [UNSEEN 1] Ok >>> * OK [UIDVALIDITY 1515362059] Ok >>> * OK [UIDNEXT 2] Ok >>> * OK [HIGHESTMODSEQ 7] Ok >>> * OK [URLMECH INTERNAL] Ok >>> * OK [ANNOTATIONS 65536] Ok >>> TAG OK [READ-WRITE] Completed >>> >>> Another line in there that said something like: >>> >>> * OK [SAVEDATE] Ok >>> >>> Would probably work fine. >> Yes, that could work. Although, when the SQL NULL semantics >> (discussed>> below) are implemented, this would likely no longer be >> necessary/useful.>> >>>> Also, there's the MULTISEARCH extension (RFC7377), which adds an >>>> ESEARCH>>>> command that allows searching across a wide selection of >>>> mailboxes, some>>>> of which may in fact lack support for the save date attribute. >>>> What is>>>> to be done in that case? Fail the whole ESEARCH command? Ignore the>>>> mailboxes that lack support? Make the SAVED* search items yield a >>>> false>>>> result for that mailbox? None of these options seem very appealing.>>> There are three choices: >>> 1) reject the command if any folder doesn't support SAVEDATE >>> 2) reject the command if none of the folders support SAVEDATE >>> 3) succeed regardless of the support for SAVEDATE >>> >>> And if there are folders that don't support SAVEDATE for case >>> 2 or 3,>>> you can: >>> a) use the INTERNALDATE instead >>> b) don't match the message >>> >>> I think (a) is clearly wrong here - if you're deleting everything >>> that's SAVEDBEFORE 1 month ago from a Trash folder, then >>> INTERNALDATE>>> will purge things before you want to. >> Yes, indeed. >> >>> The alternative is to treat SAVEDATE as NULL in the same way >>> SQL does,>>> and I think that's the right choice. So you can say "SEARCH NOT >>> SAVEDAFTER {X} BEFORE {X}" if you want to get the behaviour of >>> deleting everything that was SAVEDBEFORE a time, or fallback to >>> INTERNALDATE if it's not supported. >> I see what you're trying to do here and I agree that something >> like that>> would be a good idea. However, we need to be very careful about the>> semantics. With SQL 3-valued logic, I think (with my rather limited >> SQL-fu) your example would evaluate to Unknown: >> >> `NOT SAVEDAFTER {X} BEFORE {X}' logically translates to: >> >> (not `SAVEDAFTER {X}') and `BEFORE {X}' >> (not Unknown) and `BEFORE {X}' >> Unknown and `BEFORE {X}' >> Unknown >> >> So, how did you expect this example to work? Or am I doing something>> wrong in this inference? > > 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 -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151894824218107030 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi Stephen, sorry about missing replying on this - it came through in the week I was really sick and I didn't get back to it!

Let's look at it with SQL (sqlite in this case):

id|internaldate|savedate
1|2018-01-01|2018-01-01
2|2018-01-01|2018-02-01
3|2018-02-01|2018-02-01
4|2018-01-01|
5|2018-02-01|

table 'foo' - with rows 4 and 5 having NULL savedate.  We want to select rows 1 and 4 without getting row 2.

Yeah, you're right:

sqlite> select * from foo where not savedate > '2018-01-30' and internaldate < '2018-01-30';
id|internaldate|savedate
1|2018-01-01|2018-01-01
sqlite> select * from foo where (savedate is null or not savedate > '2018-01-30') and internaldate < '2018-01-30';
id|internaldate|savedate
1|2018-01-01|2018-01-01
4|2018-01-01|
sqlite>

Well, that's a pain.  I definitely want a way to say that second expression - because that's what I would be working with if I wanted to be able to select "old" messages regardless of whether SAVEDATE was supported.

I guess in this particular case, the idea of "fall back to internaldate only if savedate isn't defined" would be exactly what I wanted, but then maybe I'd want SAVEDBEFORESTRICT and SAVEDBEFORERELAXED :p  Horrible names though.

Mind you, with IMAP semantics you don't have Undefined, so having SAVEDBEFORE and SAVEDAFTER both always evaluate false if you don't have support would give the behaviour that my expression wants.

Bron.

On Fri, 16 Feb 2018, at 09:31, Stephan Bosch wrote:
Hi Bron,

Any word on the questions I asked below?

Op 1/28/2018 om 3:51 PM schreef Stephan Bosch:
Op 1/7/2018 om 11:04 PM schreef Bron Gondwana:
On Mon, 8 Jan 2018, at 00:04, Stephan Bosch wrote:
Hi Bron,

Op 1/4/2018 om 1:54 AM schreef Bron Gondwana:

  2: if the mailbox doesn't support storing save date, the SEARCH
  extensions should return an error if used, rather than a result,
  since
  there's no way to calculate a sensible answer to any of those three.


Ok, for the sake of discussion, I added text with this effect in the
last version. However, I am not quite happy with it yet. Returning an
error seems a bit harsh. Do we need to provide some means for the client
to find out whether the mailbox supports the save date attribute before
trying to use it?
That could be done:

TAG select "foo"
* 1 EXISTS
* 1 RECENT
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Seen \*)] Ok
* OK [UNSEEN 1] Ok
* OK [UIDVALIDITY 1515362059] Ok
* OK [UIDNEXT 2] Ok
* OK [HIGHESTMODSEQ 7] Ok
* OK [URLMECH INTERNAL] Ok
* OK [ANNOTATIONS 65536] Ok
TAG OK [READ-WRITE] Completed

Another line in there that said something like:

* OK [SAVEDATE] Ok

Would probably work fine.
Yes, that could work. Although, when the SQL NULL semantics (discussed
below) are implemented, this would likely no longer be necessary/useful.

Also, there's the MULTISEARCH extension (RFC7377), which adds an ESEARCH
command that allows searching across a wide selection of mailboxes, some
of which may in fact lack support for the save date attribute. What is
to be done in that case? Fail the whole ESEARCH command? Ignore the
mailboxes that lack support? Make the SAVED* search items yield a false
result for that mailbox? None of these options seem very appealing.
There are three choices:
1) reject the command if any folder doesn't support SAVEDATE
2) reject the command if none of the folders support SAVEDATE
3) succeed regardless of the support for SAVEDATE

And if there are folders that don't support SAVEDATE for case 2 or 3,
you can:
a) use the INTERNALDATE instead
b) don't match the message

I think (a) is clearly wrong here - if you're deleting everything
that's SAVEDBEFORE 1 month ago from a Trash folder, then INTERNALDATE
will purge things before you want to.
Yes, indeed.

The alternative is to treat SAVEDATE as NULL in the same way SQL does,
and I think that's the right choice.  So you can say "SEARCH NOT
SAVEDAFTER {X} BEFORE {X}" if you want to get the behaviour of
deleting everything that was SAVEDBEFORE a time, or fallback to
INTERNALDATE if it's not supported.
I see what you're trying to do here and I agree that something like that
would be a good idea. However, we need  to be very careful about the
semantics. With SQL 3-valued logic, I think (with my rather limited
SQL-fu) your example would evaluate to Unknown:

`NOT SAVEDAFTER {X} BEFORE {X}' logically translates to:

(not `SAVEDAFTER {X}') and `BEFORE {X}'
(not Unknown) and `BEFORE {X}'
Unknown and `BEFORE {X}'
Unknown

So, how did you expect this example to work? Or am I doing something
wrong in this inference?

Regards,

--
Stephan Bosch
Senior Developer


Phone: +49 2761 75252 00  Fax: +49 2761 75252 30


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

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_151894824218107030-- From nobody Mon Feb 26 06:20:28 2018 Return-Path: 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 584641242F5 for ; Mon, 26 Feb 2018 06:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TZJa0_TCs360 for ; Mon, 26 Feb 2018 06:20:26 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A5D12D7E6 for ; Mon, 26 Feb 2018 06:20:26 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id f4so18907802qtj.6 for ; Mon, 26 Feb 2018 06:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=JNydlgAt++KxOrZGBDMRDPKk0rl3N8YXeGt4HmWI3pE=; b=Fo0KVBw5QRPhzB7gXhzatYhxbXpgdisEN+jKsI/QGPiHi14KGwuXORvRv8+nSI8ez2 4Fpo/rt+7hDndK4jd8Qh3E7B6yILvRQIEQhAVUzxThmQAu71RYVSQGlVnf5chI/WpxKc MpU5B2YAx9W1CfnADQHVm+ArpPgi7zhSNKKDHx+KTfY+zZNCKgT8/YsG5I0JdAPanCFa rL4DEkHtDrTWl9nZey+54IubJgoq/znqYRREVa2WRznefAXR/DRpCQyFglkZV9FqrIAM 60Iv5L4jdl1CuR9tLeAPiHVzCX6QMcF+PJxOJkgWy676lJ19W29WgCCi/DePMZ/3ZI7j 9R7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=JNydlgAt++KxOrZGBDMRDPKk0rl3N8YXeGt4HmWI3pE=; b=sg/uqjTB6UnIRRwIZz287XBWzF3EiXwCxvY1NdPDpLPB1DTx7uLlvuGhSg2lih9PZH 4twPnOqpIbLMehkkUL6rWaMovPgnMi+fXOvZGXWItAQbarQMKspMVqIJq3lyGz3mWVwR fzNs2Ek/HwN6Ovv01UBZ637zP2wG3O6U7jCETqfQSuwmSRyMl3yDKvaEB5U+A2Wv59hx nEZHm6oCig4oBVLiRJ24BQPXBryt8KxstF9vYiO7Rab1I2hwed7GNT1jhTJ4Rzc08zKp 8gHGg/9eMoHEpyq3xlqD1elMt70kdretrNH6FYhgDeTBHS2+QhR4jtV5mNYJhWcdbHh5 WLdQ== X-Gm-Message-State: APf1xPA4gK86z99Q4OG+t0WQqJP79exea8VphS9zZ4UOLRCTVfhOH67k uIRjVTXP41hqquC2qBMaqyDrHaxXFf95713dOWxPnw== X-Google-Smtp-Source: AG47ELvKkRzwM2sLP64+4K3mu256DA8wRrHWfN4kshpT3l5r/Rlq1lZtUljHHY+EL6TkmmJCmjKG5xW2sPcjY8XcgEw= X-Received: by 10.200.13.75 with SMTP id r11mr6695203qti.133.1519654824911; Mon, 26 Feb 2018 06:20:24 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.3.162 with HTTP; Mon, 26 Feb 2018 06:20:24 -0800 (PST) In-Reply-To: References: <20171115160621.GC17058@meili> <1510799355.3640467.1174131992.15AF5270@webmail.messagingengine.com> <1e08751e-eb51-7fc6-eb39-214eca7f48af@isode.com> From: Barry Leiba Date: Mon, 26 Feb 2018 06:20:24 -0800 X-Google-Sender-Auth: TfYWHbwoA383QxbGkyKgWTW1aro Message-ID: To: extra@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Extra] "IMAP $Important Keyword and \Important Special-Use Attribute" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 14:20:27 -0000 I've posted draft-leiba-extra-specialuse-important-01, which has the two text changes discussed here. Does the working group want to take this as a working-group document? Barry On Fri, Feb 9, 2018 at 8:34 AM, Barry Leiba wrote: >> As I see it, the distinction between \Flagged and $Important is too subtle >> to be reliably implemented and understood. > > Hm. > The intent here is this: > > On the server side: > > - \Flagged is set or cleared in response to an explicit command from > the client. > > - $Important is set via a heuristic process performed by the server, > usually involving analysis of header fields, what mailbox the message > is filed in, perhaps message content, attachments, and such. It may > then be set or cleared in response to an explicit command from the > client, and the server may use that to adjust the heuristics in the > future. It's also possible that the server will re-evaluate this and > make a message $Important later if the user accesses the message > frequently, for example. > > On the client side: > > - Typically, an icon such as a flag or a star, or an indication such > as red or bold text, is associated with \Flagged, and the UI provides > a way for the user to turn that icon or indication on or off. > Manipulation of the this results in a command to the server. > > - Typically, a lesser indication is used for $Important. The client > might or might not provide the user with a way to manipulate it. If > it does, manipulation results in a command to the server. > > Does that help you make an implementable distinction? Would it help > to include a non-normative section of the document describing how this > is typically handled? > > Barry From nobody Mon Feb 26 16:38:04 2018 Return-Path: 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 C201E12D95A for ; Mon, 26 Feb 2018 16:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=T0RbMVea; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MhrXmISi 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 PYqOiedBsdaa for ; Mon, 26 Feb 2018 16:38:01 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E934C12D959 for ; Mon, 26 Feb 2018 16:38:00 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ED26C20D61 for ; Mon, 26 Feb 2018 19:37:59 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 26 Feb 2018 19:37:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=S+nEpgqPJB6sZ6pAoA/Jl5BBcmCh7gkmDyHVzPxnx Gs=; b=T0RbMVea5QRzjvJhpam1K+b5eHntY74EGPFraC8PMSB29DPMLgbhy8mMN yFoOTA/UMN+Jfy42MelFaqqnzuyZpwSKXfcaFThAaGWeUyEWAmiOJAFTYcuS+Txx 4d4MFTjiyfTgNoGHqHJzsjFhO+TBLjEMyEKsbWFmxBJcZ2fPuyypbCziFlZfZ/BQ hfQXSSEGIuOoWwJrAZMpjOc1gBnrrvza/4+nVE3QbCmO0X/Z1VDugtjAgwtTq1rY jLjNmOa0MMnB7aDHuO8RWtDvF20AslQZlEeeBNcIwjOuR9cG26yNSYCGuiSPZibN 52SWWyLqL1bWRzxUrj6pYRmHqcNPQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=S+nEpgqPJB6sZ6pAoA/Jl5BBcmCh7 gkmDyHVzPxnxGs=; b=MhrXmISib4USeHlzpFfh3Hw1/zEEx2CU2p6tQUx0tBFnj Z+yrm30dXrL39uTsAcrVmev1s2PSxTFcu+IPkiBbv3QDhQIrwHcjFbc1B5Lo89w0 vTkJBjBtS6tv3IMeCTM5glW9ZERm3sflUgP82NMBuAwTMNAPbrhu/4sEDs3RDzHI GAbcSdrLs6aMPl5dM7N5YpPLM5VGPBHqh9c2/VqkKPIpsP0Bk2AAU99To/Wud5yB qokuUqhIoMAl9vmb+TsOK0hzvFyFEHfl/IRWirzHIneMtBf0fQT7EK3lqGTlnHW+ B/Cqv5roCQVDb8EFXO1XwA/BBWXS8swoHgL2x5xMw== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C54459E0E2; Mon, 26 Feb 2018 19:37:59 -0500 (EST) Message-Id: <1519691879.2831523.1284423560.70A87A64@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151969187928315234" X-Mailer: MessagingEngine.com Webmail Interface - ajax-efbb3405 Date: Tue, 27 Feb 2018 11:37:59 +1100 Archived-At: Subject: [Extra] Spam Reporting? X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 00:38:03 -0000 This is a multi-part message in MIME format. --_----------=_151969187928315234 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" 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? Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151969187928315234 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Digging through my very old FLAGGED emails to see if there was anything I should be looking at, this sprung up:


In a discussion from Alexey following on from my Fosdem report at the time:


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?

Bron.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_151969187928315234-- From nobody Tue Feb 27 15:14:31 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A4812EABD; Tue, 27 Feb 2018 15:11:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: extra@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977307310.5200.735751645526529219.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:13 -0800 Archived-At: Subject: [Extra] extra - Requested session has been scheduled for IETF 101 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:13 -0000 Dear Bron Gondwana, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. extra Session 1 (1:00:00) Thursday, Morning Session I 0930-1200 Room Name: Palace C size: 50 --------------------------------------------- Special Note: 0930 - 1030 Request Information: --------------------------------------------------------- Working Group Name: Email mailstore and eXtensions To Revise or Amend Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap dmarc regext dispatch dcrup doh uta Second Priority: oauth saag tls ace dnsop calext People who must be present: Alexey Melnikov Jiankang Yao Bron Gondwana Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Flipcharts: please specify number in Special Requests field Special Requests: One flipchart please --------------------------------------------------------- From nobody Wed Feb 28 00:04:07 2018 Return-Path: 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 E0E6D1243F6 for ; Wed, 28 Feb 2018 00:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6nioZwyGJTEZ for ; Wed, 28 Feb 2018 00:04:02 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2F597124207 for ; Wed, 28 Feb 2018 00:04:02 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id EEB402CED40; Wed, 28 Feb 2018 10:03:57 +0200 (EET) To: Bron Gondwana , extra@ietf.org References: <1515027295.3130822.1223568456.6D1D8F15@webmail.messagingengine.com> <1515362666.2687647.1227253816.726EA133@webmail.messagingengine.com> <7d5e0617-cba4-c19c-8426-64f2a9e8f1eb@dovecot.fi> <64ce2646-958d-0a0c-c63a-8e15641380b0@dovecot.fi> <1518948242.1810703.1274657584.3EEDD661@webmail.messagingengine.com> From: Stephan Bosch Message-ID: <21fc0c57-36bd-b942-8727-1c3356f4bac8@dovecot.fi> Date: Wed, 28 Feb 2018 09:03:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1518948242.1810703.1274657584.3EEDD661@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] SAVEDATE updated required X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 08:04:05 -0000 Hi Bron, Op 2/18/2018 om 11:04 AM schreef Bron Gondwana: > Hi Stephen, sorry about missing replying on this - it came through in > the week I was really sick and I didn't get back to it! I haven't been having much time myself either lately. > > Let's look at it with SQL (sqlite in this case): > > id|internaldate|savedate > 1|2018-01-01|2018-01-01 > 2|2018-01-01|2018-02-01 > 3|2018-02-01|2018-02-01 > 4|2018-01-01| > 5|2018-02-01| > > table 'foo' - with rows 4 and 5 having NULL savedate.  We want to > select rows 1 and 4 without getting row 2. > > Yeah, you're right: > > sqlite> select * from foo where not savedate > '2018-01-30' and > internaldate < '2018-01-30'; > id|internaldate|savedate > 1|2018-01-01|2018-01-01 > sqlite> select * from foo where (savedate is null or not savedate > > '2018-01-30') and internaldate < '2018-01-30'; > id|internaldate|savedate > 1|2018-01-01|2018-01-01 > 4|2018-01-01| > sqlite> > > Well, that's a pain.  I definitely want a way to say that second > expression - because that's what I would be working with if I wanted > to be able to select "old" messages regardless of whether SAVEDATE was > supported. > > I guess in this particular case, the idea of "fall back to > internaldate only if savedate isn't defined" would be exactly what I > wanted, but then maybe I'd want SAVEDBEFORESTRICT and > SAVEDBEFORERELAXED :p  Horrible names though. > > Mind you, with IMAP semantics you don't have Undefined, so having > SAVEDBEFORE and SAVEDAFTER both always evaluate false if you don't > have support would give the behaviour that my expression wants. > So, what do we do here? In at least some storage implementations, Dovecot reverts to using the current date instead, storing it in cache after that time, so that at least something is remembered. Regards, Stephan. > Bron. > > On Fri, 16 Feb 2018, at 09:31, Stephan Bosch wrote: >> Hi Bron, >> >> Any word on the questions I asked below? >> >> Op 1/28/2018 om 3:51 PM schreef Stephan Bosch: >> >> Op 1/7/2018 om 11:04 PM schreef Bron Gondwana: >> >> On Mon, 8 Jan 2018, at 00:04, Stephan Bosch wrote: >> >> Hi Bron, >> >> Op 1/4/2018 om 1:54 AM schreef Bron Gondwana: >> >>   2: if the mailbox doesn't support storing save date, >> the SEARCH >>   extensions should return an error if used, rather than >> a result, >>   since >>   there's no way to calculate a sensible answer to any of >> those three. >> >> >> Ok, for the sake of discussion, I added text with this >> effect in the >> last version. However, I am not quite happy with it yet. >> Returning an >> error seems a bit harsh. Do we need to provide some means >> for the client >> to find out whether the mailbox supports the save date >> attribute before >> trying to use it? >> >> That could be done: >> >> TAG select "foo" >> * 1 EXISTS >> * 1 RECENT >> * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) >> * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Seen \*)] Ok >> * OK [UNSEEN 1] Ok >> * OK [UIDVALIDITY 1515362059] Ok >> * OK [UIDNEXT 2] Ok >> * OK [HIGHESTMODSEQ 7] Ok >> * OK [URLMECH INTERNAL] Ok >> * OK [ANNOTATIONS 65536] Ok >> TAG OK [READ-WRITE] Completed >> >> Another line in there that said something like: >> >> * OK [SAVEDATE] Ok >> >> Would probably work fine. >> >> Yes, that could work. Although, when the SQL NULL semantics >> (discussed >> below) are implemented, this would likely no longer be >> necessary/useful. >> >> Also, there's the MULTISEARCH extension (RFC7377), which >> adds an ESEARCH >> command that allows searching across a wide selection of >> mailboxes, some >> of which may in fact lack support for the save date >> attribute. What is >> to be done in that case? Fail the whole ESEARCH command? >> Ignore the >> mailboxes that lack support? Make the SAVED* search items >> yield a false >> result for that mailbox? None of these options seem very >> appealing. >> >> There are three choices: >> 1) reject the command if any folder doesn't support SAVEDATE >> 2) reject the command if none of the folders support SAVEDATE >> 3) succeed regardless of the support for SAVEDATE >> >> And if there are folders that don't support SAVEDATE for case >> 2 or 3, >> you can: >> a) use the INTERNALDATE instead >> b) don't match the message >> >> I think (a) is clearly wrong here - if you're deleting everything >> that's SAVEDBEFORE 1 month ago from a Trash folder, then >> INTERNALDATE >> will purge things before you want to. >> >> Yes, indeed. >> >> The alternative is to treat SAVEDATE as NULL in the same way >> SQL does, >> and I think that's the right choice.  So you can say "SEARCH NOT >> SAVEDAFTER {X} BEFORE {X}" if you want to get the behaviour of >> deleting everything that was SAVEDBEFORE a time, or fallback to >> INTERNALDATE if it's not supported. >> >> I see what you're trying to do here and I agree that something >> like that >> would be a good idea. However, we need  to be very careful about the >> semantics. With SQL 3-valued logic, I think (with my rather limited >> SQL-fu) your example would evaluate to Unknown: >> >> `NOT SAVEDAFTER {X} BEFORE {X}' logically translates to: >> >> (not `SAVEDAFTER {X}') and `BEFORE {X}' >> (not Unknown) and `BEFORE {X}' >> Unknown and `BEFORE {X}' >> Unknown >> >> So, how did you expect this example to work? Or am I doing something >> wrong in this inference? >> >> >> 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 > > -- >   Bron Gondwana, CEO, FastMail Pty Ltd >   brong@fastmailteam.com > > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- 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 ------------------------------------------------------------------------------------- From nobody Wed Feb 28 00:21:00 2018 Return-Path: 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 E290112D86A for ; Wed, 28 Feb 2018 00:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 A3IcQRBw-Lfd for ; Wed, 28 Feb 2018 00:20:53 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id A4C1112E039 for ; Wed, 28 Feb 2018 00:20:40 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id A10602CED40; Wed, 28 Feb 2018 10:20:39 +0200 (EET) To: Bron Gondwana , extra@ietf.org References: <1519691879.2831523.1284423560.70A87A64@webmail.messagingengine.com> From: Stephan Bosch Message-ID: <60235340-1514-fca2-2e34-73683a5c247b@dovecot.fi> Date: Wed, 28 Feb 2018 09:20:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1519691879.2831523.1284423560.70A87A64@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] Spam Reporting? X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 08:20:58 -0000 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 ------------------------------------------------------------------------------------- From nobody Wed Feb 28 11:29:25 2018 Return-Path: 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 BD12C12025C for ; Wed, 28 Feb 2018 11:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.net 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 QSciawvfPA3N for ; Wed, 28 Feb 2018 11:29:20 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C001200E5 for ; Wed, 28 Feb 2018 11:29:20 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id l187so4882312ith.4 for ; Wed, 28 Feb 2018 11:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GwpbbyAv0cneTgfY0LMGWaNNnjLrISfVnoeMPlppW+4=; b=ADZwAm4g4A2lpTTibhwm7o+3lzvQIin9fiT6oS8qMznwOqWmYRVWBBVlQq1LoqWOLD w48wHmGc8r+MwoEG0ejQAx5DQN2qOJCHPstffOfy1TghAXimcyd/9rE3tPLFyocGcwAA JPmpM/eI3gEHpW+shEB87BjVE7krSXPqNs5CbIHY+k6Q6N//S6OkVeVccJZD052KpQXq lEzPNH2XHHV52Q3hF7Wt08jqcUyAWqriZLVywCv9e46dNWAeOoS1+PNIKaG/+bfz16E5 NLGFBkaj190eUJy7HL1j+6JAHSYFENiPWvwKhAGVre8+A1kD4PuJykCJbBrTgBJNjo5g pEnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GwpbbyAv0cneTgfY0LMGWaNNnjLrISfVnoeMPlppW+4=; b=PkMDejYBd6wTWc6WAuwk+/dpnk+E2LPLeKVtx7of/iohALc9RhwEpJOcTfgYUyRmU8 h4aky8SG5i9W0XtmklLxPvgRC2IXSM3XdsIzdpVKT3LcHuN8vGnzoC899erjii+yIP08 ZgpHyXt+JJeokoit0iAxGJD0/e5jNZwjwUNaxJdEQ7wMyo3PsWW+rKB9Ehvbhnhjd9yp tPd+eZW5vzmuyazodzFTs/8IFFMUZBDpmOMe7hZXJcBXq0hS0m5jWPpPi3+CMTR85qNH ZfrPP0ADv3UuWE3Ha20crMHfr0rWSSXgKnLSliF4nbKbyo4bMUxPPAyD/DpndMYAODWL BAOQ== X-Gm-Message-State: APf1xPDlo6DGBtWl/W5TgG6asgVqIXuuEl0oCGsD6P7VkvbUr6yC+Rtf yf+oCRCmX93UmexZRTmsWk+/eN51 X-Google-Smtp-Source: AG47ELtDN3OKTl2vfN+xdKzE8QMksU6QnWuDBKUJgsCoaW7+KAozGBdYDszzqwVHoVEI3lC0fKuiMA== X-Received: by 10.36.113.67 with SMTP id n64mr22069886itc.4.1519846159260; Wed, 28 Feb 2018 11:29:19 -0800 (PST) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id m203sm2047844itd.26.2018.02.28.11.29.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 11:29:18 -0800 (PST) Received: by mail-io0-f179.google.com with SMTP id 30so4467007iog.2 for ; Wed, 28 Feb 2018 11:29:18 -0800 (PST) X-Received: by 10.107.192.2 with SMTP id q2mr22297165iof.112.1519846157547; Wed, 28 Feb 2018 11:29:17 -0800 (PST) MIME-Version: 1.0 References: <1519691879.2831523.1284423560.70A87A64@webmail.messagingengine.com> <60235340-1514-fca2-2e34-73683a5c247b@dovecot.fi> In-Reply-To: <60235340-1514-fca2-2e34-73683a5c247b@dovecot.fi> From: Brandon Long Date: Wed, 28 Feb 2018 19:29:06 +0000 X-Gmail-Original-Message-ID: Message-ID: To: stephan.bosch@dovecot.fi Cc: Bron Gondwana , extra@ietf.org Content-Type: multipart/alternative; boundary="001a114f74c45633f605664ac2d5" Archived-At: Subject: Re: [Extra] Spam Reporting? X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 19:29:24 -0000 --001a114f74c45633f605664ac2d5 Content-Type: text/plain; charset="UTF-8" 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 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 > --001a114f74c45633f605664ac2d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 c= an certainly trigger whatever it needs off of applying the keyword or havin= g a message moved/copied to the junk folder, so I'm unclear on the need= for an explicit command.

Sure, bulk application o= f either of these should be interpreted with some level of skepticism, I kn= ow our original implementation had a cut-off for a max number we'd allo= w in a single command, and it's had to evolve over time based on inform= ation about the client used and the reputation of the user, at least in reg= ards to using the spam labeling to enform the larger anti-spam system, loca= l changes such as personalized blocked sender lists or personalized learnin= g seem fine even in bulk.=C2=A0 Given the potential for bad actors, these t= ypes of requirements will come up even if you have a specific command, of c= ourse.

Even in the Gmail API, we went with just ad= ding 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:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">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.iet= f.org/doc/draft-ordogh-spam-reporting-using-imap/
>
> In a discussion from Alexey following on from my Fosdem report at the<= br> > time:
>
> https://www.mail-archi= ve.com/search?l=3Dcyrus-devel%40lists.andrew.cmu.edu&q=3Dsubject%3A%22F= OSDEM+Report+%5C-+Saturday%22&x=3D0&y=3D0
>
> Is there any appetite for reviving discussion of a standard way to
> report spam/phishing/whatever from clients such that the server knows<= br> > 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-s= ieve-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=C2=A0 Fax: +49 2761 75252 30
Email: stepha= n.bosch@dovecot.fi


---------------------------------------------------------------------------= ----------
Open-Xchange AG,=C2=A0 Rollnerstr. 14, 90408 Nuremberg, District Court Nure= mberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein<= br> 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
--001a114f74c45633f605664ac2d5-- From nobody Wed Feb 28 12:46:53 2018 Return-Path: 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 49624126BF7 for ; Wed, 28 Feb 2018 12:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=B4PdS9kV; dkim=pass (1536-bit key) header.d=taugh.com header.b=W4PpsEWG 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 EGpULBAbPc90 for ; Wed, 28 Feb 2018 12:46:50 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385C1126B6E for ; Wed, 28 Feb 2018 12:46:50 -0800 (PST) Received: (qmail 64587 invoked from network); 28 Feb 2018 20:46:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=fc49.5a971539.k1802; bh=34421lEjHgLPqf3dRWaoYAJgpSnROnWMYs5PXIp1FFs=; b=B4PdS9kVTz05L8HtiPWXZAdTj/GMO3OmDtcyw/Bf/4qgUarDpATMdgHNuw5UUZrjO90DLA+rOFnUDGDrwDx/Jfob1p9cpTogZZZ4NjF7HbHuqWOOUgp3uCcMv+VuGyzuUNWdsx7B7z9eGUvYTLU16KR20xXX7sHKfC1g3jDHZKeHKVTBvLdqXP/1Jz5j327PzcE+pzUY9NyzmwUMmtDb3Kpgj7wwlzSsJAW9CtyqWBwlqQ9m2XpBUCZ7W/dVWmc+ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=fc49.5a971539.k1802; bh=34421lEjHgLPqf3dRWaoYAJgpSnROnWMYs5PXIp1FFs=; b=W4PpsEWGK/LN4+5zb3/em8297JRS0cou/Gdimylz/j0H4ai/O1tCLQNortkCXbY7zhoiNphJgMvLpD4x8NRdGNKg3OkskGoihK11CvbuJE0doKwdvISB0EtckUJm9y1gU04ADc9W/Vvb3JAmTHWrHCNQ8IkXxwspw0KC16yvMftPYO2ErZ11FsVIIpBDJM0g5zAMEtjiS49Vz/UgXhdLY1M7lDo430bpKAZ3fj8EOMBcvt3jH48OBulBn6U4EZJ0 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 28 Feb 2018 20:46:49 -0000 Received: by ary.qy (Postfix, from userid 501) id E59ED1E3E783; Wed, 28 Feb 2018 15:46:48 -0500 (EST) Date: 28 Feb 2018 15:46:48 -0500 Message-Id: <20180228204648.E59ED1E3E783@ary.qy> From: "John Levine" To: extra@ietf.org Cc: blong@fiction.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Extra] Spam Reporting? X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 20:46:51 -0000 In article you write: >> 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. Even when a mail program has an explicit SPAM or JUNK button, you never really know what the user intended. It might be "this is an evil phish" or it might be "I subscribed to this legit list but don't want it any more" or it might just be "there's too much mail in my inbox so make it go away." Since we already have a \Junk folder, it seems to me that the way one puts messages in it is a user interface issue and not one we should try to solve. R's, John PS: $Junk may not be a standard but it seems to be a favorite example. See RFCs 5182, 5267, and 5465. From nobody Wed Feb 28 16:24:02 2018 Return-Path: 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 3318F1270AC for ; Wed, 28 Feb 2018 16:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=a1+f/K6u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DUE7ozUv 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 Dq6fN5Q4dPBc for ; Wed, 28 Feb 2018 16:23:59 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3CA120724 for ; Wed, 28 Feb 2018 16:23:59 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B73BC20CF8; Wed, 28 Feb 2018 19:23:58 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 28 Feb 2018 19:23:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=xfRSkjLaCaIG6sa70 uoENslJ1am143LkaAEt6jg4G/Y=; b=a1+f/K6u6e8jMCX4MaknS9iM5alDJCCJn 9rkXFlQ+kZyG9XDLzjz5tQnLpsRywJbHj+fpWoJkULrhVVQcwsfKT4hVYDoTFZv8 gQqvpKND9z5hxH8A6kDqearw1Jk69iNJ6xiHqaQ+OFQk7DcFx3IjAr+6rz1T7v5L kAxsjj7BqP1Y7Ejwik0g94Vcro350dwskEY5Gys51ul9U/cro6rRM/vys5ZJPXQX rZmziqVt3QqDilz12i91oUI0mE3bfORdcazmeXIEEiyq472qoDuFua4vMbGsnynb 7FHItAbkZH2D+mnlXBtZzw7FWtrPkAYzPSM8e5MKjUUtPSdU6P8bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=xfRSkj LaCaIG6sa70uoENslJ1am143LkaAEt6jg4G/Y=; b=DUE7ozUvApur2v9ykAkW0q gi5oFH2VZwOuCLIWW9Bhekvj/AXibLhgxDsIB8Fa90G7ruhn06t17JxRtfh9ZHEq eBfYasM6kYi306hlJOv6rZRqzL81MAuKHReQISNfPhnEheV8UCZbE8qitVmN0xfK UhGgCGjAEJ1z+y28P9/jLSqkgkteuVD2rGmyoZrxggRZC/jQJCg8rciAvVVdo2jy Yp5S+atrYvC/+iEWGB281XdiHOHVa23XAlsZwf9rctTZ/qkvqY5QHuNN6sX//Zgq FylbWjvD8afWgFM6dtP+n56uNU/UfWHkwSXj8hUORCb4YG9MZee7j770mQtO9Kog == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id 6760A7E3CE; Wed, 28 Feb 2018 19:23:58 -0500 (EST) References: <20171115160621.GC17058@meili> <1510799355.3640467.1174131992.15AF5270@webmail.messagingengine.com> <1e08751e-eb51-7fc6-eb39-214eca7f48af@isode.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <282DF82F-92FF-4EEC-B1CF-54EE475AB898@glyphein.mailforce.net> Cc: extra@ietf.org X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Wed, 28 Feb 2018 19:23:56 -0500 To: Barry Leiba Archived-At: Subject: Re: [Extra] "IMAP $Important Keyword and \Important Special-Use Attribute" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 00:24:01 -0000 Hi Barry, > On Feb 26, 2018, at 9:20 AM, Barry Leiba wrote: >=20 > I've posted draft-leiba-extra-specialuse-important-01, which has the > two text changes discussed here. I've only been able to take a quick look at this document, but in line 113, t= he phrase "specific meaning of general" strikes me as a bit awkward. So I s= uggest the OLD: 1. "$Important" carries a specific meaning of general importance, as be rephrased as, NEW: 1. "$Important" specifies a meaning of general importance, as or, 1. "$Important" denotes a meaning of general importance, as , etc. Thanks, Stan From nobody Wed Feb 28 16:50:47 2018 Return-Path: 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 0E6C912946D for ; Wed, 28 Feb 2018 16:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=DitQQvMP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WdKdhVXA 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 N7CKkx5Phpx9 for ; Wed, 28 Feb 2018 16:50:44 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26A8127275 for ; Wed, 28 Feb 2018 16:50:43 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3F10E20C01 for ; Wed, 28 Feb 2018 19:50:43 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 28 Feb 2018 19:50:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=SzUSHsiPhxU9WXC5mQDu8wmkjKjVO 1N17QOjKtVe4kM=; b=DitQQvMPxFjTeWDTuKG2XvQx1mNrrvl5wnABb59U6FoDO pAgzS7z5BVJrWfTzHiFYVp9PPve7dkQUXdhm1X1MyjrxmednOgNauNreEZQ7m/zz qWb/Sdrh6bw28MiA53ynkU4dhvSIlV8v6X53WxDensh9hJ3GC0pi9+JQUqzvoHL+ yx1I4m8KrbIyPPGF+4TEicNDsurquNTIPFB4QtUDJNoCEInfbZdf1R64DE5HMLlD hjDUlm7V2ipTRzXyWbQm7HYtK877X1I7FLqsUMkikb4FQVzfBG4HcMr0q59ZrtYv PZmFSOFWPNXOh5p79bKIa3wMxHyQKdGvayhXe7GJw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=SzUSHs iPhxU9WXC5mQDu8wmkjKjVO1N17QOjKtVe4kM=; b=WdKdhVXAwN/NsGCLNNFEAX P5JsQSKeouq8A9lxwJdCQd3UIGZ1yl3Q7QfK6NtQbUv/s8a+0mVbtwNY69izuOiZ N3kYS5JjX/+iEXNs+pI73PZXOFmQFH4Y4UhYwqRY9LDcPNmTYO4P4yosUs1sKg4n zUO5PneasLsg/Vd1W1P659vv445gCEDwnnMPVzDjQ+dRcpK05vB42QYM9lJy4itE keofPU28AymMZVbVTORgwUYoPn/Dp5p6e8v+hMPw44iBT/c5dQB9A6Uiy9RitsL6 ro8hyosy2+LNGOjH8ASfTQ8CkLgwalc9qAq2R6yqD0UF0lUMD5YeAtz4thHEeNvA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 07AE29E111; Wed, 28 Feb 2018 19:50:42 -0500 (EST) Message-Id: <1519865442.2416452.1287190632.1B2ADB9C@webmail.messagingengine.com> From: Robert Mueller To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b08ff009 References: <20180228204648.E59ED1E3E783@ary.qy> Date: Thu, 01 Mar 2018 11:50:42 +1100 In-Reply-To: <20180228204648.E59ED1E3E783@ary.qy> Archived-At: Subject: Re: [Extra] Spam Reporting? X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 00:50:45 -0000 > PS: $Junk may not be a standard but it seems to be a favorite example. > See RFCs 5182, 5267, and 5465. It is a registered IMAP keyword along with $NotJunk ----- https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml Purpose (description): The user (or a delivery agent on behalf of the user) may choose to mark a message as definitely containing junk ($Junk; see also the related keyword $NotJunk). The $Junk keyword can be used to mark (and potentially move/delete messages later), group or hide undesirable messages. ----- -- Rob Mueller robm@fastmail.fm