A command-line mail fetcher for Linux
Eubin is a Python script to fetch emails from remote POP3 servers. It supports secure retrieval though SSL/TLS. Also it integrates well with external password managers (like pass).
The latest version is eubin-v1.2.2.tar.gz (requires Python ≥ 3.4).
Extract files from the archive and run make & make install
$ tar -xf eubin-1.2.1.tgz $ cd eubin $ make && sudo make install
After configuration (see below), just run eubin from your command line.
$ eubin eubin[INFO]: Connect to mail.example.com:995 [SSL=True] eubin[INFO]: 0 messages retrieved (0 bytes)
If you want its output to be more verbose, add '-v' option.
$ eubin -v eubin[DEBUG]: --------- firstname.lastname@example.org --------- eubin[INFO]: Connect to mail.example.com:995 [SSL=True] eubin[DEBUG]: Login as email@example.com [APOP=False] eubin[DEBUG]: Download to "/home/fujimoto/mail/" [COPY=True] eubin[DEBUG]: 679 messages in maildrop (10 MB) eubin[INFO]: 0 messages retrieved (0 bytes)
First, create ".eubin" directory in your home path.
You can put more than one configuration file in this directory. For example, if you have two email accounts 'firstname.lastname@example.org' and 'email@example.com', you will set up as follows.
/home/fujimoto/ └─.eubin/ ├─ firstname.lastname@example.org └─ email@example.com
Configuration files are written in INI-file syntax and you need to set a handful of parameters. Below is a full configuration example that you can start to work on.
[server] host = pop.gmail.com port = 995 [account] user = firstname.lastname@example.org pass = password # Or you can ask your password manager though pass_eval # pass_eval = pass show email@example.com [retrieval] dest = ~/mail/ # Your local email folder (must be Maildir format) leavecopy = yes # Leave a copy of messages on the remote server. leavemax = # Number of mails to leave (Leave it blank to never delete). timeout = 600 # (sec) [security] apop = no # Hash your password before sending (APOP) overssl = yes # Encrypt connection with TLS starttls = no # Negotiate TLS after connection
Originally, POP3 requires its client to send username and password in plaintext. This is hardly secure, since everyone between you and the server knows your login secret. Some counter-measure was seriously in need, so RFC-1460 was written and a new command APOP was added to POP3 (circa 1993).
The basic idea of APOP is quite simple. Instead of sending a cleartext password, send the hash of the password. Here is how it works: first, POP3 server sends a nonce to you, then you hash the "nonce + secret" using MD5 algorithm, and send back the result to the server. Since one cannot produce the correct hash without knowing the secret, the server can authenticate you just by checking the hash value. This type of auth is called "Challenge-response authentication", because the server first "challenges" you with a nonce, and you need to "respond" it with a correct answer.
The important thing to note is that APOP only secures your password. All other parts of the connection (including your emails!) are known to network sniffers. Since securing the entire connection using SSL/TLS is the norm nowadays, you normally don't need to use APOP, except you are interacting with a (dated) POP3 server without SSL/TLS support.
SSL came to the town and was getting popular in late '90s. The problem at the time was that not all clients supported encryption. This means that a POP3 server must handle both types of clients, those with a SSL support and those without one.
But how? The immediate solution was to set up a separate port (995) for SSL-enabled clients, while operating the traditional TCP port (110) for non-SSL clients. This solution did work, and many servers today still operate in this mode. However, it requires users to know upfront if the server does support encryptions or not. Also some people thought that it's more elegant to handle both cases using a single port (read RFC-2595#section-7 for more details).
STARTTLS was invented as an alternative solution. In this schema, all clients first connect to the traditional port without encryption, but if both parties support encryption, the client can initiate SSL by issuing a special command named "STLS". The connection thereafter gets encrypted. If the server or the client lacks the SSL support, they can just go on without encryption.
So is STARTTLS as secure as a normal SSL/TLS connection? Not quite so. Since the transmission before STLS is not encrypted, someone in the middle can impersonate the server and tell you that SSL/TLS is not supported in this connection. In this case, you end up either 1) continuing without encryption anyway, or 2) aborting the connection without getting any message. Neither situation is in good shape.
If possible, you'd probably be better off just using the encrypted port instead of relying on STARTTLS.
NOTE: Eubin (or more correctly, the underlying "poplib" library) should raise an exception if the server does not understand STLS command when "starttls" is enabled.
I hereby place my work "eubin" into the public domain. All my copyrights, including related and neighbouring rights, of this work are abandoned.
2018 Fujimoto Seiji <firstname.lastname@example.org>
Back to index