EmailDiscussions.com - Lables are coming?

EmailDiscussions.com (http://www.emaildiscussions.com/index.php)

- FastMail Forum (http://www.emaildiscussions.com/forumdisplay.php?f=27)

- - Lables are coming? (http://www.emaildiscussions.com/showthread.php?t=76159)

Labels are coming?

Spotted on Twitter.

Quote:

Hi Jason! Labels are now available on beta: beta.fastmail.com/settings/filte…. Let us know what you think!

Oops! :eek:

Quote:

Hi Olly! We're sorry for the confusion - labels are still in limited testing and are not available on beta just yet. If you'd like to submit a support ticket with your email address, we'd be happy to add you to our next round of invites for user testing. fastmail.com/support

Fantastic!
This is a great move and, for me anyway, will fill a hole that has had me checking out alternative email providers for some months now. (So far haven't found any that both have labels and let me create email aliases on the fly.)

How is a "round of user testing" different from "the beta service" that anyone can use if they log in to it?

So cool! :cool: Really looking forward to this.
Curious how they will manage label compatibility with IMAP… if they will at all.

Quote:

Originally Posted by misc (Post 614740)

So cool! :cool: Really looking forward to this.
Curious how they will manage label compatibility with IMAP… if they will at all.

One possible approach would be only to support labels through the web interface, FastMail App and other JMAP enabled clients. Allowing IMAP clients to create new labels is tricky, and a solution that pretends labels are folders (as Gmail partly does) has some significant performance issues and tricky edge cases. JMAP has been designed with label support in mind.

Labels are now available on Fastmail's beta website.
https://beta.fastmail.com/help/receive/labels-beta.html

Quote:

Originally Posted by Berenburger (Post 614892)

Labels are now available on Fastmail's beta website.
https://beta.fastmail.com/help/receive/labels-beta.html

I can see some issues with this, unless I misunderstand the implementation. The benefit of labels is that you can attach multiple labels to a message without needing to keep multiple copies of the message. JMAP, indeed, supports this. When using folder mode, you need to keep a copy of the message in each folder, unless the FastMail JMAP server is faking folder mode, suppressing the additional copies which I guess is possible. That would make it similar in effect to what Gmail does, with probably the same tricky edge cases and difficulties if you want to migrate to a non JMAP mail service.

I still think the addition of labels to FastMail is a positive move, but I would like to understand the implications.

I would also be curious how this labels stuff translates into sieve code. But since I cannot enable the the new rules stuff anymore (because I have my own sieve additions) I can't evaluate labels either which requires the new rules stuff to be turned on.:mad: I added this complaint to my ticket about this new problem.

Simple label mode sieve code

I have been using the new rules system, which still allows custom sieve code to be inserted at one of three locations:

At the very top of the sieve code.
After the blocked senders and spam filters have executed, but before the normal user configured rules.
At the very end of the sieve code.

When using the new rules and label modes, the automatically created sieve code looks quite different to allow the new features to work. The good news is that in most cases you should be able to add old-style custom sieve before or after the automatically created code.

Below is an example where I have only created the following two user interface rules. I also inserted custom sieve comments (USER CODE A/B/C) at the three locations shown above. Other settings are defaulted.

File #1: If subject:file, then Pin, Add label "Test", Skip inbox, and Continue to apply other rules.
File #2: If subject:file, then Notify me, Add label "Test", Skip inbox, and Continue to apply other rules.

Code:

require ["fileinto", "reject", "vacation", "notify", "envelope", "body", "relational", "regex", "subaddress", 

  "copy", "mailbox", "mboxmetadata", "servermetadata", "date", "index", "comparator-i;ascii-numeric",

  "variables", "imap4flags", "editheader", "duplicate", "vacation-seconds", "fcc", "x-cyrus-jmapquery"];

# USER CODE A *************************************************************

### 1. Sieve generated for save-on-SMTP identities

# You do not have any identities with special filing.



### 2. Sieve generated for blocked senders

# You have no blocked senders.



### 3. Sieve generated for spam protection

if not header :matches "X-Spam-Known-Sender" "yes*" {

  if 

    allof(

    header :contains "X-Backscatter" "yes",

    not header :matches "X-LinkName" "*"

    )

  {

    fileinto "\\Junk";

    stop;

  }

  if header :value "ge" :comparator "i;ascii-numeric" "X-Spam-score" "5" {

    fileinto "\\Junk";

    stop;

  }

}



# USER CODE B *************************************************************

### 4. User configured rules



### 4a. Calculate rule actions



# Rule File #1

# Search: "subject:file"

if 

  allof( not string :is "${stop}" "Y",

    jmapquery text:

  {

     "subject" : "file"

  }

.

  )

{

  addflag "\\Flagged";

  

  set "L0_Test" "Y";

  

  set "skipinbox" "Y";

  

}



# Rule File #2

# Search: "subject:file"

if 

  allof( not string :is "${stop}" "Y",

    jmapquery text:

  {

     "subject" : "file"

  }

.

  )

{

  addflag "$notify";

  

  set "L1_Testing" "Y";

  

  set "skipinbox" "Y";

  

}



### 4b. Rule sent message to trash

if string :is "${deletetotrash}" "Y" {

  fileinto "\\Trash";

}



### 4c. Rule says message is spam

elsif string :is "${spam}" "Y" {

  fileinto "\\Junk";

}



### 4d. Do rule actions

else {

  if string :is "${L0_Test}" "Y" {

    set "hasmailbox" "Y";

    fileinto :copy "INBOX.Test";

  }

  if string :is "${L1_Testing}" "Y" {

    set "hasmailbox" "Y";

    fileinto :copy "INBOX.Testing";

  }

  if string :is "${skipinbox}" "Y" {

    if string :is "${hasmailbox}" "Y" {

      discard;

    }

    else {

      fileinto "\\Archive";

    }

  }

  else {

    ### 4e. Sieve generated for fetch mail filing

    # You have no pop-links filing into special folders.

  }

  

  ### 5. Sieve generated for vacation responses

  # You do not have vacation responses enabled.

  

  ### 6. Sieve generated for calendar preferences

  if 

    allof(

    header :is "X-ME-Cal-Method" "request",

    not exists "X-ME-Cal-Exists",

    header :contains "X-Spam-Known-Sender" "in-addressbook"

    )

  {

    notify :method "addcal";

  }

  elsif exists "X-ME-Cal-Exists" {

    notify :method "updatecal";

  }

}



if string :is "${stop}" "Y" {

#   For backwards compatibility

}



# USER CODE C *************************************************************

Quote:

Originally Posted by n5bb (Post 614940)

I have been using the new rules system, which still allows custom sieve code to be inserted at one of three locations:

At the very top of the sieve code.
After the blocked senders and spam filters have executed, but before the normal user configured rules.
At the very end of the sieve code.

AH HA! Thank you n5bb. I looked back at the areas you described because I was sure there was more user edit areas. Turns out there was more in the old code but not in the new code and I was using one of the user edit code sections that was removed in beta.:eek: It was only a disabled place holder for doing special testing so not critical. Beta wasn't checking for this until last week. I removed it and now I can re-enable beta again. Now I can cancel my ticket on this.:)

Quote:

Originally Posted by xyzzy (Post 614943)

You are most welcome.

Yes, there used to be more places they allowed us to insert custom sieve. But I think that the current setup is sufficient. It's pretty easy now to set up a rule based on the contents of a message using the current user interface features. I have removed nearly all of my old custom sieve, and I'm starting to clean up my normal rules.

Bill

Quote:

Originally Posted by n5bb (Post 614940)

Below is an example where I have only created the following two user interface rules. I also inserted custom sieve comments (USER CODE A/B/C) at the three locations shown above. Other settings are defaulted.

File #1: If subject:file, then Pin, Add label "Test", Skip inbox, and Continue to apply other rules.
File #2: If subject:file, then Notify me, Add label "Test", Skip inbox, and Continue to apply other rules.[/code]

I'm missing something in the code for this. I enabled labels in the preferences and from what I can see in the sieve code nothing is different (although maybe I missed something). With labels enabled a rule's "move to" becomes "label" but the code still fileinto's as if it's a folder.

What in your actual rules for those examples spawned the jmapquery I see in your code? I don't see that. It's the matching criteria that you show as subject:file that's confusing me.

Sieve jmapquery test

Quote:

Originally Posted by xyzzy (Post 614948)

...What in your actual rules for those examples spawned the jmapquery I see in your code? I don't see that. It's the matching criteria that you show as subject:file that's confusing me.

The rule I created in the rules user interface specified the following condition:

Quote:

If all of the following conditions apply
(1) Subject file

So "file" is the string which is used to search the subject field. I can't find any documentation so far on the jmapquery sieve extension, but this is what I imagine is happening. See RFC5228 in section 2.4.2. Strings.

Quote:

For entering larger amounts of text, such as an email message, a multi-line form is allowed. It starts with the keyword "text:", followed by a CRLF, and ends with the sequence of a CRLF, a single period, and another CRLF. The CRLF before the final period is considered part of the value.

In my Rule File #1 section of the sieve code, the allof test has two arguments:

not string :is "$(stop)" "Y"
jmapquery text: { "subject" : "file" }

So that allof test will be satisfied if both the value of the (stop) variable is not "Y" AND the result of the jmapquery search for the string "file" in the header "subject" is true. If satisfied, the allof test actions which are performed are:

The message is flagged.
The value of the variable "L0_Test" is set to "Y".
The value of the variable "skipinbox" is set to "Y".

Then in the ### 4d. Do rule actions section of the sieve script, the L0_Test variable value will cause the "hasmailbox" variable value to be set to "Y" and the message will be copied into the Test folder. A bit later in the script, the "skipinbox" and "hasmailbox" variables will cause the implicit keep copy of the message to be discarded, so that it won't be filed into the Inbox.

I now wish I had used a different search string other than "file" for my example, since it could accidentally be interpreted as some filing operation rather than the subject search string.

Bill

Quote:

Originally Posted by n5bb (Post 614949)

The rule I created in the rules user interface specified the following condition:

If all of the following conditions apply
(1) Subject file

So "file" is the string which is used to search the subject field. I can't find any documentation so far on the jmapquery sieve extension, but this is what I imagine is happening.

And that's what is confusing me. For example if I select the match condition if subject contains file then I would expect it to generate the sieve code

Code:

if header :contains "Subject" "file"

and that's what I get (also similar variants for the other matching conditions). This is in beta with labels enabled. It's not any different than what's always been generated for the "old" rules. If the jmapquery is doing the same thing I don't know what advantage it would have over subject :contains, labels or no labels.

I wonder if your beta is different from my beta (since I expect labels are still a work in progress). Since I only got beta working again tonight after a week I wonder if the implementation has changed so that mine is "newer" than yours assuming you have been using beta all along I I only re-enabled it tonight. Two things to try to be sure you have the latest (not sure which one might work or even if this theory is correct) is log out and log back into beta and/or (b) turn off the new rules and then turn them back on again (caution, off/on looses all the rules changes made in the beta).

The rest of the code that sets and tests the various variables is straight forward although it bothers me somewhat how efficient the standard filter case is to fileinto :copy the message and then discard the original. But that's a server problem and not our problem.

Quote:

I can't find any documentation so far on the jmapquery sieve extension, but this is what I imagine is happening. See RFC5228 in section 2.4.2. Strings

The ability to enter multi-line strings with text: was something I was unaware of. Nice to know. Thanks.

FWIW, ignoring the reason why I cannot get the jmapquery test I did find what I think is a little more info in this web site section 4.4 (Email/query). And that ties back to RFC 8620 section 5.5. So I guess the "{subject:file}" is a "Mailbox/query" and the FM jmapquery syntax is to simply map the brace enclosed stuff directly into one of those /query statements. Just guessing here. But if this is correct, then according to RFC 8620 section 5.5 FM was (is?) intending to support large emails but maybe they changed their mind so that's why I don't now see it.

Two observations:

(a) for Sieve rules that FM generates this is not important, but if anyone adds their own rules that use the jmapquery thing I think it would be terribly easy to miss out the line that just has that dot on it... (I do recognise that it's a common end-of-something delimiter, seen inside other protocols, but it's machine-friendly rather than user-friendly.)

(b) why is jmapquery being used instead of simpler match tests etc? It may be from FM's point of view this makes the logic for their rule-generator simpler. It might also be more efficient (in terms of server load) if it's been implemented with more modern code features.