From alexey.melnikov@isode.com Thu Apr 4 02:39:21 2013 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3365721F95DB for ; Thu, 4 Apr 2013 02:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.99 X-Spam-Level: X-Spam-Status: No, score=-101.99 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwUAM4gQVs1d for ; Thu, 4 Apr 2013 02:39:20 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 8982F21F946B for ; Thu, 4 Apr 2013 02:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1365068359; d=isode.com; s=selector; i=@isode.com; bh=JaDIBDQ5rYNh+U5rEuoOgEKNnJ+C2+cNyMXo6x886As=; 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=SM6TQ2k1r5xq0D5gJpk8l8Z3fnw/i3OoxgsbpVbeCvhf6RFtBeqG+d57WZSTaz0m1NWwNt tygRMNdXg6QPShOkoRRXYaLZex8aFa87TRQeXe/U+EaE4PMyvn6II4SC68WNp2a3ylk4C3 WhBcYBrZmiB1U+xz7211n9k76kRBvNA=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 4 Apr 2013 10:39:19 +0100 Message-ID: <515B1F8E.5010202@isode.com> Date: Tue, 02 Apr 2013 19:12:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Stephan Bosch , Ned Freed References: <20130210000420.4778.87812.idtracker@ietfa.amsl.com> <5116E5ED.20307@rename-it.nl> <513B1839.3050202@rename-it.nl> <01ORB1SUSLYS000054@mauve.mrochek.com> <514AF7A9.3040502@rename-it.nl> In-Reply-To: <514AF7A9.3040502@rename-it.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sieve mailing list Subject: Re: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-01.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 09:39:21 -0000 On 21/03/2013 12:06, Stephan Bosch wrote: > Hi Ned, > > Op 3/15/2013 6:39 PM, Ned Freed wrote: [...] >> (2) I'm wondering if it wouldn't be best to suggest a default timeout. >> 12 hours? A day? > It can be useful. Anyone else got suggestions or comments about this? I have no objection to something like 1 day, but why do we want to make it different from "vacation", which uses 7 days, if I am not mistaken. (I don't have strong preference in favour of 7 days.) From stephan@rename-it.nl Sun Apr 7 09:48:50 2013 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E77F21F85DA for ; Sun, 7 Apr 2013 09:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAZNBkXLhQua for ; Sun, 7 Apr 2013 09:48:50 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id AC73621F859D for ; Sun, 7 Apr 2013 09:48:48 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:64632 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UOslg-00007h-QF for sieve@ietf.org; Sun, 07 Apr 2013 18:48:46 +0200 Message-ID: <5161A34D.3040805@rename-it.nl> Date: Sun, 07 Apr 2013 18:48:13 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Sieve mailing list References: <20130407160743.19463.39851.idtracker@ietfa.amsl.com> In-Reply-To: <20130407160743.19463.39851.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130407160743.19463.39851.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------040200000000010203080000" X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Subject: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-02.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 16:48:50 -0000 This is a multi-part message in MIME format. --------------040200000000010203080000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I made a new version of the "duplicate" draft. It should address the comments by Ned, Kristin and Alexey. I added the example I gave to Alexey. This resulted in quite a bit of restructuring in the description of the new test command, so it is best to review at least that section entirely. There is one thing I thought of and haven't addressed so far. My current implementation makes a new entry in the duplicate tracking list irrespective of whether one exists already, overwriting the old one and thereby resetting the expiry time to whatever is configured using ":seconds". This will make example 3 in the draft yield unexpected results; if duplicates arrive within the expiry time, the total expiry time is in effect extended. The semantic difference here is that the expiry time is either measured relative to the initial message or relative to the last duplicate. This means that the 30 minutes in the example can stretch indefinitely if duplicates keep arriving before the expiry deadline. So, for the scenario of example 3, such behavior is quite obviously wrong. However, would there be an application for having the expiry time be relative to the last message received with the specified ID rather than the initial one? How would we accommodate for that? Regards, Stephan. --------------040200000000010203080000 Content-Type: message/rfc822; name="New Version Notification for draft-bosch-sieve-duplicate-02_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="New Version Notification for draft-bosch-sieve-duplicate-02_"; filename*1="txt.eml" Return-path: Envelope-to: stephan@rename-it.nl Delivery-date: Sun, 07 Apr 2013 18:07:53 +0200 Received: from mail.ietf.org ([12.22.58.30]:42463) by drpepper.rename-it.nl with esmtp (Exim 4.72) (envelope-from ) id 1UOs8E-0007rJ-2j for stephan@rename-it.nl; Sun, 07 Apr 2013 18:07:53 +0200 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480D221F8EC3 for ; Sun, 7 Apr 2013 09:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYx9lHo50Yg0 for ; Sun, 7 Apr 2013 09:07:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B39D21F8EDF for ; Sun, 7 Apr 2013 09:07:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: stephan@rename-it.nl Subject: New Version Notification for draft-bosch-sieve-duplicate-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130407160743.19463.39851.idtracker@ietfa.amsl.com> Date: Sun, 07 Apr 2013 09:07:43 -0700 X-RenameIT-MailScanner-SpamScore: -4.7 (----) X-RenameIT-MailScanner-SpamCheck: No, score=-4.7 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 A new version of I-D, draft-bosch-sieve-duplicate-02.txt has been successfully submitted by Stephan Bosch and posted to the IETF repository. Filename: draft-bosch-sieve-duplicate Revision: 02 Title: Sieve Email Filtering: Detecting Duplicate Deliveries Creation date: 2013-04-07 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-bosch-sieve-dupl= icate-02.txt Status: http://datatracker.ietf.org/doc/draft-bosch-sieve-duplicate Htmlized: http://tools.ietf.org/html/draft-bosch-sieve-duplicate-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-bosch-sieve-dupli= cate-02 Abstract: This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplicate message deliveries. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. = = The IETF Secretariat --------------040200000000010203080000-- From NED+mta-filters@mauve.mrochek.com Sun Apr 7 19:09:54 2013 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53CB21F902D for ; Sun, 7 Apr 2013 19:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdoBuJDicSsJ for ; Sun, 7 Apr 2013 19:09:54 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 37F7121F902C for ; Sun, 7 Apr 2013 19:09:54 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OS7MSRX5O00034D1@mauve.mrochek.com> for sieve@ietf.org; Sun, 7 Apr 2013 19:04:51 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ORQXGSAS4G000054@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Sun, 7 Apr 2013 19:04:45 -0700 (PDT) From: NED+mta-filters@mauve.mrochek.com Message-id: <01OS7MSOJ7RG000054@mauve.mrochek.com> Date: Sun, 07 Apr 2013 15:23:38 -0700 (PDT) In-reply-to: "Your message dated Sun, 07 Apr 2013 18:48:13 +0200" <5161A34D.3040805@rename-it.nl> References: <20130407160743.19463.39851.idtracker@ietfa.amsl.com> <5161A34D.3040805@rename-it.nl> To: Stephan Bosch Cc: Sieve mailing list Subject: Re: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-02.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 02:09:54 -0000 > There is one thing I thought of and haven't addressed so far. My current > implementation makes a new entry in the duplicate tracking list > irrespective of whether one exists already, overwriting the old one and > thereby resetting the expiry time to whatever is configured using > ":seconds". This will make example 3 in the draft yield unexpected > results; if duplicates arrive within the expiry time, the total expiry > time is in effect extended. The semantic difference here is that the > expiry time is either measured relative to the initial message or > relative to the last duplicate. This means that the 30 minutes in the > example can stretch indefinitely if duplicates keep arriving before the > expiry deadline. So, for the scenario of example 3, such behavior is > quite obviously wrong. However, would there be an application for having > the expiry time be relative to the last message received with the > specified ID rather than the initial one? How would we accommodate for that? I should have given this more consideration. The difference between timeouts "relative to first" and "relatve to last" seems significant enough to me to provide a means to control it. It's certainly easy enough for me to accomodate in my implementation. In fact since the default should be "relative to first" we can simply reuse the existing :last parameter in use elsewhere. Thoughts? Ned From stephan@rename-it.nl Wed Apr 10 04:53:34 2013 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD37121F940F for ; Wed, 10 Apr 2013 04:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU6AuzTJJcWU for ; Wed, 10 Apr 2013 04:53:31 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id C4CC121F9410 for ; Wed, 10 Apr 2013 04:53:27 -0700 (PDT) Received: from ewi1299.ewi.utwente.nl ([130.89.145.113]:50259) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UPtac-0005ke-SQ; Wed, 10 Apr 2013 13:53:25 +0200 Message-ID: <516552A4.9080104@rename-it.nl> Date: Wed, 10 Apr 2013 13:53:08 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ned Freed References: <20130407160743.19463.39851.idtracker@ietfa.amsl.com> <5161A34D.3040805@rename-it.nl> <01OS7MSOJ7RG000054@mauve.mrochek.com> In-Reply-To: <01OS7MSOJ7RG000054@mauve.mrochek.com> Content-Type: multipart/alternative; boundary="------------000007020208050003040803" X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00, HTML_MESSAGE autolearn=ham version=3.3.1 Cc: Sieve mailing list Subject: Re: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-02.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:53:34 -0000 This is a multi-part message in MIME format. --------------000007020208050003040803 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Op 4/8/2013 12:23 AM, Ned Freed schreef: >> There is one thing I thought of and haven't addressed so far. My >> current implementation makes a new entry in the duplicate tracking >> list irrespective of whether one exists already, overwriting the >> old one and thereby resetting the expiry time to whatever is >> configured using ":seconds". This will make example 3 in the draft >> yield unexpected results; if duplicates arrive within the expiry >> time, the total expiry time is in effect extended. The semantic >> difference here is that the expiry time is either measured relative >> to the initial message or relative to the last duplicate. This >> means that the 30 minutes in the example can stretch indefinitely >> if duplicates keep arriving before the expiry deadline. So, for the >> scenario of example 3, such behavior is quite obviously wrong. >> However, would there be an application for having the expiry time >> be relative to the last message received with the specified ID >> rather than the initial one? How would we accommodate for that? > > I should have given this more consideration. > > The difference between timeouts "relative to first" and "relatve to > last" seems significant enough to me to provide a means to control > it. It's certainly easy enough for me to accomodate in my > implementation. I agree. > In fact since the default should be "relative to first" we can simply > reuse the existing :last parameter in use elsewhere. Would we make allowing the presence of :last dependent on :seconds (much like :index) ? Alternatives I can think of: :refresh, :update, :renew - with the semantic interpretation that the entry in the tracking list is being updated/refreshed/renewed. Anyone else suggestions? Regards, Stephan. --------------000007020208050003040803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Op 4/8/2013 12:23 AM, Ned Freed schreef:
>> There is one thing I thought of and haven't addressed so far. My
>> current implementation makes a new entry in the duplicate tracking
>> list irrespective of whether one exists already, overwriting the
>> old one and thereby resetting the expiry time to whatever is
>> configured using ":seconds". This will make example 3 in the draft
>> yield unexpected results; if duplicates arrive within the expiry
>> time, the total expiry time is in effect extended. The semantic
>> difference here is that the expiry time is either measured relative
>> to the initial message or relative to the last duplicate. This
>> means that the 30 minutes in the example can stretch indefinitely
>> if duplicates keep arriving before the expiry deadline. So, for the
>> scenario of example 3, such behavior is quite obviously wrong.
>> However, would there be an application for having the expiry time
>> be relative to the last message received with the specified ID
>> rather than the initial one? How would we accommodate for that?
>
> I should have given this more consideration.
>
> The difference between timeouts "relative to first" and "relatve to
> last" seems significant enough to me to provide a means to control
> it. It's certainly easy enough for me to accomodate in my
> implementation.

I agree.

> In fact since the default should be "relative to first" we can simply
> reuse the existing :last parameter in use elsewhere.

Would we make allowing the presence of :last dependent on :seconds (much like :index) ?

Alternatives I can think of:

:refresh, :update, :renew - with the semantic interpretation that the entry in the tracking list is being updated/refreshed/renewed.

Anyone else suggestions?

Regards,

Stephan.
--------------000007020208050003040803-- From stephan@rename-it.nl Wed Apr 10 04:56:48 2013 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871B521F8C1A for ; Wed, 10 Apr 2013 04:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgJTjPZ0Y1H2 for ; Wed, 10 Apr 2013 04:56:48 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF3921F8BAE for ; Wed, 10 Apr 2013 04:56:47 -0700 (PDT) Received: from ewi1299.ewi.utwente.nl ([130.89.145.113]:50265) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UPtds-0005pR-MY; Wed, 10 Apr 2013 13:56:46 +0200 Message-ID: <5165536A.1040402@rename-it.nl> Date: Wed, 10 Apr 2013 13:56:26 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ned Freed References: <20130407160743.19463.39851.idtracker@ietfa.amsl.com> <5161A34D.3040805@rename-it.nl> <01OS7MSOJ7RG000054@mauve.mrochek.com> <516552A4.9080104@rename-it.nl> In-Reply-To: <516552A4.9080104@rename-it.nl> Content-Type: multipart/alternative; boundary="------------060309040709010200090106" X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00, HTML_MESSAGE autolearn=ham version=3.3.1 Cc: Sieve mailing list Subject: Re: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-02.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:56:48 -0000 This is a multi-part message in MIME format. --------------060309040709010200090106 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Op 4/10/2013 1:53 PM, Stephan Bosch schreef: > (lots of garbled mess) > > Anyone else suggestions? Ok, sorry for the mess, this is the last time I use the Thunderbird Edit->Rewrap feature. Regards, Stephan. --------------060309040709010200090106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Op 4/10/2013 1:53 PM, Stephan Bosch schreef:
(lots of garbled mess)

Anyone else suggestions?

Ok, sorry for the mess, this is the last time I use the Thunderbird Edit->Rewrap feature.

Regards,

Stephan.




--------------060309040709010200090106-- From stephan@rename-it.nl Wed Apr 10 13:51:03 2013 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1549A21F92E8 for ; Wed, 10 Apr 2013 13:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFHgB9wTuIgv for ; Wed, 10 Apr 2013 13:50:58 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE8821F91D8 for ; Wed, 10 Apr 2013 13:50:53 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:58566 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UQ1yk-0007J4-4n for sieve@ietf.org; Wed, 10 Apr 2013 22:50:51 +0200 Message-ID: <5165D08D.4040404@rename-it.nl> Date: Wed, 10 Apr 2013 22:50:21 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Sieve mailing list References: <20130407160743.19463.39851.idtracker@ietfa.amsl.com> <5161A34D.3040805@rename-it.nl> In-Reply-To: <5161A34D.3040805@rename-it.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Subject: Re: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-02.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 20:51:24 -0000 On 4/7/2013 6:48 PM, Stephan Bosch wrote: > Hi, > > I made a new version of the "duplicate" draft. It should address the > comments by Ned, Kristin and Alexey. I added the example I gave to > Alexey. > > This resulted in quite a bit of restructuring in the description of > the new test command, so it is best to review at least that section > entirely. One other thing: we recently defined this great new Sieve use-case called IMAPSieve. Is there any application imaginable for the duplicate test in this context, i.e. do we want to allow it there? Either way, I think we should state its applicability explicitly. Regards, Stephan. From NED+mta-filters@mauve.mrochek.com Thu Apr 25 14:56:25 2013 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AF721F9590 for ; Thu, 25 Apr 2013 14:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhfVcZoVCEGn for ; Thu, 25 Apr 2013 14:56:24 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C2AAA21F92C0 for ; Thu, 25 Apr 2013 14:56:21 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OSWJ6NZ42O004GX7@mauve.mrochek.com> for sieve@ietf.org; Thu, 25 Apr 2013 14:51:18 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OSDA15QVCW000054@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Thu, 25 Apr 2013 14:51:16 -0700 (PDT) From: NED+mta-filters@mauve.mrochek.com Message-id: <01OSWJ6MW7KE000054@mauve.mrochek.com> Date: Thu, 25 Apr 2013 14:44:27 -0700 (PDT) In-reply-to: "Your message dated Wed, 10 Apr 2013 22:50:21 +0200" <5165D08D.4040404@rename-it.nl> References: <20130407160743.19463.39851.idtracker@ietfa.amsl.com> <5161A34D.3040805@rename-it.nl> <5165D08D.4040404@rename-it.nl> To: Stephan Bosch Cc: Sieve mailing list Subject: Re: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-02.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:56:25 -0000 > On 4/7/2013 6:48 PM, Stephan Bosch wrote: > > Hi, > > > > I made a new version of the "duplicate" draft. It should address the > > comments by Ned, Kristin and Alexey. I added the example I gave to > > Alexey. > > > > This resulted in quite a bit of restructuring in the description of > > the new test command, so it is best to review at least that section > > entirely. > One other thing: we recently defined this great new Sieve use-case > called IMAPSieve. Is there any application imaginable for the duplicate > test in this context, i.e. do we want to allow it there? Either way, I > think we should state its applicability explicitly. I think there are legitimate use-cases, but it's also incredibly easy to misuse in this context. The basic problem is that moving messages around in IMAP doesn't carry with it any sort of inherent special semantic and people move messages around for all sorts of reasons (or for no real reason at all). This is quite unlike message delivery. So, for example, you could define a Sieve in IMAP to prevent, say, the inclusion of a second copy of the same message in a given folder. But bad things are going to happen if, say, you forget the filter is there and move some of the messages out and back in a couple of times. We'd have to extend the semantics of the extension substantiantially to take care of this, and even if we were to do that actually using it would be very tricky indeed. Since I see the main benefit of this extension as how simple it makes duplicate checks in Sieve, this usage makes me very nervous, so nervous that I could certainly accept a "NOT RECOMMENDED" label for this case. Ned From hammondjohnson@hushmail.com Sat Apr 27 14:06:57 2013 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7064221F9929 for ; Sat, 27 Apr 2013 14:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waO66DHJwMhA for ; Sat, 27 Apr 2013 14:06:57 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA9B21F9910 for ; Sat, 27 Apr 2013 14:06:54 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 0540E580BD for ; Sat, 27 Apr 2013 18:00:54 +0000 (UTC) X-hush-relay-time: 220 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 18:00:53 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id BBA9BE6736; Sat, 27 Apr 2013 18:00:53 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 14:00:53 -0400 To: sieve@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427180053.BBA9BE6736@smtp.hushmail.com> Subject: [sieve] Biggest Fake Conference in Computer Science X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:06:57 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.