Default Envelope Return-Path can tarnish IP reputation for mail-sending hosts.

[dmsnell]

[61010] introduced a change which set the Envelope Return-Path for emails, when unset, to a default value which could be a plausible and deliverable address, whereas previously it was set by the running host to an undeliverable address using private details for the username and hostname.

While this has improved the deliverability of messages sent from WordPress by providing DMARC and SPF alignment, an issue was raised from the host perspective.

Some hosts appear to be applying global policies on their email servers which allows deliverability at the otherwise undeliverable mailboxes, making it possible to send bounce emails and thus helping to maintain IP reputation.

It appears that much of the confusion appears because of the integration of many different systems which have all evolved in complicated ways over time, but there might be ways to adjust which move the WordPress ecosystem forward while helping hosts avoid misconfiguration issues on individual sites from reflecting on their servers.

This ticket branches from #64368 where a specific interaction bug between the sendmail configuration and the email changes caused unexpected crashing.

Goals

• WordPress should send valid emails with proper Envelope Return-Paths.
• Misconfiguration relating to non-deliverability should be easier to identify and resolve for site owners.

[SirLouen]

Let's talk about 6.9 pre-era and post-era to illustrate the whole point.

In the 6.9 pre-era, what we encountered was mostly, hostings taking care of all-things-mailing, and some users just skipping all through it, with 3rd-party plugins.

To some extent this is what WP pretended the wp_mail to be. But personally, from the first day I used WP, I thought it was weird that something so important like “mail communications” was so weak by default and immediately required of 3rd parties to make it happen (or a lot of tweaking and even knowledge about PHPMailer).

But one of the most important aspects in the 6.9 pre-era we found, was a MAIL FROM not aligning with the From address.

Lets imagine the following example:

I'm a good WP user, with basic knowledge about mailing and deliverability. I've been taught that SPF/DKIM/DMARC are influential things, and I want all 3 of them to pass easily, without much fuzz.

We all know it's true that WordPress is not helping anyone to set a From: address. And this is a pain point, but at least, it's clearly documented a wp_mail_from hook to set such. I, as a good WP user, don't really want to deal with PHPMailer at all, and in fact, as a regular user, I should not even know that PHPMailer even exists (in fact, today could be PHPMailer and tomorrow could be symfony/mailer). So basically, knowing that I need to set this hook, to set my From: address I proceed accordingly, setting the From:for example to hello@example.com, an email I own and I can receive emails within my webhost mail client.

Then, following my web host's mail configuration guideline, I set up the SPF record with the mail relay address, my DKIM with the RSA that the webhosting provides, and finally the DMARC with the corresponding receiver policy.

And finally, I start sending emails with my WP site to find, that SPF is miserably softfailing, because the Sender and the From SPF are not aligned for some reason.

How can we solve this? Originally, the solution was this: Having to hook, to the PHPMailer init hook, learning that PHPMailer exists, and how it works. Definitely obnoxious for an exemplary user.

Here we have, an exemplary user, being hit in the ass by a WordPress decission to remove the recommended setting by PHPMailer of setting the MAIL FROM the same as the selected From.

This is probably why, 99% of these users, obviously installed the WP Mail SMTP or equivalent plugin and forgot about all the obnoxious wp_mail system for obvious reasons. A silent majority that are simply ignoring the wp_mail commands because they are simply overriding it.

But now, in the Post 6.9 era, this is switched around: With all the steps above, the exemplary user has a perfectly set up and working mailing system.

Now lets go back to the Pre-6.9 era with a different type of user.

On the other side we have the not-knowledgeable user that cannot care a bit about learning all this mailing concepts, and just wants a site that simply works and sends emails out of the box. So here is where web hosting system administrators need to take their decisions.

Ensuring deliverability is something a little weird and completely lies on the MDA. There are some gold standards, but there are also some "fuzzy" ideas on what is better or not. WordPress as an agnostic software (and mostly relying on PHPMailer), should only follow those gold standards.

Having this in mind, some were suggesting, they only cared about two things to ensure such deliverability:

• Simple SPF passing (based on Return-Path FQDN)
• Return-Path delivery capacity (ensuring that, in case of mail bounce, email could be delivered to an existing inbox).

How to easily solve this?

1. Setting a default hoster-controlled, return path, for example: defined-alias@hosters-example.org
2. Creating a local inbox for such defined-alias
3. Configuring the hosters-example.org SPF record for their mailing relay.

With this scenario what we have?

✅ Since they control the Sender address (because there is no sender address set by WP by default), the sender is that random email, hence we have capacity to receive emails there
✅ SPF passing because they control both the DNS and the FQDN for the Sender address.
❓ Ignoring DMARC
❓ Most webhosts don't configure by default DKIM and solely rely on the domain registered in the hosting panel. So passing DKIM won't happen by default. Passing DKIM means passing DMARC as long as SPF softfails.

But for many MDA, this is somewhat enought to ensure deliverability (but as we have seen, requirements are being strenghten with the years passing)

But there are a couple of problem. The most important: It's impossible to SPF align From: and MAIL FROM, not even in relaxed mode without altering PHPMailer behaviour as we commented before. These hosts can only rely on softfailing for SPF, seldomly passing DKIM and just having a valid Return-Path.

Post 6.9 the scenario is the following for these hosts:

❌ Since some people are not configuring the DNS for their domains, they must rely on having control of the domain's DNS to help them pass SPF/DKIM otherwise they will have SPF failing, DKIM failing, and DMARC failing
❌ And since the domain SPF for the domain is failing, they won't have alignment.

The wrong part here, is that webhost system administrators should have the tools and the skills to make everything happen.

1. Force their users to set their NS to their DNS so they can have some agency over their records
2. Ensure incoming mails to wordpress@example.org can be catched (or ignore all emails to that inbox)
3. If they cannot enforce their users to set their NS, advice them on setting their DNS if they are willing to have a working mailing system (cPanel has this menu for example)

Yes, its true, that before with a very weak and simple configuration, this poorly configured hosts had a very simplistic delivery system that to some extent ensured some degree of deliverability

But this was in exchange of killing the “exemplary users” and forcing them to "learn" about PHPMailer principles (and the phpmailer_init which should not be recommended the use, unless for special cases, like setting isSMTP).

I can understand the frustration of some web hosts, because now they have to significantly upgrade their systems to ensure the same degree of deliverability. Ensuring this, will differentiate the top web hostings from the very basic ones and will make available the full set of SMTP tools for top quality deliverability (Full SPF Alignment/DKIM/DMARC passing).

Big relays like Mailgun, SendGrid and SES, won't rely on poorly configured DKIM/SPF records.

But from my perspective, WordPress, simply as a software provider (and to some extent, as a "proxy" to PHPMailer capabilities), can only ensure to provide the maximum capabilities at the minimum configuration for the “exemplary user”.

This is my "use-case" when taking decisions on what to introduce and what not.

A bit long discourse, but I think I have not forgotten any of the most relevant elements regarding this topic.

PS: Please keep this close as this discussion should get to an end at some point, and I don't like having tickets in Mail component without a final keyword (just like #60420)

[dmsnell]

Duplicate of #60420.

thanks for the link @SirLouen — I didn’t realize this already had an open issue. I will mark this one as a duplicate.

[dmsnell]

@SirLouen please do not reopen this; it’s a duplicate.

I understand that it can seem overwhelming how much discussion is already in #60420, but I made a mistake in opening this ticket and it’s not better to fragment the conversation between old and new tickets. It’s okay if issues remain challenging and messy until they are resolved.

[SirLouen]

Replying to dmsnell:

I understand that it can seem overwhelming how much discussion is already in #60420, but I made a mistake in opening this ticket and it’s not better to fragment the conversation between old and new tickets. It’s okay if issues remain challenging and messy until they are resolved.

I think there was a little confusion; it's not a duplicate.

#60420 is specifically talking about the need to add a new input field in the admin to set the From address, because they don't like the fact of using the wp_mail_from hook

This ticket was coming from the specific idea in #64368 that WP having explicitly set a Sender/MAIL FROM address is forcing some sysadmins to manage those unhandled inboxes.

As you can see, they are entirely different. In this comment I said that I preferred to keep this ticket as close status (like the other one), because knowing that I've been dealing for months with this kind of never-ending discussions, and for me, as the current maintainer, having a final keyword, helps me triage/clean up during my scrubs once the conversations have completely decayed/staled after some weeks/months.

So ideally I would leave this open to keep things in a better place (as I have some plans for #60420, but I have no plans for this one, and I truly think that should be completely shut down at some point).