Cypht Webmail Screen Shots – Mobile Version

I had a request on the “Cypht Webmail Screen Shots” post to share some mobile/responsive views of the program. Since I always aim to please, and since the percentage of people with even a shred of interest in this project is so very very small, here it is!

Overall, my design skills fall somewhere between terrible and total shit. My design premise for the Cypht UI has been: “Don’t pretend you know what colors go well together. Don’t fool yourself into thinking you can make something slick. JUST KEEP IT SIMPLE DUMMY“.

I’m pleasantly surprised with the result. It’s pretty standard webmail fare, super simple, and reasonably consistent across browsers.


The main menu. Available by swiping right on any page, or with the awkward looking triangle in the upper left corner of a page.


I pretty much never write E-mail on my phone. But I could!


Yay, only 1 unread message! Also, if you have not checked out Humble Bundle, you should.


The site settings page


General site settings. Kind of squeezed in there, but not too bad!


Search all the things again!


Read a search result. The message view page is tricky on mobile. This one looks pretty good, but others not so much. It’s a work in progress.


Just a teeny tiny calendar. Nothing to see here.


RSS news feed for my favorite Linux news site.


Server management page


“Quick add” dialog on the server page. So cool.


Keyboard shortcut management.


IMAP folder management.


Save settings page.

There are some noticeable omissions to this list, specifically the contacts management interface and the profiles page. I left profiles out because it looks like dog poop, and I left contacts out because I realized the screenshot was of my actual contacts and that would be dumb to post. It looked pretty good though! All in all, Cypht is pretty responsive. Writing this post helped me identify some areas we need to work on, so thanks to the person who requested it!

Cypht Webmail Screen Shots

This is YET ANOTHER post to shill for Cypht, my Open Source webmail project. But instead of droning on endlessly about technical mumbo-jumbo like I usually do, this one has pictures! They are pretty! Let’s look at them!


Browsing IMAP folders like it’s the noughts yo!


Fancy compose form with an HTML editor. Cypht also supports text only for outbound E-mail (and FTW).


The Servers page is where you add data sources to your account. Without data sources there is not much to look at.


Site settings page with expandable categories.


Search all the things at once!


Read one of the things you searched for!


This webmail program has a calendar. It’s truly amazing.


Home page on mobile (S5 emulation with Chromium)


Main menu on mobile


RSS feed list view on mobile


I almost forgot we support themes. I suck at it, but it’s pretty easy. Maybe somebody who doesn’t suck at it will make some more


This theme is called “VT100”. See what I mean about sucking at themes?

There is more, but I’m too lazy to set up decent looking test data and you get the idea. All this uploading of images has made me tired, so I think I will go take a nap.

5 Cool Cypht Webmail Features

Cypht is the Open Source webmail program I have been toiling away on for the last few years. It stands out from the competition because of a few unique options, not that it doesn’t have its own warts. But let’s focus on the positive, and not talk about things like the painful installation process, outstanding bugs, or unfinished features. I wouldn’t be doing a very good job converting this blog into a propaganda platform for the project with a title like “5 Shitty Cypht Webmail Features“. Also, I’m a dork. What I think qualifies as cool is known to be subjective.

1. Stand Alone Authentication
Pretty boring opener, but bear with me. Typically webmail programs are designed to point to an E-mail source, like an IMAP or POP3 server, for authentication. They pass the username and password you give them on to the E-mail server, which then tells the webmail program if you are legit or bogus. Cypht boldly (not really) breaks this paradigm by splitting authentication from your E-mail sources.

We support using LDAP or a database to authenticate users, as well as the old-school method of using a pre-configured IMAP or POP3 server. Adding new authentication mechanisms is designed to be easy (relatively), so any source that can verify your username and password can be coded up. We even support a dynamic login process that lets you pick from common E-mail service providers, and can auto-discover E-mail services for a domain (sometimes).

2. Combined Views
Cypht provides combined lists of E-mail messages from all your accounts. One of the reasons I started working on yet another webmail program, was because I wanted this feature. I spend 95% of my time using these views for my E-mail needs, and very little time browsing folders and pages like it’s 1999 (though Cypht supports this as well)

Show me the latest 20 unread messages from each of my accounts over the last 2 weeks in one list? Done. Search for the boarding pass I misplaced even though I forgot which E-mail account I used to make the reservation, and the plane takes off in 5 minutes? Done (this actually happened to me). If you have more than one E-mail account, combined views quickly become the bee’s knees. If you only have one E-mail address, you probably should have skipped this section.

3. Module Sets
Plugins are cool. Module sets are cooler. First of all, they sound cooler. Secondly, module sets are not just a way to bolt on features. Cypht is entirely built of module sets, and a framework to run them. Only one is required, the “core” set. It does things like basic page layout and login/logout. Everything else (IMAP, SMTP, POP3, RSS, contacts, profiles, the list goes on) is its own module set, and can be enabled or disabled independently.

As if that wasn’t the ultimate in coolness, there’s more! Module sets can override each other. Don’t like the default behavior of a core module? You can change it without hacking a single line of Cypht code by creating your own module set that overrides it. I need a sweater it’s getting so cool in here! There is even some poorly written documentation about module sets for aspiring developers.

4. Focus on Security
Security is serious business for a webmail program. So many attack vectors! From filtering out nasties, to TLS everywhere, to encrypting data at rest – Cypht goes the extra mile to try to cover all the bases. Cypht was built with security and privacy as core design principles.

Securing a complex web application is a process, and we welcome feedback and suggestions to continue to improve. For the gory details, check out our security page with a list of impressive sounding technical stuff.

5. Production and Debug Mode
Cypht has two modes of operation. “Debug” mode is what you use when troubleshooting issues or doing development. “Production” mode is what you use when … in production. Debug mode fire-hoses your PHP log with information about each request, enables all errors and warnings, and activates new modules as you create them for a quick write-then-test cycle. Production mode uses combined and minfied assets, silences warnings, and pre-calculates module dependencies.

If you are looking for a different kind of webmail, one that is lightweight, secure, and has a complicated install process -check out Cypht. Or don’t. It’s cool.

Be Kind, Send Text

There are still some of us out there, an ever dwindling group I’m sure, who don’t want images or borders or colors or bold fonts in an E-mail. I know that using HTML markup to send fancy-pants E-mail is popular with the kids these days, I even begrudgingly support it in my own webmail client. But for the love of all that is holy, if you are going to send HTML formatted E-mails (or any other rich text format), please do it correctly – INCLUDE A TEXT VERSION.

The MIME standard, which defines the structure of “modern” E-mail messages, already supports exactly what you need: Just use “multipart/alternative”, and send a text only version along with the wiz-bang HTML copy you spent a week styling (most of which any sane client will strip out anyway). it’s not rocket science, and even though these standards are decades old, it’s surprising how many companies and services still get it wrong. In the last few weeks alone, I have run across the following:

No text part at all

This is the most common. You didn’t even try to send a text version of the content. Keep in mind, it’s not just curmudgeons like myself who won’t read your message, but people with accessibility requirements (think blind people using screen readers) are also going to have a hard time finding the content hidden in 50 nested divs. Why do you hate blind people?

HTML markup in the text part

You tried, I will give you credit for that. But you failed miserably, because now I get a text message with a bunch of raw HTML tags and useless style rules with some content buried deep within. Thanks, but no thanks.

A text part without the same content

You included a text part. It’s not raw HTML thank goodness. Sadly, it’s just a short message to click a link and read the HTML version online. I’m not going to click that link. Another common one is just an empty text part with no content at all. I appreciate your brevity! My favorite offender in this category is a major bank I do business with. They periodically send me E-mail with an HTML part and text part, yay! unfortunately, the text part is always the same. It simply reads:


Very helpful! I know LARGE BANKS have low standards for software development, but this is ridiculous.

Incorrect or missing character set

I can almost forgive you for this. You sent a text part. It has the same content as the HTML version and isn’t markup. But you used non-ASCII characters and did not include the correct character set header. The result is highly likely to render incorrectly. And you were so close to getting it right!

In conclusion, please be kind to aging oldsters like myself, and send a properly formatted text version of whatever you want me to read. Then I can write happy fun-time blog posts about rainbows instead of ranting about E-mail formats. Eh, I will probably still rant about E-mail formats, but I do like rainbows.

Psql + Vim = Happy Face

I love Vim. I use it to develop software, write blog posts, analyze and manipulate raw data, even compose E-mail. If I’m typing something and it requires more than 4 words, I do it in Vim. I was going to write a post about all the Vim tips and tricks I have consumed over the years, but that information lives almost exclusively in muscle memory, which requires too much effort to extract. Instead, I’m writing about how you can spice up your psql environment with Vim, since I just did that last week, and kind of sort of remember how I did it.

Psql is the command line client for Postgres. It’s a powerful, if somewhat boring, interface to the DB. Type an SQL statement, get an ASCII formatted result. In this way it’s similar to the mysql command line interface for that other RDMS you may have heard of. Psql has some interesting options we can use to bring the Vim goodness. That other client might have similar features, but thankfully I don’t work with that anymore and have all but forgotten it existed at all.

Vi Style Key Bindings

This is like “set -o vi” in bash, but for psql. Support for vi key-binding is provided by the readline or libedit library, so enabling this in psql can be done using the .inputrc file in your home directory. Just create the file if it does not exist, and add the following:

set editing-mode vi
set keymap vi-command

Now you can navigate the Psql command line with some Vim-like shortcuts via a limited command mode accessed with ESC. So cool!

Editing Queries With Vim

Being able to jump around the CLI is nice, but when you are building a complicated query, it’s better to have a full featured editing environment. Psql provides a command, “\e”, that will start an editor with the last query pre-loaded. When exiting the editor, the updated query will be re-run. You can control the editor with the EDITOR environment variable. Just set that to “vim” before starting psql. I define this in my .bashrc file so ANY program respecting the EDITOR variable will use Vim by default, because of course I do. The only other trick here is to make sure Vim knows that you are editing a query so we get fancy-pants syntax highlighting. Adding this to your .vimrc file should do the trick (presuming psql is using /tmp like it does on Debian):

syntax on
au BufRead /tmp/psql.edit.* set syntax=sql

Now I can seamlessly use Vim from psql to develop complex SQL statements. SO GOOD.

Query Results in Vim

In the course of developing said complex SQL statements, I’m running oodles of queries and analyzing the results. This is yet another place we can dollop Vim awesome-sauce into psql. Like the EDITOR environment variable, psql respects the PAGER variable. This defines what program will be used to display results that don’t fit in the available terminal screen real-estate. There are 3 steps to gluing this all together: 1. Setup a custom Vim syntax file to make the results all pretty; 2. create a custom Vim config to be used when displaying results; and 3. Set the correct PAGER value before starting psql.

First up, the syntax highlighting. Create a file called “dbout.vim” and put it in ~/.vim/syntax. If those folders don’t exist in your home directory, create them. Put the following super hacky syntax highlight definitions in that file:

" Vim syntax file
" " Language: db output
" " Maintainer: Jason Munro

syn region Heading start=/^ \l/ end=/[-+]\+$/
syn match Border "|"
syn match IntVal " \d\+\(\n\| \)"
syn match NullVal " NULL\(\n\| \)"
syn match NegVal " -\d\+\(\n\| \)"
syn match FloatVal " \d\+\.\d\+\(\n\| \)"
syn match NegFloatVal " -\d\+\.\d\+\(\\n\| \)"
syn match DateTime "\d\{4}-\d\{2}-\d\{2} \d\{2}:\d\{2}:\d\{2}\(\.\d\{1,}\|\)"
syn match TrueVal " t\(\n\| \)"
syn match FalseVal " f\(\n\| \)"

hi def Heading ctermfg=246
hi def IntVal ctermfg=229
hi def FalseVal ctermfg=88
hi def NullVal ctermfg=242
hi def Border ctermfg=240
hi def NegFloatVal ctermfg=160
hi def FloatVal ctermfg=230
hi def NegVal ctermfg=160
hi def DateTime ctermfg=111
hi def TrueVal ctermfg=64

The color definitions I’m using here expect a 256 color capable terminal, those with less will have to fiddle with the ctermfg values. Next, create a custom Vim configuration for the results that uses the syntax highlighting. Just copy your existing .vimrc to .vimrcpg, and add the following lines:

syntax on
set syntax=dbout

Finally, set the PAGER environment variable before running psql:

export PAGER='vim -R -u ~/.vimrcpg -'

And, voila! Check out the super cool color highlighting from the obviously very useful “test” table I just created!
In conclusion, psql is awesome, but psql with Vim integration is awesome-er.