a good alternative to BCC EMAILS

GNU Mailman

In a previous post we explained the pros and cons of using bcc emails,
see: “how to send and limit BCC EMAILS”.

In the conclusions, among the other sentences, we stated:

Use dedicated apps to send mass mailings.
The professional systems have an approval workflow
and step by step control, 
they are designed to avoid mistakes.

Summary of this article:

How it works

Email marketing platforms can be hard to learn and to support (in case you provide them to your customers).

What we are describing here is the idea to use the open source software “GNU Mailman” to send your mass mailings.
The suggestion comes from our own experience offering the easy to use “copymail app”.

A Mailman “one-way” list is a configuration for newsletters or announcements
where only authorized moderators can post, and members cannot reply to the list.

Here’s how it works:

The user sends the message from their email client to the list’s email address.
He must then approve the delivery, which will be distributed server-side to all subscribers.
The system automatically handles bounces (returned emails) and, if desired, unsubscribes.
Subscriptions must be registered manually.
The service is highly reliable, capable of handling thousands of addresses without difficulty.
Sending relies on RealSender’s or other SMTP servers.

GNU Mailman “one-way” list

GNU Mailman is a widely used software that most Internet Service Providers offer.
On the interenet there are a few guides that explain how to configure and use it for mass mailings:

members join by filling in a form on your website (and replying to the confirmation email)
they will be sent a welcome message that does not mention how to post to the list
they will receive your newsletters, with a footer that gives simple instructions for unsubscribing
only authorized persons can post to the list (send the newsletters)

The main reference is this document taken from two posts by Barry Warsaw to the mailman-users list:
How do I create a newsletter/announcement/one-way list?

It esplains in detail the main points:

how to create a customized welcome message and listinfo page that avoids mentioning how to post to the list
how to minimize password issues and unsubscription problems commonly faced on this type of list
how to restrict the list so only authorized persons can post
how to set an announcement list to reply to a contact address
how to post to the announcement list

Another article from Stanford University explains how Mailman
can be used to set up a list to be ‘announcement-only’:
How to set up a ‘one-way’ announcement-only or newsletter list - Knowledge article KB00010792

Some history about GNU Mailman

Mailing lists can be discussion-based or announcement-based. Mailman software is written in Python language, before its release the Python community used Majordomo, a Perl-based mailing list manager.

Today, Mark Sapiro is maintaining the stable 2.1 branch,
while Barry Warsaw, concentrates on the new 3.X version.

Two overriding principles that are critical to Mailman’s ongoing success:

No message should ever be lost
No message should ever be delivered more than once

In Mailman 2 the developers re-designed the message handling system to ensure that these two principles would always be of prime importance. This part of the system has been stable for at least a decade now, and is one of the key reasons that Mailman is as ubiquitous as it is today.

VERP bounce management

VERP stands for Variable Envelope Return Path. It is a well-known technique that mailing lists use to unambiguously determine bouncing recipient addresses. When the mailing list gets the bounce, it can do something useful, such as disable the bouncing address or remove it from the list’s membership.

There is a standard format for the bounces, called delivery status notifications. Mailman uses a library that contains dozens of bounce format heuristics, all of which have been seen in the wild during the 20 years of Mailman’s existence.

VERP exploits a requirement of the fundamental SMTP protocol to provide unambiguous bounce detection, by returning such bounce messages to the envelope sender. This is not the From: field in the message body, but in fact the MAIL FROM value set during the SMTP dialog. This is preserved along the delivery route, and the ultimate receiving mail server is required, by the standards, to send the bounces to this address.

If the Mailman server is mylist@example.org, then the VERP-encoded envelope sender for a mailing list posting sent to anne@example.com will be: mylist-bounce+anne=example.com@example.org. Bounced emails are sent to the VERP-encoded recipient address. Mailman can then parse the To: header to decode the original recipient as anne@example.com

Using VERP requires that Mailman send out exactly one copy of the message per recipient. VERP requires a unique MAIL FROM for each recipient, and the only way to do that is to send a unique copy of the message. This approach also helps prevent the message from being identified as spam.

From and Mail From address alignment

During the trial period, the default “copymail app” configuration uses a domain provided by us as the Mail From address (also known as the bounce/return-path/envelope address), which is the address to which bounced emails are returned. This Mail From domain is different from the From address domain (the sender address visible to recipients).

Before putting it into production, some changes must be made to the DNS to authenticate the messages sent with the From domain. The latest email standards allow you to send authenticated emails using a subdomain as the Mail From address (for example, email.youremaildomain.com) while still being able to use the base domain as the From/Sender address (for example, info@youremaildomain.com). Further details can be found within the email authentication advanced page.

The same situation will occur in other environments. We recommend verifying this with your internet service provider.