EmailDiscussions.com  

Go Back   EmailDiscussions.com > Email Service Provider-specific Forums > FastMail Forum
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
Stay in touch wirelessly

FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc.

Reply
 
Thread Tools
Old 10 Mar 2021, 11:26 PM   #1
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 606
email moved by rule retains copy in Inbox

I have a rule I created through the Fastmail search, which is intended to move a matching email to a different folder. The rule works, sort of (a copy of the email is in the destination folder), but a copy of the email is also retained in the inbox.

This rule matches a sender and a subject.

I have another rule that moves a email based upon the sender which correctly moves matching emails but does not retain a copy in the inbox, but it doesn't also match on the subject.

How do I change the original rule so that matches are deleted from the inbox?
camner is offline   Reply With Quote

Old 11 Mar 2021, 08:36 AM   #2
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 344
Quote:
Originally Posted by camner View Post
I have a rule I created through the Fastmail search, which is intended to move a matching email to a different folder. The rule works, sort of (a copy of the email is in the destination folder), but a copy of the email is also retained in the inbox.

This rule matches a sender and a subject.
Using the UI, no matter how many conditions are created for a rule, specifying a Move to destination folder precludes filing into the INBOX (i.e., the Continue to apply other rules checkbox is disabled in that rule). So at the moment it's not obvious to me how that specific rule could result in filing a matching message both into your specified folder and continuing on to default filing into INBOX.

Last edited by xyzzy : 11 Mar 2021 at 09:14 AM.
xyzzy is offline   Reply With Quote
Old 11 Mar 2021, 01:46 PM   #3
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,875
Do you have any custom sieve? If so, that is where I would first look for the cause of this. Also, look to see if there is any mechanism by which the message could be received twice under different receiving addresses.
BritTim is offline   Reply With Quote
Old 11 Mar 2021, 02:14 PM   #4
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 606
Yes, I do have custom sieve, but no rules that should impact this situation, since I just started using that email address and the rule acts on the To: field and the Subject.

OK, I was looking at the Edit Sieve screen, and I see that FM interface rules are acted upon first, before the user Sieve code.

Here's an excerpt from what was generated by the rule:

### 4d. Do rule actions
else {
if string :is "${L0_archives_to_delete_permenently}" "Y" {
fileinto
:copy
:mailboxid "655686524b36ba99"
"INBOX.archives.to delete permenently";
set "hasmailbox" "Y";
}
if string :is "${L1_Dads_mail_VITA_RAC_Volunteer_Hours}" "Y" {
fileinto
:copy
:mailboxid "c5c83b43-921a-4a80-8324-e36b774e6b68"
"INBOX.Dads mail.VITA.RAC Volunteer Hours";
set "hasmailbox" "Y";
}
# Then archive or clear implicit keep if skipping inbox
if string :is "${skipinbox}" "Y" {
if not string :is "${hasmailbox}" "Y" {
fileinto
:mailboxid "8fb0a692-ab78-4e62-a475-7f7fe05c14c9"
:specialuse "\\Archive"
"INBOX.Archive";
} else {
discard;
}

I don't read Sieve code all that well, but it seems to me that since after fileinto is copy, then the behavior I'm seeing may make sense.

But, why does the rule generate this code?

Last edited by camner : 11 Mar 2021 at 02:23 PM.
camner is offline   Reply With Quote
Old 11 Mar 2021, 06:35 PM   #5
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 256
Quote:
Originally Posted by camner View Post
Here's an excerpt from what was generated by the rule:

### 4d. Do rule actions
else {
if string :is "${L0_archives_to_delete_permenently}" "Y" {
fileinto
:copy
:mailboxid "655686524b36ba99"
"INBOX.archives.to delete permenently";
set "hasmailbox" "Y";
}

On the face of it, that's alarming, but the code says

if a variable named "L0_archives_to_delete_permenently" is "Y"
then do various stuff


Looking at my Sieve rules I see lots of this sort of thing too, but earlier in the file, some of the logic that could create variables with those sorts of names is commented out. For example, here, this section exists

if
allof( not string :is "${stop}" "Y",
header :contains "Return-Path" "<ispf-l-list"
)
{
if mailboxidexists "8c0136de-5597-410e-81e4-450d642911a4" {
set "L31_INBOX_in_listserv_ls_ISPF" "Y";
set "skipinbox" "Y";
}
set "stop" "Y";
}

and that could define the "L31_INBOX_in_listserv_ls_ISPF" variable, so any test later that examines it might take some actions. But I also have sections like

# if
# allof( not string :is "${stop}" "Y",
# header :is ["List-Id","List-Post"] ["<hercules-390.yahoogroups.com>","<<hercules-390.yahoogroups.com>>"]
# )
# {
# if mailboxidexists "24354043-e3b7-490c-8184-09ea116686ab" {
# set "L63_INBOX_in_herc_all_maillists_herc_390_yh__ie_the_emulator_" "Y";
# set "skipinbox" "Y";
# }
# set "stop" "Y";
# }

- which in my rules is the only place where variable "L63_INBOX_in_herc_all_maillists_herc_390_yh__ie_the_emulator_"
might have been set. It clearly isn't set so the later logic

if string :is "${L63_INBOX_in_herc_all_maillists_herc_390_yh__ie_the_emulator_}" "Y" {
fileinto
:copy
:mailboxid "24354043-e3b7-490c-8184-09ea116686ab"
"INBOX.INBOX.in-herc all maillists.herc-390-yh (ie the emulator)";
set "hasmailbox" "Y";
}

will never actually do anything (except waste CPU cycles on the FM server).



I'm, not sure how happy I am to see what looks like test code being generated mixed up with live code.
JeremyNicoll is offline   Reply With Quote
Old 11 Mar 2021, 07:07 PM   #6
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 344
Quote:
Originally Posted by camner View Post
But, why does the rule generate this code?
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.

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.

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.

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")?

-----

Update due to mistake pointed out in the next post: The first paragraph should read:

The general FM Sieve "logic" is that section 4a (Calculate rule action) tests the rule conditions and a match sets the corresponding Lx_... and skipinbox variables. Disabled rules still show the code but it is simply commented out and thus it's Lx... variable will never be set.

Last edited by xyzzy : 12 Mar 2021 at 05:10 AM. Reason: Corrected 1st paragraph
xyzzy is offline   Reply With Quote
Old 11 Mar 2021, 09:49 PM   #7
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 256
Quote:
Originally Posted by xyzzy View Post
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 View Post
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 View Post
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 View Post
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.
JeremyNicoll is offline   Reply With Quote
Old 12 Mar 2021, 05:04 AM   #8
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 344
Quote:
Originally Posted by JeremyNicoll View Post
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?
Oops sorry for the mistake. I meant to say "section 4a (Calculate rule action) tests the rule conditions and a match sets the corresponding Lx_... and skipinbox variables". It was getting late when I typed that. I just went back and added a correction to my post. Thanks for pointing that out.

Quote:
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?
Yeah, I was trying to keep the explanation simple and avoided introducing the concept of "keep". But you are correct. The fileinto :copy just doesn't clear the "keep" so that the message can still potentially default to filing into the INBOX. But...

Quote:
It's not precisely discarding a copy, it's turning off the "implicit keep"...
Which is what that block of code does following that "Then archive or clear implicit keep if skipping inbox" comment, i.e., that discard.

Quote:
I just looked at my Sieve code; all of my mailboxids are the '5 dash separated hex' values type too.
Which brings us back to my original concern. Where did that strange looking mailboxid come from?

I'd still like to see the section 4a code (appropriately censored if necessary).

Last edited by xyzzy : 12 Mar 2021 at 05:12 AM.
xyzzy is offline   Reply With Quote
Old 13 Mar 2021, 01:29 PM   #9
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 606
Well, this has gotten way over my head very quickly!

FWIW, here is the complete section 4, with personal stuff (if I caught it all...), munged. There are two custom rules set up (though I have a huge Sieve code as well, but that executes after section 4 rules, no?) The second custom rule works fine, with no retention of emails in the Inbox. Just the first rule has that occur.

Code:
### 4. User configured rules

### 4a. Calculate rule actions

# Search: "to:[email protected] subject:(GetYourRefund Client)"
if 
  allof( not string :is "${stop}" "Y",
    jmapquery text:
  {
     "conditions" : [
        {
           "conditions" : [
              {
                 "to" : "[email protected]"
              },
              {
                 "cc" : "[email protected]"
              },
              {
                 "bcc" : "[email protected]"
              },
              {
                 "deliveredTo" : "[email protected]"
              }
           ],
           "operator" : "OR"
        },
        {
           "conditions" : [
              {
                 "subject" : "GetYourRefund"
              },
              {
                 "subject" : "Client"
              }
           ],
           "operator" : "AND"
        }
     ],
     "operator" : "AND"
  }
.
  )
{
  set "read" "Y";
  
  if mailboxidexists "655686524b36ba99" {
    set "L0_archives_to_delete_permenently" "Y";
    set "skipinbox" "Y";
  }
  set "stop" "Y";
}

# Search: "from:[email protected]"
if 
  allof( not string :is "${stop}" "Y",
    jmapquery text:
  {
     "from" : "[email protected]"
  }
.
  )
{
  set "read" "Y";
  
  if mailboxidexists "c5c83b43-921a-4a80-8324-e36b774e6b68" {
    set "L1_Dads_mail_VITA_RAC_Volunteer_Hours" "Y";
    set "skipinbox" "Y";
  }
  set "stop" "Y";
}

### 4b. Rule sent message to trash
if anyof(
  string :is "${deletetotrash}" "Y",
  string :is "${spam}" "Y"
) {
  set "skipinbox" "Y";
}
# Copies always get marked read for better compatibility with IMAP clients
# and labels mode.
if anyof(
  string :is "${read}" "Y",
  not string :is "${skipinbox}" "Y"
) {
  if hasflag "\\Seen" {
    set "read" "Y";
  } else {
    addflag "\\Seen";
  }
}
# Similarly, only the inbox copy gets flagged
if allof(
  string :is "${flagged}" "Y",
  string :is "${skipinbox}" "Y"
) {
  addflag "\\Flagged";
}
if string :is "${deletetotrash}" "Y" {
  fileinto :specialuse "\\Trash" "INBOX.Trash";
}

### 4c. Rule says message is spam
elsif string :is "${spam}" "Y" {
  fileinto :specialuse "\\Junk" "INBOX.Junk Mail";
}

### 4d. Do rule actions
else {
  if string :is "${L0_archives_to_delete_permenently}" "Y" {
    fileinto
      :copy
      :mailboxid "655686524b36ba99"
      "INBOX.archives.to delete permenently";
    set "hasmailbox" "Y";
  }
  if string :is "${L1_Dads_mail_VITA_RAC_Volunteer_Hours}" "Y" {
    fileinto
      :copy
      :mailboxid "c5c83b43-921a-4a80-8324-e36b774e6b68"
      "INBOX.Dads mail.VITA.RAC Volunteer Hours";
    set "hasmailbox" "Y";
  }
  # Then archive or clear implicit keep if skipping inbox
  if string :is "${skipinbox}" "Y" {
    if not string :is "${hasmailbox}" "Y" {
      fileinto
        :mailboxid "8fb0a692-ab78-4e62-a475-7f7fe05c14c9"
        :specialuse "\\Archive"
        "INBOX.Archive";
    } else {
      discard;
    }
  } else {
    # Set flags for inbox copy
    if not string :is "${read}" "Y" {
      removeflag "\\Seen";
    }
    if string :is "${flagged}" "Y" {
      addflag "\\Flagged";
    }
    # Do MailFetch filing if applicable, otherwise deliver to inbox
  }

Last edited by camner : 16 Mar 2021 at 01:20 PM.
camner is offline   Reply With Quote
Old 13 Mar 2021, 06:21 PM   #10
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 344
Just to be sure about what you say the problem is in terms of that code.

You say that if a message is sent to [email protected] and the subject is "GetYourRefund Client" the message is filed into "archives_to_delete_permenently" and your inbox?

Is that correct? I have to ask because aside from the weird looking mailboxid I see nothing wrong with that code and a message with the stated conditions should only appear in "archives_to_delete_permenently".

The weird looking mailboxid must be ok to the extent of causing the section 4a conditions tests to work to set L0_archives_to_delete_permenently and skipinbox. That in turn will allow the section 4d actions to do it's fileinto and set hasmailbox. So with both hasmailbox and skipinbox set the "keep" will get cancelled from the discard and nothing further should be done.

So I have to ask, are you sure it's the same message also in the inbox, i.e., is the message id and time stamps identical?

I said the weird looking mailboxid must be correct to allow the above described actions. But I think it is also true that if it is somehow invalid to the fileinto the specified folder name is used instead, at least I think that's what's supposed to happen. If there's a bug with that fileinto behavior then perhaps that explains it.

I am still curious about the weird looking mailboxid. Was the folder "archives_to_delete_permenently" originally some other name? I'm not totally clear on mailboxid's but I believe they have something to do with renaming folders in a IMAP environment.

Quote:
...though I have a huge Sieve code as well, but that executes after section 4 rules, no?)
Do you mean you have your own Sieve code in the edit block at the bottom of the script? If so then yes that code will be reached after all the UI rules stuff has been processed?

BUT...

You need to know that one of the above section 4 rules was satisfied if you don't want any of your code at the bottom to see the message!

If you look at the last 3 lines at the end of the FM generated code before that edit block you will see:

Code:
if string :is "${stop}" "Y" {
#   For backwards compatibility
}
So is your code embedded in an else or elsif block? Or do you explicitly check whether the stop switch is set to bypass your code? If not then maybe something in your additional code is somehow responsible for the strange behavior which might explain why the code you show in your post appears to be ok.

---

By the way, here's a "meta comment" about posting code in this forum. Please use the "code" format, i.e., the '#' formatting option, so that the code retains its original formatting (specifically the indenting). I show the use of the code formatting code in the 3-line block above.

Last edited by xyzzy : 13 Mar 2021 at 06:57 PM.
xyzzy is offline   Reply With Quote
Old 13 Mar 2021, 07:06 PM   #11
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 256
One minor comment, most unlikely to have any bearing on the OP's problem... In the block of code that the OP posted, that starts

# Search: "to:[email protected] subjectGetYourRefund Client)"

the logic isn't looking for a Subject header that contains "GetYourRefund Client" but instead for a Subject that contains "GetYourRefund" and "Client", in any order, separated by any other words. That's seen here:

{
"conditions" : [
{
"subject" : "GetYourRefund"
},
{
"subject" : "Client"
}
],
"operator" : "AND"
}


Regarding xyzzy's question about whether the apparently equal messages really are equal, I would compare them by using the "More" menu within display of each message to select "Show Raw Message" then c&p all of the contents of each raw message to a text file. I'd then use a (programmer's) file compare utility to look for differences in the two saved files.

Last edited by JeremyNicoll : 13 Mar 2021 at 07:12 PM.
JeremyNicoll is offline   Reply With Quote
Old 13 Mar 2021, 07:34 PM   #12
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 344
Quote:
Originally Posted by JeremyNicoll View Post
...the logic isn't looking for a Subject header that contains "GetYourRefund Client" but instead for a Subject that contains "GetYourRefund" and "Client", in any order, separated by any other words.
Heh, because of stuff like this I never use jmapquery (search) type of rules for filters. If I have to create a rule through the UI I always create rules using the "no preview" form. They are exact and also give you more matching criteria. Doing a search-type match (which includes stemming) may have it's place as a filter rule. It's just I haven't yet had a case that needed one.

Last edited by xyzzy : 14 Mar 2021 at 05:08 AM.
xyzzy is offline   Reply With Quote
Old 14 Mar 2021, 06:08 AM   #13
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 606
Quote:
Originally Posted by xyzzy View Post
Just to be sure about what you say the problem is in terms of that code.

You say that if a message is sent to [email protected] and the subject is "GetYourRefund Client" the message is filed into "archives_to_delete_permenently" and your inbox?

Is that correct? I have to ask because aside from the weird looking mailboxid I see nothing wrong with that code and a message with the stated conditions should only appear in "archives_to_delete_permenently".


The weird looking mailboxid must be ok to the extent of causing the section 4a conditions tests to work to set L0_archives_to_delete_permenently and skipinbox. That in turn will allow the section 4d actions to do it's fileinto and set hasmailbox. So with both hasmailbox and skipinbox set the "keep" will get cancelled from the discard and nothing further should be done.

So I have to ask, are you sure it's the same message also in the inbox, i.e., is the message id and time stamps identical?
Yes, that is exactly what I am saying. Here is a link to a screenshot that shows the results of a search, and you andsee that FM says there are two locations where the search found a matching email.

The message IDs are:
[email protected][AND
[email protected]

which are the same.

Quote:
I am still curious about the weird looking mailboxid. Was the folder "archives_to_delete_permenently" originally some other name? I'm not totally clear on mailboxid's but I believe they have something to do with renaming folders in a IMAP environment.
That mailbox was created so long ago that I can't remember if it ever had another name. But, "archives_to_delete_permenently" isn't the name of the mailbox. "to_delete_permenently" is a child mailbox of "archives" (which is on the same level as Inbox)

Quote:
Do you mean you have your own Sieve code in the edit block at the bottom of the script? If so then yes that code will be reached after all the UI rules stuff has been processed?
I think so. When I click on the link "Edit custom Sieve code," on the page that opens, block 4 is right above a block containing my custom Sieve, so I assume block 4 is executed first.

Quote:
BUT...

You need to know that one of the above section 4 rules was satisfied if you don't want any of your code at the bottom to see the message!

If you look at the last 3 lines at the end of the FM generated code before that edit block you will see:

Code:
if string :is "${stop}" "Y" {
#   For backwards compatibility
}
So is your code embedded in an else or elsif block? Or do you explicitly check whether the stop switch is set to bypass your code? If not then maybe something in your additional code is somehow responsible for the strange behavior which might explain why the code you show in your post appears to be ok.
My Sieve code is exactly where FM put it when they upgraded to allow the creation of rules through the interface. It doesn't appear to me to be inside an else or elseif block; it looks as if it is just appended right after block 4.
---
Quote:
By the way, here's a "meta comment" about posting code in this forum. Please use the "code" format, i.e., the '#' formatting option, so that the code retains its original formatting (specifically the indenting). I show the use of the code formatting code in the 3-line block above.
Thanks for the reminder. I have edited the original post.
camner is offline   Reply With Quote
Old 14 Mar 2021, 07:17 AM   #14
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 344
Quote:
Originally Posted by camner View Post
My Sieve code is exactly where FM put it when they upgraded to allow the creation of rules through the interface. It doesn't appear to me to be inside an else or elseif block; it looks as if it is just appended right after block 4.
Which means your code is always seeing the messages no matter what the section 4 code does. Even in the "old rules" the stuff the became the new section 4 was a series of elsif blocks and expected your additions following it to also be an else or elsif block.** You still need to do that as part of your additional code down there.

Note, if you don't want to enclose your code within an else or elsif then precede your code with the following:

Code:
 if string :is "${stop}" "Y" {stop;}
So are there any tests in your code at the end that can cause the behavior you are seeing? Correct your code as described (i.e., preceded with that stop test or enclosed with an else or elsif, whatever is desired) and see if your problem email still has the same behavior. I suspect it won't.

Quote:
Thanks for the reminder. I have edited the original post.
Much nicer!

-------------
** That three line block that tests for stop is commented as "For backwards compatibility" precisely because it assumes any user code at the end is in it's own else or elsif block, i.e., the logical sequence to follow the "old" elsif's that preceded it. Initially when in beta testing the new FM code they didn't have that 3-line block in there. That meant that the user code that followed starting with an else or elsif for the "old" FM code resulted in a syntax error. I guess they didn't test that out since I had to submit a ticket on it because I too have code at the end starting with elsif. Hence the comment about "backward compatibility", i.e., to make the user's code at the end remain syntactically compatible with the new section 4 code.

Last edited by xyzzy : 14 Mar 2021 at 12:51 PM.
xyzzy is offline   Reply With Quote
Old 16 Mar 2021, 08:08 AM   #15
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 606
Hmmm...I may have figured this out.

The very last line of my custom Sieve code is:

Code:
#redirect all other mail to the inbox
  keep;
So, if I understand how all this works, the Section 4 rules, set up through the FM rules interface, are run through, BUT SO IS MY CUSTOM SIEVE CODE! So, since none of my custom sieve rules apply to the emails in question, it all fall through to the end and then the keep command retains a copy in the inbox.

It seems to me that I've got a couple of choices....

I could keep using custom Sieve only, as I have been doing for years.

If I wanted to use the FM rules interface so I could create a rule from a search, for example, is there I way I could alter the code so that my custom sieve rules are only considered if a given email does not satisfy any of the FM rules interface rules I have set up?
camner is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +9. The time now is 11:05 AM.

 

Copyright EmailDiscussions.com 1998-2013. All Rights Reserved. Privacy Policy