Quote:
Originally Posted by BritTim
No, I am saying that sieve code created to process messages fetched using a POP link is only used at the time messages are received using that link.
|
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.
------------
** Maybe that's some of the confusion here, the term "pop link" is not defined by Fastmail in any of it's documents (I searched) and I believe they removed the term from the UI after I questioned them on it. It's why I usually am referring to it as the "fetch identity".