http://permalink.gmane.org/gmane.ietf.mta-filters hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.mta-filters/5288 <pre>Hello, This draft describes an extension to the Sieve mail filtering language (RFC 5228) called "duplicate". It adds the ability to detect duplicate message deliveries. The main application for this new extension is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. Using this extension, the user can for example decide to move duplicate messages to a special folder, mark them as 'seen', or discard them altogether. I first implemented this extension a little more than a year ago as a vendor-defined extension for my own Sieve implementation (Dovecot Pigeonhole). I did this upon repeated requests from users. They were looking for a Sieve-equivalent of what could be achieved with Procmail using `formail -D`. Since then, I extended it a bit and eventually I made it more generic. In January of this year I decided that it may be suitable for proper standardization, so I posted the specification on the Sieve mailing list (https://www.ietf.org/mai</pre> Stephan Bosch 2013-05-22T22:19:18 http://permalink.gmane.org/gmane.ietf.mta-filters/5285 <pre> We always have a tricky situation when something belongs elsewhere as well as on apps-discuss -- this has happened a few times as we've branched off discussions (webfinger, json, dmarc), and will also happen in cases such as imap and sieve stuff, as we try to bring it into appsawg. I think the best approach is to try to cross-post when it's stuff that's relatively low volume (such as this), and to keep apps-discuss periodically updated when it's higher volume (such as webfinger). We've now had reviews of this document https://datatracker.ietf.org/doc/draft-bosch-sieve-duplicate/ ...by Ned Freed, Aaron Stone, and Cyrus Daboo. Alexey, too, as shepherd. And PSA has expressed approval for handling it in appsawg. I've seen no objections, so I think that works for bringing it into appsawg. For review, if we could get a couple of other appsawg folks, even some who are not otherwise involved with sieve, to review it as a sanity check, we should be OK. Claudio can help corral a couple of reviewers through</pre> Barry Leiba 2013-05-22T16:19:35 http://permalink.gmane.org/gmane.ietf.mta-filters/5283 <pre>I read the draft and it looked good to me. +1 On Tue, May 21, 2013 at 2:42 PM, Alexey Melnikov &lt;alexey.melnikov&lt; at &gt;isode.com&gt;wrote: _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Aaron Stone 2013-05-21T22:21:53 http://permalink.gmane.org/gmane.ietf.mta-filters/5282 <pre>Hi, Are there people here who can do additional reviews of the draft? Thank you, Alexey Begin forwarded message: _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Alexey Melnikov 2013-05-21T21:42:53 http://permalink.gmane.org/gmane.ietf.mta-filters/5281 <pre> Fire away; send a message to &lt;appsawg-chairs&lt; at &gt;tools.ietf.org&gt;, ask, and offer to shepherd. Murray and Salvatore are suddenly getting a batch of new work to keep them off the streets. Barry _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Barry Leiba 2013-05-03T21:55:14 http://permalink.gmane.org/gmane.ietf.mta-filters/5280 <pre> No, not really. I think this draft is sufficiently mature at this point that we should try and get it on track to become an RFC. Barry and/or Pete, would it make sense to progress this through the appsawg? I'd be happy to do the sheparding work. Ned _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> NED+mta-filters< at >mauve.mrochek.com 2013-05-03T21:22:25 http://permalink.gmane.org/gmane.ietf.mta-filters/5279 <pre> Yes, I agree with that. BTW, any further comments on the document as it is now? More thoughts on the ':last' issue? Regards, Stephan. _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Stephan Bosch 2013-05-03T08:40:02 http://permalink.gmane.org/gmane.ietf.mta-filters/5278 <pre>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 t</pre> hammondjohnson< at >hushmail.com 2013-04-27T18:00:53 http://permalink.gmane.org/gmane.ietf.mta-filters/5277 <pre> 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 _______</pre> NED+mta-filters< at >mauve.mrochek.com 2013-04-25T21:44:27 http://permalink.gmane.org/gmane.ietf.mta-filters/5276 <pre> 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. _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Stephan Bosch 2013-04-10T20:50:21 http://permalink.gmane.org/gmane.ietf.mta-filters/5275 <pre>Op 4/10/2013 1:53 PM, Stephan Bosch schreef: Ok, sorry for the mess, this is the last time I use the Thunderbird Edit-&gt;Rewrap feature. Regards, Stephan. _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Stephan Bosch 2013-04-10T11:56:26 http://permalink.gmane.org/gmane.ietf.mta-filters/5274 <pre>Op 4/8/2013 12:23 AM, Ned Freed schreef: &gt;&gt; current implementation makes a new entry in the duplicate tracking &gt;&gt; list irrespective of whether one exists already, overwriting the &gt;&gt; old one and thereby resetting the expiry time to whatever is &gt;&gt; configured using ":seconds". This will make example 3 in the draft &gt;&gt; yield unexpected results; if duplicates arrive within the expiry &gt;&gt; time, the total expiry time is in effect extended. The semantic &gt;&gt; difference here is that the expiry time is either measured relative &gt;&gt; to the initial message or relative to the last duplicate. This &gt;&gt; means that the 30 minutes in the example can stretch indefinitely &gt;&gt; if duplicates keep arriving before the expiry deadline. So, for the &gt;&gt; scenario of example 3, such behavior is quite obviously wrong. &gt;&gt; However, would there be an application for having the expiry time &gt;&gt; be relative to the last message received with the specified ID &gt;&gt; rather than the initial one? How would we accommodate for that? &gt; &gt; I should h</pre> Stephan Bosch 2013-04-10T11:53:08 http://permalink.gmane.org/gmane.ietf.mta-filters/5273 <pre> 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 _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> NED+mta-filters< at >mauve.mrochek.com 2013-04-07T22:23:38 http://permalink.gmane.org/gmane.ietf.mta-filters/5272 <pre>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</pre> Stephan Bosch 2013-04-07T16:48:13 http://permalink.gmane.org/gmane.ietf.mta-filters/5271 <pre> [...] 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.) _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Alexey Melnikov 2013-04-02T18:12:30 http://permalink.gmane.org/gmane.ietf.mta-filters/5270 <pre> I was unclear, sorry. I was talking about having to catch the error at compile time. I think catching it at execution time should be allowed. Yeah, this is one where additional comments would really be nice. Excellent. Ned _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> NED+mta-filters< at >mauve.mrochek.com 2013-03-21T14:37:29 http://permalink.gmane.org/gmane.ietf.mta-filters/5269 <pre>Op 3/15/2013 10:09 PM, Kristin Hubner schreef: Ok, I understand, but I don't really have a preference; either ":key" or ":uniqueid" makes sense. Anyone else got suggestions or strong opinions about this? :) Regards, Stephan. _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Stephan Bosch 2013-03-21T12:11:25 http://permalink.gmane.org/gmane.ietf.mta-filters/5268 <pre>Hi Ned, Op 3/15/2013 6:39 PM, Ned Freed wrote: Ok, I'll improve that a bit. Agreed. Perhaps when someone finishes the multiscript draft at some point, it could be mentioned there. Agreed. Yes, good catch. This is what my current implementation does too. Yes, always good to give hints in the right direction. I'm not sure what you mean here. Do you want me to make the kind of error more open, e.g. by adopting the wording used for the :zone and :originalzone arguments for the date extension? `It is an error to specify both :zone and :originalzone.' Which basically leaves the kind of error up to the implementer. I have no problem with that. It can be useful. Anyone else got suggestions or comments about this? Yes, otherwise users could get surprised at some point. Thanks. I'll make a new version some time next week. Regards, Stephan. _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Stephan Bosch 2013-03-21T12:06:01 http://permalink.gmane.org/gmane.ietf.mta-filters/5267 <pre>A minor comment: I'm not crazy about the ":value" tag name, as I find it less self-explanatory than I'd prefer. I'd propose instead ":key", or or maybe ":uniqueid". Regards, Kristin On Mar 12, 2013, at 2:14 PM, Stephan Bosch wrote: _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Kristin Hubner 2013-03-15T21:09:52 http://permalink.gmane.org/gmane.ietf.mta-filters/5266 <pre> Sorry to take so long to respond; I finally managed to complete my implementation yesterday. In implementing this, I saw nothing about the semantics of the test I would like to see changed. I really like the clever way the single word "duplicate" ends up doing the right thing in most cases. The draft also seems pretty complete, although a couple of clarifications are needed: (0) A clear execution model is really important here. In particular, the way this has to be implemented is that during sieve execution queries whatever back end database you're using but does *not* update it. Only after the sieve has been evalauted without error and the actions it specified have been perform should the database be updated. I note that the same applies in environments that support multiple sieves - you evaluate them all, apply the results, and for the subset of sieves that evaluated without error, perform the updates. I'll also note that how duplicate tests in multiple scripts interac</pre> NED+mta-filters< at >mauve.mrochek.com 2013-03-15T17:39:36 http://permalink.gmane.org/gmane.ietf.mta-filters/5265 <pre>Hi Alexey, On 3/10/2013 3:01 PM, Alexey Melnikov wrote: To detect duplicates, some more or less unique identifying string value must be extracted from the message and compared between deliveries. For most cases, the contents of the Message-ID header is the best choice; that is what it is meant for. However, to accommodate more complex uses, the duplicate test has the flexibility to choose a different string value for comparison. Using the :value argument, the string value can be set manually to an arbitrary string. Typically, one would compose this string using variable substitutions. One can for example compose it from parts of a header, the envelope, multiple headers, parts of the message body or even the current date; whatever is appropriate for the application. There is one example of the use of :value in the draft (the second one). I should perhaps make the subject header structure a bit more complex to justify its use in this example (because :header would work here as well). Another exa</pre> Stephan Bosch 2013-03-12T21:14:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.mta-filters