Sieve is a standard language for filtering email addresses, used to do anything from filing messages into inboxes to forwarding them to another address. It’s a fairly well-established IETF standard. It’s what powers the filters in our webmail.
This update adds a little love to our implementation, with four new extensions:
- We’ve added the “variables” extension, which lets you compose more complicated scripts with an internal state.
- The “subaddress” extension lets you split a username from its alias tag (more on that later!) and filter on either part
- The “mailbox” extension lets you test for the existence of mailboxes
- The “imap4flags” extension lets you flag messages as they get delivered.
A lot of internal work went into making this possible, and we should be in a pretty good position to add more extensions in the future!
Currently, our routing for custom domains is basic, but functional. It lets you route any address or prefix of one on a domain you own anywhere else.
That’s actually a subset of what Sieve does for users already. Of course, by the time you’re executing a user’s Sieve script, you’ve already routed that mail to a user…
Enter account-wide Sieve scripts. These will basically give you a lot of flexibility in redirecting any emails that reach your account, whether on a custom domain or not. They run before user scripts do, which gives them a chance to redirect the mail as necessary. Otherwise, they’re the same.
We haven’t replaced the old routing with Sieve yet, but at some point we hope to. First we’ll need a friendly user interface for defining rules, though.
In the meantime, if you check out the routing tab there’s a link to a basic text editor that allows you to write and save a Sieve script to run at the account level. You don’t need to use this- you can continue to use the simpler routing rules UI, or use a combination of the two.
All user addresses on shared domains now gain some useful aliases! Basically, if you have a “firstname.lastname@example.org” user, you can now give out the address “email@example.com” or “firstname.lastname@example.org”, where tagged can be anything. These addresses all deliver mail to that user. Give them out to unwanted email marketers or as signups on websites! (We recommend you use "_" as the tag separator, as “+” is well known and spammers may strip it out to get your real address.) A longer explanation has been added to our features list.
You can now send mail from addresses you own, without needing to set up an explicit user. In technical terms, you can set the envelope’s MAIL FROM to any address you own, which is either an alias on shared domains or any address on a custom domain.
For the moment, all valid user logins for an account can technically send for any address under that account. Keep that in mind if giving logins to users you don’t trust. In the future, we will likely be able to restrict sending privileges to addresses that directly rewrite to that user.
All of this should integrate with replies composed from webmail (Roundcube), which should default to sending as the alias that the email was delivered through, if available. You may need to create matching “Identities” in third party clients. (We expose the alias a mail was delivered through as a header, which could be used for automatic integration.)
Also this week, as a small bonus feature: webmail now has right click menus, thanks to the handy contextmenu plugin. Roundcube actually has quite a few interesting community plugins we hope to add in the future.
Finally, about this space.
In case you were wondering, I intended to do weekly updates detailing what’s new and what we’re working on… two weeks ago. We got a little tied up working on this update’s features.
See you next week, hopefully!