[BritTim]

If that's the case I will go back to my original premise and we are going around in a circle. If I fetch mail from one of the identities it will of course have its requisite X-LinkId. If the server delivers that email to the sieve script, be that fetch disabled or not, the sieve code checking for that X-LinkId will be executed. I cannot see how interpreting that script has some kind of implicit condition to not execute that piece of sieve script if I flag that fetch as disabled and the server delivers that email.

In other words if the fetch is done on that pop link** and the server delivers that email to the sieve script there is no way I can see that chunk of code not executing when it matches the X-LinkId if the code remains in the script even though the fetch is disabled. Back to square one.

I think we may be talking past one another and missing something in the translation. I'll repeat it again, disabled or not, if I fetch that email, if that email has a X-LinkId (which for that identity it will) that code will be executed. I may not be a sieve expert but I've worked on compilers and interpreters long enough to say I don't know how that X-LinkId condition could fail to match its X-LinkId even if the fetch is disabled so long as that X-LinkId in the headers and the script.

I am clearly doing a terrible job of explaining, for which I apologise. Let me backtrack and start by explaining the two main ways messages can arrive at your account.

1. Most common, anyone can send a message to one of the email addresses associated with your account. I refer to this as "normal email delivery".
2. You can set up an Identity that includes manually fetching messages from another account. This is done by specifying the POP3 server, user and password associated with that other account. When such a fetch Identity is created, FastMail will periodically poll the Inbox of that other account, downloading any messages it finds there into your account. A long digression on why you might want to have messages arrive in your account this way is possible, but let's leave that for another time. If the fetch Identity (POP link) is disabled, the other account will not be polled. That does not prevent normal email delivery from occurring. However, nothing you put in a fetch Identity is relevant to normal email delivery.

For normal email delivery to your account, you can create Rules based on things like From header, To header, Subject line or message size to control filing of messages into a different folder than the default of Inbox. This has nothing to do with the X-LinkId header.

Messages that are manually fetched using a fetch Identity (from another account's POP server) are automatically given an extra header (the X-LinkId header you see referred to in your sieve script). At the same time you create the fetch Identity, you can also indicate the folder to be used when messages are fetched. When you do this, FastMail automatically adds a snippet to the sieve script to control this delivery to a specific folder. If no messages with a specific X-LinkId header are ever received (because the fetch Identity is disabled) the sieve snippet associated with that X-LinkId header will have no effect. Code of the form

if header Xx-LinkId :is "12345" {
  fileinto "Inbox.MyFolder;
}

will never be true and will be ignored.

If this is still unclear, perhaps someone else will help me out. A guy called Bill is often here and is good at explaining clearly.