[xyzzy]

Originally Posted by BritTim

There is no reason for any change to the sieve code when you simply disable a POP link. The relevant code will simply never have any effect.

I don't know how you can say that. As I discussed in my post if the destination folder is not Inbox it will get sorted into that specified folder even if the fetch is "disabled". If the code was removed when disabling the Fetch, as I was originally expecting, it would sort into the Inbox by default unless there was an explicit organize rule sorting it to some other folder.

Also, whether you keep or delete emails on the original server from which you fetch using a POP link is not controlled by the sieve code.

I mentioned (speculated) that too.

Are you seeing any unexpected results from use of these identities, or are you just trying to understand the sieve code to gain a better appreciation of how FastMail works?

Mostly to understand the reasoning behind this particular chunk of code and why it is what it is.

I first stumbled on this when I forgot the Fetch (pop link) was created. Without thinking I created an organize rule for the incoming email to the same folder the Fetch would sort it to. Since organize rules don't have a stop statement I could see it would end up sorting the same email to the destination folder twice; first from the organize and second from the Fetch (pop link). So I disabled the Fetch and that's when I noticed it didn't have any effect. Code was still there. I've gotten into the habit of checking the sieve code when I use the UI to see how using the UI affects the sieve code and that does help in understanding the language.

Of course all I have to do is remove my organize and I did. So all this now is just to confirm whether I am seeing a bug or this is deliberate and if so the reasoning behind it