LibEtPan is one C library for IMAP, SMTP, JMAP, ActiveSync and local mailboxes

One library for talking to mail and news servers

LibEtPan is described as a portable C mail library for accessing, parsing and composing email and news messages. The scope of that sentence is bigger than it first appears, because the features list covers four separate concerns. The protocols are IMAP, SMTP, POP3, NNTP, JMAP and ActiveSync, along with RSS and Atom feeds and Gmail helpers. The message handling covers RFC 822 and IMF, MIME, and message composition, which is the part that decides whether a mail client can send a reply with an inline image. The local storage side supports Maildir, mbox, MH and a cache database, so the same program can read a server mailbox and a local one. And the security layer covers TLS, SASL, OpenPGP and S/MIME. The platform list is Linux, macOS, iOS, Android and Windows, and the project is written in C. For a reader deciding on it, the honest summary is that this is infrastructure for a mail client, not a mail client.

The build paths diverge, and Linux has moved to ICU

The primary maintained build paths are configure and make on Linux and macOS, and Xcode on macOS and iOS, and Android and Windows build files are also included. That sentence is the first thing to internalise, because there is no single build command that works everywhere and the per-platform instructions are short and specific. On Linux you install Autoconf, Automake, Libtool and ICU development headers, libraries and converter data, for example libicu-dev on Ubuntu, and then build:

./autogen.sh --with-icu=yes --disable-iconv
make

The maintained Linux build and the GitHub workflow use ICU for charset conversion, and GNU libiconv is not required. The unit tests are run separately:

make -C unittest check

The flag pair in the autogen call is the part that will bite you if you copy a command from an old thread. An older build path used iconv, and the current one asks for ICU explicitly and turns iconv off. ICU is a heavier dependency than iconv, and it brings converter data with it, which is a cost that buys correct charset behaviour on modern Linux distributions. The Android build makes the same choice permanently: it no longer builds or links GNU libiconv at all.

macOS and iOS have both an autotools path and an Xcode workspace

On macOS with configure and make, the instructions are the familiar autotools sequence. Install Autoconf, Automake and Libtool, then build:

./autogen.sh
./configure
make

For macOS and iOS with Xcode, the project expects Xcode and CMake, and the workspace is prepared with a bootstrap script in the build-mac directory:

cd build-mac
./bootstrap.sh
open libetpan.xcworkspace

Having both is not redundancy, it is two different consumers. The autotools path is for people building the library on a workstation or for a Unix-like target, while the Xcode workspace is the path for the Apple platforms, where the project also ships a Package.swift file for Swift Package Manager and a build-spm directory. The README ties the pinned ICU submodule explicitly to the Android dependency bootstrap, so if you also target Android, the same charset decision carries across your Apple and Android builds.

Android is an NDK script, Windows is a Visual Studio solution

The Android instructions are worth reading carefully because they pin the toolchain rather than describing it. You install Android NDK r23 or newer, set ANDROID_NDK, and build from the build-android directory:

export ANDROID_NDK=$HOME/Library/Android/sdk/ndk/27.1.12297006
cd build-android
./build.sh

The path in the example is a macOS one, which tells you the script is developed on a Mac, and the build-android README covers dependency details, supported ABIs and a sample app. The Windows path is the most conventional of the set. You open build-windows/libetpan.sln in Visual Studio and build the solution, and the build-windows README lists the supported Visual Studio versions and the required third-party binaries. Between them, the Android and Windows instructions are the practical reality of a C library with a wide platform ambition, each target needs its own build entry point, its own dependency story and its own instructions. If you maintain a fork, that is where your maintenance cost sits.

What is in the repository, and what the release history says

The top level of the repository shows a mature autotools project with modern additions. There is autogen.sh, configure.ac, m4/, Makefile.am, rules.mk and libetpan-config.h.in, plus libetpan.pc.in for pkg-config, and a ChangeLog, NEWS and RELEASE.md for the release process. The source lives in src/ with public headers in include/, documentation in doc/, tools/, tests/ and unittest/, and a dependencies/ directory plus a .gitmodules file for the pinned ICU submodule. There is also a skills/ directory and an AGENTS.md file, which suggests the project has been set up for agent assisted work as well as for humans. The release history is the interesting part for an adopter. Version 1.9.4 was published on 2019-11-01, version 1.10 on 2026-05-22 and version 1.10.1 on 2026-06-14, and the last push was on 2026-10-09. A gap of six and a half years between 1.9.4 and 1.10 suggests the project went quiet and came back, so the version numbers alone tell you little about how often the code changes. The licence is the other thing to check: it is a custom licence that GitHub cannot classify, and the LICENSE file is the only authority on what you may do with it.

Where LibEtPan is the wrong choice

Three cases stand out. The first is a program that only needs to send a message over SMTP. Linking a library that also implements IMAP, POP3, NNTP, JMAP, ActiveSync, RSS and Atom, plus OpenPGP and S/MIME, is a dependency cost and an attack surface cost for a fraction of the feature set. The second is a target that is not on the platform list. Linux, macOS, iOS, Android and Windows have build paths; anything else means maintaining a port yourself. The third is the licence. The project uses a custom licence, and while a permissive licence would let you vendor the code without ceremony, an unclassified custom licence means every downstream user, including a commercial distributor, has to read it. That is not a technical objection, but it is a real one for a dependency that ends up in a shipped product.

Editorial conclusion

Adopt LibEtPan if you are writing C or a language with a C binding and need real mail protocol support, local mailbox formats and message composition in one dependency. Do not adopt it if your platform tooling is not among Linux, macOS, iOS, Android and Windows, or if you need a licence you can read at a glance, because the project uses a custom licence that GitHub cannot classify and you must read the LICENSE file yourself. Before you start, check the DEPENDENCIES.md file for your platform, confirm that your platform uses the maintained ICU charset conversion path, and confirm that the build scripts for your target, whether autotools, Xcode, the Android NDK script or the Visual Studio solution, fit your pipeline.

Frequently asked questions

Official sources

1. dinhvh/libetpan on GitHub
2. Issues
3. README
4. Releases