[wp-trac] [WordPress Trac] #60420: Default wordpress at site.com sender address can be problematic

[WordPress Trac]

#60420: Default wordpress at site.com sender address can be problematic
-----------------------------+------------------------------
 Reporter:  thinlinecz       |       Owner:  (none)
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Mail             |     Version:  1.5.1.2
 Severity:  normal           |  Resolution:
 Keywords:  close            |     Focuses:
-----------------------------+------------------------------

Comment (by michael.orlitzky):

 Replying to [comment:25 knutsp]:
 > Replying to [comment:7 SirLouen]:
 >
 > No need to save anything, other than caching it. I mean a Test (those
 automatically performed when visiting Site Health). As we know, that page
 performs tests, then displays the results, what they mean, explains what
 the implications are and so on. In case of failure, the user may be
 advised to create a forwarder to null ("blackhole"), to an existing
 address or create a full account.
 >
 > The test may just try to send to the From adress with SMTP (default:
 wordpress@[server.host]), not actually sending any message, using `VRFY`
 or `RCPT TO`. With the latter, the MX will either accept it and invite to
 go on or reject it as non existent. The response code can be turned into a
 boolean (success/unsucessful). Or actually send a test message, but that
 would require a user initiated test, as in the plugin "Site Health Tools".
 >
 > I may be able to make a tiny plugin to demonstrate this concept,
 implemented as a Site Health Test, if this is the way to go.

 Again, apologies for sounding rude, but this is just doomed to fail. The
 theoretical problem is that sending to the `From: ` address is not
 meaningful unless the server it lives on implements the same SPF/DKIM
 checks that other recipients will (sender address verification is almost
 never the problem). The practical issue is that "is this address
 deliverable?" is not a boolean. A lot of things can go sideways:

 1. You're bypassing the MTA's configuration... what if it uses a relay
 host and the web server is blacklisted?
 2. You have to pick a HELO name that both passes SPF and is valid for the
 web server.
 3. What do you do if there's a temporary DNS error?
 4. What do you do if you manage to connect but the connection is dropped?
 5. What do you do if everything goes OK, but at the very end, the server
 sends you a 4xx mailbox full?

 An MTA is equipped to handle all of those scenarios, and the web server's
 MTA is (should be) properly configured. But if all you get is a one-off
 SMTP session where nothing is configurable, you're going to get wrong
 answers and confuse the hell out of people trying to explain to them
 problems that don't exist.

 If site health is the way to go, the best we can hope for is a warning
 that no address was configured and that you have to write a plugin or
 modify your theme to configure one (both of which are insane :P)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60420#comment:28>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform