Why cpan.org email forwarding became impractical

The Perl NOC has announced the shutdown of cpan.org email forwarding today, April 25. Its explanation combines a very high spam proportion with difficulties delivering legitimate forwarded messages under modern authentication requirements. The volunteers also report that attempts to find an external provider failed. Continuing the service at an acceptable quality was no longer feasible.

I have used Perl for nearly thirty years, and I regard CPAN as a substantial part of its usefulness. A stable way to contact a module author fits the same practical model as distributing documented packages. The shutdown is therefore worth understanding as an infrastructure decision. Keeping an address unchanged does not keep the delivery conditions behind that address unchanged.

A forwarding address adds another sender

SPF, specified in RFC 7208, lets a domain authorize sending hosts. A receiving server evaluates the address of the server making the current SMTP connection. Forwarding changes that server. If an intermediary preserves the original envelope sender, the final recipient can see a sending host that the original domain never authorized.

The specification discusses this problem explicitly for mediators. A message can pass a check when it first arrives and fail after another server forwards it. That result does not require the message to have been forged. It follows from applying a host-authorization mechanism at a different point in the delivery path. Reliable forwarding needs to account for that change.

This is why I would resist describing a forwarding service as a trivial alias database. Mapping one address to another explains where the operator wants the message to go. It does not explain how the next receiver will evaluate the message or whether that receiver will accept it. The service has to operate within policies controlled by domains and providers outside its own administration.

DKIM, described in RFC 6376, adds a signature associated with a domain. A verifier retrieves the public key through the signing domain and checks the signed message content. Ordinary relaying can preserve that signature when it preserves the relevant content. Changes to signed content can invalidate it, so the exact behavior of an intermediary matters.

SPF and DKIM consequently answer different questions. One concerns authorization of the sending host for an email identity. The other associates a domain with signed message content. I would inspect their separate results when diagnosing forwarding instead of collapsing them into a single statement that the message passed authentication somewhere earlier.

Authentication also needs to match the visible author

DMARC in RFC 7489 adds identifier alignment around the domain in the visible From field. A valid authentication result for some other domain does not automatically authenticate that visible author identity. The specification defines how an authenticated SPF or DKIM domain can align with it.

This creates another constraint on a forwarder. Making a downstream authentication check succeed under the forwarding service domain is not necessarily enough to establish alignment with the original visible From domain. I would ask which identity passed and how it relates to that header before calling a delivery workaround complete. Otherwise, a fix at one layer can leave the receiving policy unsatisfied.

The NOC announcement names SPF, DKIM, DMARC, and ARC among the requirements that made reliable operation difficult. That is consistent with a service whose responsibilities extend beyond receiving and retransmitting bytes. It needs to preserve enough authenticated information for a recipient to make a useful decision, despite the extra delivery step.

ARC, documented in RFC 8617, lets intermediaries add authenticated assessments to an ordered handling chain. A later receiver can verify those assertions and use them in its decision. The mechanism preserves information about previous handling. It still requires a judgment about whether the intermediaries supplying that information are trustworthy.

I would therefore avoid treating ARC as a guarantee of inbox delivery. Its specification gives receivers evidence they can use. It does not force every receiving provider to trust a particular forwarder or accept every message with a valid chain. An operator still has to understand the policies and observations at the far end of the route.

Spam changes the cost of providing the service

The NOC reports that more than 99 percent of incoming mail was spam. Even with two filtering layers, some unwanted mail passed through and harmed delivery of other outbound messages. The consequence extended beyond the author-forwarding service itself. Maintaining it affected the other mail responsibilities of the volunteers.

That is an operational reason to consider removal, even when the address mapping remains useful to some people. I would evaluate the service by legitimate delivery and its effect on shared infrastructure. Counting configured aliases alone would tell me little about either. A service can have many historical registrations while only a small portion still depend on it.

The announcement also says the operators will work with the security team to retain a way to reach authors. That is a dependency I would keep explicit. Public issue reporting and private security reporting can require different channels. Replacing an obsolete address with a public tracker is useful for ordinary bugs, but a vulnerability reporter may need a private contact route.

I would review published contact details after a change like this, including metadata that readers encounter through package discovery. An address is part of the maintenance interface of a distribution. When it stops receiving mail, leaving it in place makes the documentation promise something the infrastructure no longer supplies. A current route needs to be discoverable where a reader would have found the old one.

For anyone maintaining a package, I would test the replacement route from outside the account that owns it. The test should establish receipt and identify who watches the destination. A successful configuration edit is weaker evidence than an observed delivery, particularly when several systems publish or cache contact information. The useful outcome is that a report reaches a person who can respond to it.