Live data from Hacker News

Sieve: An Email Filtering Language (RFC 5228)

rfc-editor.org

21–25 of 25 posts

Re: Sieve: An Email Filtering Language (RFC 5228)

#21
post #13

I always want to have a programmable mailserver, but not just for filtering. I hope it can also do things like calling API then react according to the respond etc. It's like a eBPF program but for mailservers. I'm not sure Sieve is a language that enables such usage. I know maybe it's a domain-specific language, but since it's a language capable of programming the server, I would rather expect more from it than "it's…

Sieve seems not powerful enough. I had this though experiment a few days ago: What if you could run code in a sandbox on the server (javascript, webassembly?) with api's (provided by the server) to access mailboxes/messages and to take actions (move to folder, change message flags), and perhaps some networking (e.g. dns blocklist)?

Re: Sieve: An Email Filtering Language (RFC 5228)

#22
post #12

I am Fastmail customer so I have access to their Sieve functionality but decided against it. For me the fundamental limitation is that Sieve looks at email only once, when email arrives. I wanted to do the things like: archive email after 3 days being in my inbox, or older than my most recent read email (which would mean I scanned the inbox and the summary was enough) etc. I ended up implementing a Python script that…

Yeah, "keep sales newsletters for two weeks, then delete forever" has been a thing I've wanted for a long time. Nothing seems to make that easy. I've been leaning towards local processing on an mbox folder... that would also let me build up multiple Bayesian filters to try categorizing my other mail - why does almost everyone only auto-categorize spam? Google kinda broke out of that with their "social" and "important…

Interesting indeed. What kind of classification would you have in mind? Separate out different types of senders, e.g. friend groups, or professional clients? Or more the personal email, transactional email, newsletter?

For bayesian junk filtering to work, you train with messages marked either as junk or nonjunk. I suppose you could train based on positive tag, and assume the message has the opposite signal if it didn't get that tag. My historic email is only classified for (non)junk. If I would start more classifications, I would have to ignore the existing messages.

Fyi, I'm working on https://github.com/mjl-/mox, which also includes a bayesian filter. This sounds implementable.

Re: Sieve: An Email Filtering Language (RFC 5228)

#23
post #22
post #12

Earlier quoted context omitted.

Yeah, "keep sales newsletters for two weeks, then delete forever" has been a thing I've wanted for a long time. Nothing seems to make that easy. I've been leaning towards local processing on an mbox folder... that would also let me build up multiple Bayesian filters to try categorizing my other mail - why does almost everyone only auto-categorize spam? Google kinda broke out of that with their "social" and "important…

Interesting indeed. What kind of classification would you have in mind? Separate out different types of senders, e.g. friend groups, or professional clients? Or more the personal email, transactional email, newsletter? For bayesian junk filtering to work, you train with messages marked either as junk or nonjunk. I suppose you could train based on positive tag, and assume the message has the opposite signal if it didn…

Gmail's categories are a pretty reasonable starting place: primary, social, updates, forums, promotions.

All reasonably identifiable by word choices, and often at extremely different urgency / priority levels.

But I would personally also have an "interesting" category for newsletters and whatnot that are more likely to get a full read (newsblur has a weak version of this for my RSS, it's nice). And an "urgent" category that notifies more visibly than others. "Recruiters" is also periodically useful - a bunch of cold emails filled with buzzwords, should be identifiable a mile away.

But underneath it all it's mostly that it confuses me that there's so little ability to experiment here. Shared always-updating spam filters makes sense, but there's a lot of similar things people could try unique to their needs that are just totally unsupported. I don't want better global categorization (gmail), I want personalization. Email is weirdly non-personal in the vast majority of systems, and I suspect it's part of why people burn out on it and switch to a never-ending churn of apps that are a better fit for one piece or another.

Re: Sieve: An Email Filtering Language (RFC 5228)

#24
post #19
post #11

this was part of cyrus imap from cmu, which iirc was the first big imap server to support server side indexes. (i think they were bdbs, iirc) believe it or not, but many hugely popular applications from 20+ years ago didn't even implement indexing. in this case if you had too much mail your imap client would just time out. well through the mid-2000s you even had to use a third party plugin for outlook called "lookout…

FWIW they were not Berkley DBs. IIRC the only db was the duplicate suppression feature. Folders (mailboxes in proper IMAP lingo) had hand-built indexes. Good stuff. Credit to jgm, the original author.

that sounds right. and yes, very good stuff! i remember thinking at the time "hah. this is built with real computer science!". and well, at the time, it was the only thing that worked for large mail spools.

i also think it was the first support for sasl(?) encryption upgrades for legacy text/tcp mail protocols

also, fun sidebar: indices vs. indexes, both are apparently valid english... but it seems computer people have adopted the latter almost exclusively. never noticed it before...

Re: Sieve: An Email Filtering Language (RFC 5228)

#25
post #24
post #19

Earlier quoted context omitted.

FWIW they were not Berkley DBs. IIRC the only db was the duplicate suppression feature. Folders (mailboxes in proper IMAP lingo) had hand-built indexes. Good stuff. Credit to jgm, the original author.

that sounds right. and yes, very good stuff! i remember thinking at the time "hah. this is built with real computer science!". and well, at the time, it was the only thing that worked for large mail spools. i also think it was the first support for sasl(?) encryption upgrades for legacy text/tcp mail protocols also, fun sidebar: indices vs. indexes, both are apparently valid english... but it seems computer people ha…

SASL came out as a generalization of the IMAP AUTHENTICATE mechanism. CMU wanted Kerberos to work and it had been done as something of a one-off in telnet, and initially in IMAP. There were a couple companion protocols proposed for IMAP (stuff like contacts) that the same group was working on, and they wanted to leverage the same mechanism. From there, might as well do the same thing for POP and SMTP, etc. So they started working on a library (which Cyrus IMAP didn’t use for at least a while, sorry my fault).

Kind of funny that SASL is the most durable piece of the effort.

(I doubt this is entirely accurate. I wasn’t there for a lot of it.)

Post reply on HN