http://blog.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/5289 <pre>Hello, according to RFC5804 (ManageSieve), what authorization ID shall a user use, who is permitted to manage both her own scripts and the global scripts, in order to manage the global scripts? (provided that authorization ID = authentication ID is supposed to be used for managing the own, private scripts) Do the following paragraphs from Section "3 Sieve URL Schema": owner = *ochar ;; %-encoded version of [SASL] authorization ;; identity (script owner) or "userid". ;; ;; Empty owner is used to reference ;; global scripts. [... and ...] Note that the empty owner (e.g., sieve://example.com//script) is different from the missing owner (e.g., sieve://example.com/script) and is reserved for referencing global scripts. hint, that to access the global scripts an empty authorization ID shall be used? The word "global" is mentioned in the whole RFC only on these two places. What does the constant "userid" mean in the above definition of "owner"? Thanks for your feedback Дилян _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </pre> Дилян Палаузов 2013-06-18T19:46:27 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/mail-archive/web/sieve/current/msg05292.html). There, it was first picked up and reviewed by Ned Freed and Alexey Melnikov and I turned it into a first I-D submission. The next versions -01 and -02 were discussed in these threads: https://www.ietf.org/mail-archive/web/sieve/current/msg05300.html https://www.ietf.org/mail-archive/web/sieve/current/msg05310.html At this point it was decided that the document was sufficiently mature to start the process of becoming a proposed standard. Since the Sieve WG is no longer the obvious place to do this, it was moved to APPSAWG. Apart from its name, the new submission draft-ietf-appsawg-sieve-duplicate-00 is identical to draft-bosch-sieve-duplicate-02. The following are known issues we haven't addressed in the latest version so far and I think these should be discussed a bit more: - Do we measure the expiry time of entries in the duplicate tracking list relative to the initial message or relative to the last duplicate (https://www.ietf.org/mail-archive/web/sieve/current/msg05310.html). Should we make this configurable? - Is the "duplicate" extension supposed to be active in IMAPSieve (RFC 6785) context (https://www.ietf.org/mail-archive/web/sieve/current/msg05314.html)? Currently, consensus is to mark this as NOT RECOMMENDED. I'd like to finish this document some time in July or August. For that, it would be nice to get it thoroughly reviewed, so your reviews and comments are very welcome! Regards, Stephan Bosch. On 5/22/2013 10:39 PM, internet-drafts&lt; at &gt;ietf.org wrote: _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </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 appsdir. We might also specifically ask Arnt Gulbrandsen and Tim Showalter for reviews, as formerly active Sieve folks. Barry _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </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 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. _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </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 _______________________________________________ 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-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 have given this more consideration. &gt; &gt; The difference between timeouts "relative to first" and "relatve to &gt; last" seems significant enough to me to provide a means to control &gt; it. It's certainly easy enough for me to accomodate in my &gt; implementation. I agree. &gt; 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. _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </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 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. _______________________________________________ sieve mailing list sieve&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/sieve </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 interact is tricky. I eventually decided to qualify duplicate with the sieve "owner", which then acts like another handle. I don't see any reason to get into the multiple scripts bit in the draft; I'm just noting it in case someone is interested. (1) The draft says nothing about what happens when the specified header field does not exist. The test should fail unconditionally in this case. (2) The draft says nothing about what happens when there are more than one of the specified fields present. It should say that the first one that is found is used. (3) The draft probably should say that duplicate does not support either the index or mime extensions directly (:index, :mime:, and :anychild), and that if you want to perform such checks you can do them with variables and :value. And finally, a few nits: (1) The "MUST throw a compile time error if both :header and :value are specified" is a bit strong. For one thing, such a check is inappropriate if ihave is in effect. And for another, while I was able to implement it, it may not be convenient for all implementations to perform this check at compile time. (2) I'm wondering if it wouldn't be best to suggest a default timeout. 12 hours? A day? (3) A MUST be case-sensitive is probably a good idea, perhaps with a note as to how you can use the set action to muck around with case. That's it! Thanks for producing such a good draft! 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-15T17:39:36 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.mta-filters