Quote:
Originally Posted by xyzzy
The general FM Sieve "logic" is that section 4a (Calculate rule action) tests the rule conditions and a match sets the corresponding Lx_... and hasmailbox variables. Disabled rules still show the code but it is simply commented out and thus it's Lx... variable will never be set.
|
Aha! Disabled rules! I forgot that I had any... Section 4a doesn't set any "hasmailbox" variables here though; it's setting the "skipinbox" variable - which presumably means that later we intend to prevent that mail being routed to the inbox?
Quote:
Originally Posted by xyzzy
Section 4d (Do rule action) checks the Lx... variable to see which rule matched in section 4a, and if so do the fileinto :copy and set hasmailbox.
|
So at this point such mails are being routed to a named mailbox (by the fileinto). The ":copy" means not that there's a copy being made elsewhere, but that - for the moment - the "implicit keep" (which would normally route every mail to the INBOX) is still going to happen. And "hasmailbox" presumably indicates that the mail has successfully been put somewhere else?
Quote:
Originally Posted by xyzzy
Finally at the end of these action tests (where it has the comment "Then archive or clear implicit keep if skipping inbox") if both skipinbox (set from the rule that matched in section 4a) and hasmailbox (set from the corresponding 4d action) are true (both will be) then discard the copy the fileinto made.
|
It's not precisely discarding a copy, it's turning off the "implicit keep"...
Quote:
Originally Posted by xyzzy
On the surface I see no problems with the section 4d code you show. So what does the corresponding section 4a code show, i.e., where the rule conditions are tested to set L0_archives_to_delete_permenently and L1_Dads_mail_VITA_RAC_Volunteer_Hours?
I say "on the surface" because one thing does strike me as somewhat "odd". That is the mailboxid used for fileinto INBOX.archives.to delete permenently, i.e, 655686524b36ba99. Admittedly I don't know much about mailboxid's but all the ones I've seen are not in that format. They are usually 5 dash separated hex components like the one for INBOX.Dads mail.VITA.RAC Volunteer Hours (c5c83b43-921a-4a80-8324-e36b774e6b68). I wonder if that has something to do with the otherwise unexplained behavior, and if so, how/why did that odd looking mailboxid get created (if it really is "odd")?
|
I just looked at my Sieve code; all of my mailboxids are the '5 dash separated hex' values type too.