Google retires Gmail POP fetching, prompting self-hosted webmail alternatives

Google is retiring its Gmailify and desktop POP-fetching features, with full support for the website’s “Check mail from other accounts” function ending in January 2027. This change has spurred interest in self-hosted solutions like plMail, a new open-source webmail client that aggregates multiple email accounts into a single interface without requiring users to operate their own mail servers.

What happened

Gmail is winding down the ability to collect messages from external accounts directly through its web interface. While Google is not shutting down POP or IMAP access for third-party clients, the convenience of having Gmail fetch mail on your behalf via its website is disappearing. Existing users can continue using POP fetching only until January 2027. This shift removes a long-standing feature that allowed users to consolidate various email inboxes into one Gmail view without configuring external clients.

In response to this deprecation, plMail has emerged as a free, open-source alternative. It functions strictly as a mail client rather than a mail server, meaning it does not handle email delivery or replace your current provider. Instead, it connects to existing IMAP accounts, including Gmail and Outlook, and synchronizes messages into a local PostgreSQL database. This approach allows users to maintain their current email infrastructure while gaining a unified, self-hosted interface for reading and managing messages across different accounts.

Key details

• plMail is a web-based mail client, not a mail server, so it relies on existing providers for email delivery.
• The software synchronizes messages from IMAP, Gmail, and Outlook accounts into a local PostgreSQL database.
• Installation is supported via Docker Compose for AMD64 and ARM64 systems, as well as a TrueNAS application.
• Gmail and Outlook integrations require OAuth configuration, which is more complex than standard IMAP setup.
• Optional local AI features for summarization and drafting are available via Ollama but are disabled by default.
• Backups must include both the PostgreSQL database and the var/secrets/generated.env file to retain access to credentials.

Background

To understand the value of plMail, it helps to distinguish between mail servers and mail clients. A mail server, such as Postfix or Exchange, is responsible for receiving, storing, and delivering email messages. A mail client, like Outlook or Thunderbird, is software that retrieves those messages from the server and presents them to the user. Most self-hosted email solutions require managing both, which involves significant technical overhead regarding security, spam filtering, and deliverability.

plMail bypasses the server management burden by acting solely as a client. It pulls data from existing servers via IMAP (Internet Message Access Protocol) or OAuth APIs. By storing a synchronized copy of emails in a local database, it enables fast search and unified views across multiple accounts. This model is similar to how desktop clients work but runs in a browser, making it accessible from any device without reconfiguring individual accounts on each machine.

Why it matters

For teams and individuals who rely on Gmail’s aggregation features, the upcoming retirement of POP fetching creates a fragmentation risk. Without a centralized view, users may need to check multiple inboxes separately, reducing efficiency and increasing the chance of missed communications. plMail offers a way to retain a unified inbox experience without migrating away from established providers like Google or Microsoft. This is particularly relevant for small businesses that use domain email alongside personal accounts but do not want to manage complex mail server infrastructure.

However, self-hosting introduces new responsibilities. Because plMail stores a copy of your emails locally, you become responsible for the security and integrity of that data. The project is currently maintained by a single developer, which means security patches and feature updates may not arrive as quickly as they would from a large commercial vendor. Additionally, the need to back up both the database and encryption secrets adds operational complexity. If these files are not backed up together, you may lose access to your archived messages even if the database remains intact.

What you can do

• Test plMail with a secondary or non-critical email account before deploying it for primary communications.
• Ensure you have a robust backup strategy that includes both the PostgreSQL database and the var/secrets/generated.env file.
• Configure HTTPS with a trusted certificate to secure access to the web interface, especially if accessing it remotely.
• Enable two-factor authentication for the administrator account to protect against unauthorized access.
• Consider running optional AI features locally via Ollama if you need summarization tools, avoiding sending sensitive data to external services.
• Monitor the project’s development status and security policy, keeping in mind it is an early-stage project with a single maintainer.