[wp-trac] [WordPress Trac] #5007: Email notifications fail on hosted sites that check sender address

[WordPress Trac]

#5007: Email notifications fail on hosted sites that check sender address
--------------------------+------------------------
 Reporter:  jlwarlow      |       Owner:  pishmishy
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  2.9
Component:  Mail          |     Version:  2.8.4
 Severity:  normal        |  Resolution:  fixed
 Keywords:  needs-patch   |     Focuses:
--------------------------+------------------------

Comment (by GwynethLlewelyn):

 Let me add my voice to those who are opposed to closing this ticket.

 First, I fully understand why a 14-year-old ticket was closed. All teams
 using some sort of time-tracking software are under constant pressure from
 their supervisors to close as many tickets as possible. Your quarterly
 evaluation might be tied to the number of tickets being closed. I have
 never worked at Automattic, but I can fully understand if this is the
 case. An open ticket means a lazy developer. A closed one is work being
 done. I know the drill.

 That said, it is good business practice to actually provide a concise and
 reasonable explanation about ''why'' the ticket was closed. "I closing
 this as fixed.
 Please open a new ticket for any outstanding issue that you see." is
 ''not'' a valid reason.

 The issue is not ''fixed''. It's ''documented'' as not working, with a
 link to this ticket. Sure, writing good documentation ''is'' hard work,
 and my thanks for that, but the ''original'' message was about broken
 functionality, not about bad documentation.

 Let me reinforce that again:

 **The original issue is ''not'' fixed**. It wasn't fixed 12 years ago, and
 ''it is still broken'' **today**.

 The argument that this issue only affected 'edge cases' 14 years ago (such
 as Fasthosts) is a ''fallacy''. In fact, Fasthosts was just enforcing a
 very good practice, namely, checking for fake email addresses created from
 within a mail server. Indeed, these days, spammers don't just send out
 emails with fake addresses — these will very easily be discarded by anti-
 spam mechanisms. Rather, spammers prefer to infect systems (such as
 WordPress — or, more likely, one of the popular plugins), take advantage
 of the lack of ''strict'' checking ''inside'' the server, and just spam
 others with what is perceived as a legitimate address coming from a
 legitimate server.

 That was 14 years ago, when people were much more worried about
 ''in''coming spam than ''out''going spam. There was a certain neglect in
 that area. Not so any more. These days — in 2021, at the date of writing —
 sending email from server to server, in a desperate attempt to curb
 spam/scams/malware, has become increasingly more sophisticated, with
 several layers of digitally encrypted signatures, and a plethora of
 authetication mechanisms (using DNS, for instance), in the attempt of
 making the lives of spammers more and more difficult.

 It's not just Fasthosts that bothers with these things. **Every email
 provider, in 2021, is required to do extra-strict checking on all inbound
 and outbound emails.** Failing to do so results almost immediately into
 being placed into a blacklist.

 Also, these days, 'being on a blacklist' is not just about spam. Malicious
 hacker activity is routinely monitored by many automated systems, and
 recurring culprits are flagged on global databases. Because one of the
 reasons for hacking a system is getting the ability to send spam out of a
 legitimate server, databases of hacking origin servers are mixed with
 those of spammers; in other words, attempt to hack another system, and
 your own server will not only be blocked for intrusion attacks but it will
 be blocked as a source of email, too. ''The reverse is also true'': send
 some spam — even involuntarily (because you've been a victim of a hacking
 attack) — and ''your IP address gets blocked''. Worldwide. In minutes, if
 not in seconds.

 That means no more WordPress.

 While 14 years ago such a scenario would probably be restricted to a few
 security-conscious hosting providers, today it's the norm, not the
 exception — at least on the major hosting providers: those that host
 ''millions'' of WordPress websites. And these large, popular providers are
 even more vulnerable to this issue — that's because, these days, most
 blacklists do not restrict themselves to a ''single'' IP address. They
 collect data and do statistical analysis — if a significant number of IP
 addresses, all belonging to the same provider, are sending emails that get
 labelled as not legitimate (worse: all of them coming from the same fake
 mailbox, `wordpress at ...`, it's highly probable that ''all'' IP addresses
 in that block will ''also'' be blacklisted, or, at least, that email
 coming from those addresses get tagged as coming from a 'suspicious'
 provider. Get several providers exhibiting the same behaviour, and you
 start to see country-wide blacklisting. Again, this is not just about
 email. These days, an organisation may start just having their email being
 blacklisted, but eventually, their whole IP block may get cut at the
 source — packets getting dropped by routers world-wide. Or at least these
 packets will get a lower quality of service; this is left to the
 discretion of those who manage the backbones of the Internet. But they're
 becoming more aggressive and restrictive.

 In fact, even organisations with impeccable track record get blocked
 occasionally. Google, for instance, has one of the best anti-spam/anti-
 scam/anti-malware solutions implemented on Gmail. Nevertheless, every
 other month or so, some of their outbound email relayers get blacklisted
 (at least temporarily — say for 48 hours, or a whole week). I'm just aware
 of that because users of my own server, having local mailboxes hosted
 there, start complaining that 'they cannot get any email from Gmail'.
 Obviously, they complain to ''me''. But even if they complained to Google
 instead and were taken seriously (which is not a realistic scenario),
 there is next to nothing that Google can do about that. ''If'' one of
 their outbound servers has been blacklisted, it means that spammers have
 found a way to send at least a few spam emails out. Often they do that by
 creating a multitude of accounts with randomly generated usernames, then
 send email out of ''all'' of them simultaneously — staying just one step
 ahead of Google's automated account cancelling software — many of which,
 since they coming from a highly reputable organisation, will go through
 and eventually reach their victims. Not, however, without ringing a few
 alarms all the way. Google's own servers might just get preventively
 banned for a while, giving Google a few days to handle the issue on one
 particular server caught at sending out spam. Eventually, service will be
 restored...

 My point is that not even all-powerful Google is immune to being
 blacklisted. They ''do'' send spam occasionally — which come from 'fake'
 accounts. Google is powerless to prevent the blacklisting services to list
 them as spammers; all they can do is, like everybody else, request removal
 from a specific blacklist (which is usually granted but can take
 hours/days...)

 Also, knowing that all WordPress installations will generate a
 `wordpress at ...` address, which the server's sysadmin has to make sure that
 it gets accepted as legitimate (even if it isn't being read/monitored by
 any human), spammers will know, after hacking into a WordPress website,
 that at least ''one'' address coming from that site will be legitimate.
 Granted, the lack of this knowledge hasn't stopped spammers in the past
 (or the present). But it's definitely something to be taken into account —
 especially because it's an open invitation available on ''all'' WordPress
 sites since the dawn of history. Obviously, hackers might simply get email
 addresses directly from the user table; but such emails may not be local.
 A good fall-back option for the hackers, therefore, is just to try sending
 emails out of `wordpress at local.server.name.domain.tld` — it's likely that
 these emails will at least go through the local MTA's anti-spam measures.

 Anyway... this message is already way too long; my point is that there is
 ''still'' a lot to be discussed on this particular issue and that it is by
 no means 'resolved' or 'fixed'. Worse, due to the extra layers of security
 imposed by today's email servers, the situation has become potentially
 much more problematic than it was in 2007.

 Paraphrasing myself from a discussion tread on the WordPress support
 forums, I still maintain that using the Administrator Email instead of a
 'fake' address is a much better choice because:

 1. Usually, the admin email gets verified before being used, so it’s more
 likely to be a valid email;
 2. Admins get periodically notified by WordPress itself, when logging in,
 to re-check if the email address for the site administration is still
 valid;
 3. It’s far more likely for a site admin to check their own email address
 periodically rather than a ‘fake’ address ‘invented’ by WordPress (which,
 if it exists at all, may be routed to nowhere);
 4. It’s also reasonable to expect that the site admin’s own email address
 is less likely to be filtered out by their own mail servers’ anti-spam
 /anti-scam/anti-malware tools than a ‘fake’ address which is neither
 registered nor whitelisted anywhere (unless, of course, one is aware of
 the need of doing so ''a priori'').

 That said, the best solution, of course, is to refrain from creating
 'fake' email addresses. At the very least, I would expect that such a
 critical option/decision was under user control — an option somewhere on
 the settings panel or at least on `wp-config.php`. The ''default''
 behaviour, however, ought to be to use the admin email for ''all''
 communications and notifications, giving users the option to select a
 different email if desired.

 Fortunately, there is currently a workaround that can limit the damage:
 the notifications email address (and user name) ''can'' be filtered out.
 The simplest way of doing so is to add a few lines to the theme's
 `functions.php`, but an alternative is to add it as a plugin (so that it
 carries on between theme changes), or, even better, as a Must-Use plugin,
 installed by the sysadmins by default on ''all'' WordPress sites. On
 large-scale hosting providers this can be easily achieved by the already-
 existing automated tools; all that is required is to make these
 organisations (and their sysadmins) ''aware'' of the issue.

 It's a suboptimal solution, but at least it works today. Nevertheless,
 there is still a pressing need for a ''permanent'' fix: it's counter-
 intuitive to have to ''add'' additional functionality (a theme, plugin...)
 to ''remove'' what could otherwise be described as a security flaw (at the
 very least, 'a bug' or 'an issue') just because ''some'' people do not see
 it as such. Instead, everything should work the other way round: using the
 admin email ought to be the default, and any other exception to the rule
 should be made optional (possibly even delegating it to a plugin, if the
 user so desires).

 Please stick to the
 [https://en.wikipedia.org/wiki/Principle_of_least_astonishment Principle
 of Least Surprise].

 A concerned system administrator (who also does a bit of WordPress
 administration)

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