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/4249 Isn't this really a generic issue, not specific to sieve? We can discuss how to solve it here and now, but IMO such a solution should not be be published in a document titled "Sieve So and So". My suggestion for solving it would be to include some sort of key or hash in the Auto-Submitted field which uniquely identifies the (script,user,statement) triple. Arnt Arnt Gulbrandsen 2008-12-01T22:27:10 http://permalink.gmane.org/gmane.ietf.mta-filters/4248 Alexey Melnikov 2008-12-01T21:19:41 http://permalink.gmane.org/gmane.ietf.mta-filters/4246 Alexey Melnikov wrote: I've updated the draft to include your proposal. It looks like "owner" can be empty, as long as "authority" is not. Alexey Melnikov 2008-11-30T17:58:52 http://permalink.gmane.org/gmane.ietf.mta-filters/4244 Hi Stephan, Stephan Bosch wrote: Good so far. I think this text is not going to be good in presence of ihave extension. So I would rather omit or reword this part. I am not sure what you mean here. IMHO, this part is good. This text is good and might be helpful. While I generally agree with the intent of your new text, I think it demonstrates cases when saying less is actually better than saying more: a very specific text might unintentionally exclude some valid checks. Alexey Melnikov 2008-11-30T15:17:58 http://permalink.gmane.org/gmane.ietf.mta-filters/4243 Philip Guenther writes: OK. I had a vague intention of someday doing just that... "apply sieve script to all old mail", which would transmogrify the sieve script into a series of rather complex SQL queries and shuffle mail around from where it is to where the sieve script would have filed it. That would, among other things, make the RDBMS query planner choose evaluation order based on expected performance, and probably make the whole operation faster by a few orders of magnitude. Arnt Arnt Gulbrandsen 2008-11-30T10:03:19 http://permalink.gmane.org/gmane.ietf.mta-filters/4242 On Sat, 29 Nov 2008, Arnt Gulbrandsen wrote: The base spec doesn't require it because it's not observable without variables. An implementation can do that only if the 'variables' extensions has not been required. The variables spec, RFC 5229, says this in section 3.2: The interpreter MUST short-circuit tests, i.e., not perform more tests than necessary to find the result. Evaluation order MUST be left to right. If a test has two or more list arguments, the implementation is free to choose which to iterate over first. Philip Guenther Philip Guenther 2008-11-29T22:25:54 http://permalink.gmane.org/gmane.ietf.mta-filters/4241 Hi, I _thought_ sieve required short-circuiting, but didn't feel courageous enough reply to Dilian's message... The only occurence of "short-curcuit" in 3028 was removed in 5228, and I didn't see anything to replace it. Further, and perhaps more seriously, I don't see any requirement of order. As far as I can see, a sieve implementation can evalue header and envelope in either order in this case: if anyof ( header ... , envelope ... ) { ... } Have I been smoking the good stuff? Arnt Arnt Gulbrandsen 2008-11-29T22:02:52 http://permalink.gmane.org/gmane.ietf.mta-filters/4240 Yes. Not only are they permitted to do so, the variables extensions makes short-circuiting a requirement - see RFC 5229 section 3.2. I think you meant "don't evaluate". Which is exactly why the specification requires short-circuiting. It's required to be "a". This isn't a question of having an opinion, it's a question of what the specification already requires. Ned Ned Freed 2008-11-29T21:37:51 http://permalink.gmane.org/gmane.ietf.mta-filters/4239 Mester wrote: I think you want to use: redirect "localuser< at >whatever.doma.in"; I.e. there is no such Sieve action as 'forward'. Also the email address must be quoted (as suggested by Arnt). Alexey Melnikov 2008-11-29T18:08:21 http://permalink.gmane.org/gmane.ietf.mta-filters/4238 Hi, I also tried it but it has the same resault. I tried localuser< at >localdomain but it sais invalid e-mail address. Attila Mester 2008-11-29T10:08:47 http://permalink.gmane.org/gmane.ietf.mta-filters/4237 mester< at >freemail.hu writes: Try forward "localuser< at >whatever.doma.in"; Some software does not have the concept of local users at all. Arnt Arnt Gulbrandsen 2008-11-29T09:30:55 http://permalink.gmane.org/gmane.ietf.mta-filters/4236 Hi, I have a Debian 4.0 server with Sieve enabled Cyrus IMAP and Exim4. I have one e-mail address at my internet provider with two aliases. I use fetchmail to download the e-mail account to a local user, but I want to forward the messages arrived with one alias to another local user. I wrote a small script but it sais invalid e-mail address. How can I correct it? (sendmail localuser < ... works just fine) My script looks like this: if header :contains ["received"] "for EMAIL< at >ALIAS" { forward localuser; } Attila Mesterhazy Mester 2008-11-29T09:12:09 http://permalink.gmane.org/gmane.ietf.mta-filters/4235 Alexey Melnikov wrote: I've updated the document once (mostly editirial) based on comments from Cyrus. See <http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-melnikov-sieve-imapext-metadata-05.txt> for a detailed list of changes. I am planning to update the document once again to remove "_" from test names, e.g. "mailbox_exists" would become "mailboxexists". Please speak up if you have any objections. Alexey Melnikov 2008-11-27T15:17:16 http://permalink.gmane.org/gmane.ietf.mta-filters/4234 Hello, Are implementations permitted to stop evaluating a test, when the result makes no sense, e.g. in anyof(true, header "A" "B") evaluate "header"? The point is, that Sieve-Variables, says (Sec. 3.2. Match Variables) The decimal value of the match variable name will index the list of matching strings from the most recently evaluated successful match of type ":matches". However it is not very clear for me if every test needs to be evaluated, and thus if the last :match test was permitted to be evaluated, is it necessary to evaluate it? Consider a message A: Xa B: Xb C: Mc and if anyof (header :matches ["A", "B"] "X*", header :matches "C" "M*") { //what is ${1}? } What would be the value of ${1} * a - because after finding it out, the result of the first header test is clear. Having true as the first parameter of anyof, then anyof stops evaluation. * c - because this is the last matched test and the evaluation has not stopped after finding out that the first header test suffices for the result of anyof * b - header evaluates all possibilities, and anyof stops when the result is clear. Thanks in advance for your opinion, Дилян Дилян Палаузов 2008-11-27T12:52:46 http://permalink.gmane.org/gmane.ietf.mta-filters/4233 Aaron Stone wrote: Agreed. We already have UNAUTHENTICATE. But using URIs would be quite elegant. You already know my personal answer to this question ;-). Alexey Melnikov 2008-11-26T04:40:52 http://permalink.gmane.org/gmane.ietf.mta-filters/4232 On Tue, 2008-11-25 at 20:54 +0000, Alexey Melnikov wrote: +51% wait to work on an extension. Now that we've enumerated some more of the issues URI's raise, I think it's likely we'll get really stuck on working out the details. Is there another way that we can achieve the goal of one user modifying another user's Sieve scripts that's not too ugly and can easily become URI in a future revision? Is there a path we might agree on for merging Sieve management into IMAP protocol, and cease work on ManageSieve at some reasonable level of functionality? It would be a shame if the Sieve URI's ended up being like email message ID's -- they look like something that you could use to uniquely identify and retrieve a message from somewhere in the universe, but not really. Aaron Aaron Stone 2008-11-25T21:28:24 http://permalink.gmane.org/gmane.ietf.mta-filters/4231 Alexey Melnikov wrote: [...] We've discussed this in more details in Minneapolis and the room agreement was that ManageSieve commands should accept URIs in addition to script names. However, I am having second thoughts on this. 1). It looks like at least the following commands would need to be updated: HAVESPACE, PUTSCRIPT, GETSCRIPT, DELETESCRIPT But LISTSCRIPTS returns script names. Should it be changed to return URIs? I think this would break all existing clients, so I don't think that an unextended version of LISTSCRIPTS should do that. Also, should it list *all* scripts accessible by the current user, or just personal scripts? The former seems like an extension that Dilian was talking about. 2). Considering that Sieve script names are in Unicode it would also make sense to specify IRI version of Sieve URIs. I frankly don't have experience specifying IRIs. So my current thinking is that these changes might have undesired effects on existing clients and they also seem to require quite a bit of work. But I really want to get this document done (for Lemonade/OMA MEM among other things). So can we postpone this change till an extension? I've missed another obvious use case: constructing URIs to give them to third parties. Alexey Melnikov 2008-11-25T20:54:17 http://permalink.gmane.org/gmane.ietf.mta-filters/4230 Hi Дилян, Дилян Палаузов wrote: While I think having a standardized way of accessing global scripts would be a good idea, I am not convinced that the empty string is going to be Ok. This might have some weird side effects on URI parsers (but I am not sure). This creates security issues. Besides the list of all allowed authorization ids might not be readily available. I am afraid you are going against rough WG consensus in this case. It is not currently possible. An extension would be needed in order to add the ability to change a user's language. It seems to be working now. Alexey Melnikov 2008-11-25T20:45:38 http://permalink.gmane.org/gmane.ietf.mta-filters/4229 On 11/21/08 4:11 PM, Arnt Gulbrandsen wrote: Sorry, I don't have ESP, so I don't know what you're talking about. I came up with a contrived example, but haven't come up with a realistic one. Have you one you can provide? You've not presented a case (real world or otherwise) fixed by Aaron's change I wanted undone. Matthew Elvey 2008-11-24T08:37:36 http://permalink.gmane.org/gmane.ietf.mta-filters/4228 Far too many web shopping sites and other software refuse to accept arnt+thisorthat< at >example.com as a valid address. This week I've run into something worse. Tobit.de makes a mail server which, AFAICT, transforms arnt+abcdary< at >example.com into arnt«cdary< at >example.com. Absolutely lovely. Arnt Arnt Gulbrandsen 2008-11-22T19:04:56 http://permalink.gmane.org/gmane.ietf.mta-filters/4227 Matthew Elvey writes: And since someone needs to say why this didn't sway the WG rough consensus, I'll say why I'm not persuaded. My code is able, or not, to carry out an ereject in a manner different from reject. It depends on this and that, including factors beyond control of my code. The code may even be able to do it when the sieve script is uploaded, but unable to when it's executed. Making a script invalid between upload and execution is not at all desirable. Not having ereject at all is not desirable either. And so on. Aaron's solution is the best compromise I can think of, in the sense that it minimises the sum of undesirable aspects. Arnt Arnt Gulbrandsen 2008-11-22T00:11:09 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.mta-filters