|
FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc. |
|
Thread Tools |
4 Dec 2018, 10:44 AM | #1 |
Essential Contributor
Join Date: May 2018
Posts: 474
|
Identities & Fetch Fetch settings vs. it's Sieve code
I was going to submit the following as a ticket. But I thought I would post it here for opinions of what I believe is a bug.
------- I have three identities enabled and created; a.com, b.com, and c.com. Also three corresponding folders to filter into; a, b, c. Sieve generates the following code (fake X-LinkId for this example of course): Code:
### 8. Sieve generated for fetch mail filing elsif header :is "X-LinkId" "12345" { fileinto "INBOX.a; } elsif header :is "X-LinkId" "67890" { fileinto "INBOX.b"; } elsif header :is "X-LinkId" "54321" { fileinto "INBOX.c"; } I can understand the possibility of the "keep a copy" or "delete the copy" being done at the server level thus not affecting the sieve code. But why does disabling the fetch by unchecking "Fetch mail from..." not cause the corresponding fileinto sieve clause to be deleted? With it deleted the b.com mail would end up in the Inbox unless an explicit organize rule is created. And that is exactly what happens if I have the "Fetch mail from..." set to Inbox instead of b. The sieve clause is deleted. So in summary, enabling or disabling a Fetch identity's "Fetch mail from this account this account into..." has no effect on the sieve code unless the destination folder is the Inbox. I would expect the sieve clause to be deleted exactly as if Inbox were specified as the destination (unless an explicit filtering rule is also defined by the user). As it stands now mail will always get sorted into it's specified folder whether it's Fetch is enabled or disabled unless the destination folder is the Inbox. What's the reasoning behind this or is this a bug (as opposed to a "feature"), or what am I missing in my reasoning? |
4 Dec 2018, 01:01 PM | #2 |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,090
|
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. 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.
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? |
4 Dec 2018, 04:04 PM | #3 | |||
Essential Contributor
Join Date: May 2018
Posts: 474
|
Quote:
Quote:
Quote:
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 Last edited by xyzzy : 4 Dec 2018 at 04:10 PM. |
|||
4 Dec 2018, 04:24 PM | #4 | ||
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,090
|
Quote:
|
||
4 Dec 2018, 05:43 PM | #5 |
Essential Contributor
Join Date: May 2018
Posts: 474
|
So are you saying that if the Fetch is disabled the incoming mail from that linked email service will never be delivered by the FM servers? In other words the FM servers also look at that enable/disable flag just like they look at the "keep a copy" and "delete the copy" flags? That is the one case I hadn't even considered.
If that's true then that's the missing piece of the puzzle in my understanding of that code that I've been looking for! And that's why you previously said the pop-link code would never be executed (i.e., email with the associated X-LinkId will never make it to the sieve code). Last edited by xyzzy : 4 Dec 2018 at 07:11 PM. |
5 Dec 2018, 01:15 AM | #6 | |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,090
|
Quote:
FastMail will not try to figure out whether the messages arriving via normal mail delivery are similar in some way to those that were previously fetched using a POP link. That would be a highly complex and error prone process. |
|
5 Dec 2018, 06:38 AM | #7 | |
Essential Contributor
Join Date: May 2018
Posts: 474
|
Quote:
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". Last edited by xyzzy : 5 Dec 2018 at 06:55 AM. |
|
5 Dec 2018, 08:43 AM | #8 | ||
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,090
|
Quote:
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 Code:
if header Xx-LinkId :is "12345" { fileinto "Inbox.MyFolder; } 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. |
||
5 Dec 2018, 10:59 AM | #9 | ||
Essential Contributor
Join Date: May 2018
Posts: 474
|
You were doing great, I fully agree 100% with what you said, up to the following part:
Quote:
You are saying that the X-LinkId is added to that identity's mail "manually fetched using a fetch Identity". I submit that the X-LinkId will also be (and is) added if the auto 5-minute poll option is chosen instead of doing a manual refresh. The confusion/disagreement, and the reason I started this thread, is over that "snippet" as you referred to it. That "snippet" is always created for a fetch identity when the destination folder to sort into is not the Inbox (the "specific folder" you referred to). And it doesn't matter whether the identity's "Fetch mail" is checked or unchecked (enabled or disabled). The snippet is created. Quote:
It hadn't occurred to me when I started this thread but now seems the only reasonable possibility (which is what I thought you meant in a earlier post) is if the server doesn't access the identity's POP server if the fetch identity is disabled. So it is (must be) accessing the enable/disable state just like it accesses the "keep a copy"/"delete the copy" setting. In other words the server has to know the enable/disable status of that identity to ensure, one way or another, the snippet condition will never be true when the fetch identity is disabled. Because if it doesn't check and inserts the X-LinkId for that identity, that snippet will always sort into the destination folder whether the fetch identity is enabled or not. This is why I started this thread. What I hadn't thought of before I apparently, according to you, misunderstood what you were trying to say (and now I don't think so) is how could the fetch identity be disabled without the server knowing about it because the snippet is always there? I don't see any other alternatives. Either the server accesses the identity's POP server or it doesn't. Not accessing the identity's POP server is the most reasonable interpretation of what disabling the fetch means. Auto or manual refresh doesn't affect this. So the server has to know the enable/disable status (or some other way to keep it from fetching from the identity's POP server) because if it doesn't, and the message gets delivered to the sieve script including its X-LinkId that snippet is going to sort it to the destination folder whether enabled or not. As I said, not thinking about the server knowing the enable/disable status is what led to my confusion. Are you still saying this can't be right, server doesn't know the enable/disable state, and somehow that snippet magically never sees or matches on the X-LinkId? If that was true the fetch would would end up placing the message in the Inbox if the fetch is disabled. And that doesn't happen. Last edited by xyzzy : 5 Dec 2018 at 11:07 AM. |
||
5 Dec 2018, 05:03 PM | #10 | |
Essential Contributor
Join Date: Dec 2017
Location: Scotland
Posts: 484
|
Quote:
|
|