email moved by rule retains copy in Inbox

[xyzzy]

Originally Posted by camner

Hmmm...I may have figured this out.

The very last line of my custom Sieve code is:

#redirect all other mail to the inbox
  keep;

Ah ha! So as I suspected it was your added code. The keep is overriding the earlier discard.

So, if I understand how all this works, the Section 4 rules, set up through the FM rules interface, are run through, BUT SO IS MY CUSTOM SIEVE CODE! So, since none of my custom sieve rules apply to the emails in question, it all fall through to the end and then the keep command retains a copy in the inbox.

As I have been saying, yes, your code was always being reached because you didn't follow the proper procedure to only execute it if there wasn't already a match in section 4 (or a match in the preceding section of the "old" code, whatever the section numbers were).

The explicit keep was never necessary since sending the message to the inbox is always the default unless it is cleared explicitly for some reason (i.e., in the section 4 code where it does the discard because a UI rule matched) before execution terminates.

It seems to me that I've got a couple of choices....

I could keep using custom Sieve only, as I have been doing for years.

Which is what I was telling you. Prefix your code with what it should have been prefixed with all along i.e., enclose all your stuff in the else (or if appropriate elsif) braced appropriately including your superfluous keep if you wish. Or with the current FM code test the stop switch before your code. Note, see last paragraph below.

If I wanted to use the FM rules interface so I could create a rule from a search, for example, is there I way I could alter the code so that my custom sieve rules are only considered if a given email does not satisfy any of the FM rules interface rules I have set up?

Again, testing the stop switch before your code tells you whether any of the UI section 4 rules generated stuff were satisfied. The stop switch will not be set if there is no match.

For code following section 4 the only conditions I can think of where you might not want it subject to the stop switch is where you are 100% sure no match could possibly ever have occurred in section 4 which is what I think you are assuming. I suppose it's ok not to prefix with the stop switch test or use the else/elsif but why would you not want to? Then you don't fall into problems like yours and having to keep track that anything you do down there doesn't conflict with some UI filter you may add in the future. But if you want to leave everything as is except for that keep so be it.

[camner]

As you can probably tell from what I've written before, my knowledge of Sieve is rather limited, and I appreciate the time you've been taking to stick with me on this.

I do have a couple of other questions...

(A) To make sure I understand what you are suggesting as one possible way to proceed:

Replace

if string :is "${stop}" "Y" {
#   For backwards compatibility
}

with:

 if string :is "${stop}" "Y" {stop;}

I see I can't edit section 4 directly, so I suppose I put the replacement code at the top of my sieve code?



(B) If you look back at my earlier post where I pasted the entire section 4, you'll notice that I have two rules. One of them is the rule we've been talking about where a copy was retained in the Inbox. But the other one is a very similar rule, but does NOT result in a copy being retained. I would think the two rules ought to display similar behavior! The only difference I can see is that one rule tries to filter only on the From address, while the other filters on the To address + Subject.

[JeremyNicoll]

Originally Posted by camner

(B) If you look back at my earlier post where I pasted the entire section 4, you'll notice that I have two rules. One of them is the rule we've been talking about where a copy was retained in the Inbox. But the other one is a very similar rule, but does NOT result in a copy being retained. I would think the two rules ought to display similar behavior!

I'd agree with that except that although your own custom Sieve code ends with a "keep", I'm not certain if that line would always be processed. Is it on its own or is it also subject to conditions that precede it? Is there anything in your custom Sieve code that could prematurely end its execution? (Either intentionally, if there's a "stop" that you choose to execute, or a redirect or discard, or maybe a syntax error - I don't know how Sieve handles errors.) Do you have other mails which are being properly processed by your own Sieve code?

Edited: I looked in RFC 5228 - see: https://tools.ietf.org/html/rfc5228 - where in section 2.10.6 it says:

"When an error occurs in a Sieve script, all processing stops." but then it describes aspects that vary according to the implementation. And then it says "When an error happens, implementations MUST notify the user that an error occurred and which actions (if any) were taken, and do an implicit keep." I am not sure (if there is a problem) how that notification of the user might happen. But note that it's another way that a "keep" could happen.

Originally Posted by camner

The only difference I can see is that one rule tries to filter only on the From address, while the other filters on the To address + Subject.

That should be irrelevant, provided you're certain that the sample mail that you say matched this first rule actually did do.



One solution to this - since you seem not to understand Sieve very well - would be to stop using your own Sieve code. Are you certain that whatever your custom code does cannot done by setting up rules within the FM rules GUI?

[xyzzy]

Originally Posted by camner

(A) To make sure I understand what you are suggesting as one possible way to proceed:

Replace

if string :is "${stop}" "Y" {
#   For backwards compatibility
}

with:

 if string :is "${stop}" "Y" {stop;}

I see I can't edit section 4 directly, so I suppose I put the replacement code at the top of my sieve code?

No, I said add the stop test to the the start of your code, i.e., just ignore that FM's "backwards compatibility" block is even there. As I mentioned it's a simple one line addition.

### 4. User configured rules
.
.
.
if string :is "${stop}" "Y" {
#   For backwards compatibility
}
----------------------------------------------- end of section 4
----------------------------------------------- start of your code at the bottom
if string :is "${stop}" "Y" {stop;} # <-- add this line before your original code
your original code starts here...
...

This will always work no matter what you do in your additional code. But you have an another alternative choice if your code entirely consists of a series of tests, e.g.,

if test1 {
   stuff to do if test1 is true...
} elsif test2 {
   stuff to do if test2 is true...
} elsif test3 {
   stuff to do if test3 is true...
}

Then you don't need the additional stop test if you change your first if to an elsif since it then just a series of alternatives to the stop test FM generates at the end of section 4. It's just a question of which is more aesthetically pleasing to you!

Either way it's simple quick fix.

(B) If you look back at my earlier post where I pasted the entire section 4, you'll notice that I have two rules. One of them is the rule we've been talking about where a copy was retained in the Inbox. But the other one is a very similar rule, but does NOT result in a copy being retained. I would think the two rules ought to display similar behavior! The only difference I can see is that one rule tries to filter only on the From address, while the other filters on the To address + Subject.

As JeremyNicoll stated we don't know what you are doing in your additional code. It's not worth figuring out. Bottom line is you don't want to handle the incoming messages if a section 4 UI generated rule already handled it (and I might point out that even the FM code test's the stop switch before testing each rule).

Originally Posted by JeremyNicoll

One solution to this - since you seem not to understand Sieve very well - would be to stop using your own Sieve code. Are you certain that whatever your custom code does cannot done by setting up rules within the FM rules GUI?

I'm curious about this too. What are you doing down there that makes you think you can't already do it in the UI?

Is it the match criteria? Remember that creating rules in the UI gives you two ways to create a rule. One is the "search" type of rule. The other is the "no preview" method which gives you more matching criteria.

Is it the actions? If so then, yes, I suppose then you might need your own code.

[camner]

Originally Posted by xyzzy

I'm curious about this too. What are you doing down there that makes you think you can't already do it in the UI?

Is it the match criteria? Remember that creating rules in the UI gives you two ways to create a rule. One is the "search" type of rule. The other is the "no preview" method which gives you more matching criteria.

Is it the actions? If so then, yes, I suppose then you might need your own code.

No, there's probably nothing in my Sieve code I can't do in the current UI. The issue is that I've built up a very long list of tests that (mostly) file incoming email into specific folders and silently discard other emails that are sent to email addresses that have been compromised or spammed (and that don't consistently get kicked out by the FM spam filter). Most of these predate the current, more robust FM UI. Including comments, my Sieve code is over 300 lines long, and redoing all those rules in the UI would be a rather long and tedious task.

Thanks for all your help!