use CloudAccess.net for disposable sites.
Wait, wait longer....

Hmm that would mean the joomla site is called with its IP and not its domain name when the mails is triggered right?

We have to guess/assume that yes.

But the url (with an IP in it) that is used can be directed at another virtual host on the server (I guess, no time to test today) using the host header.

The code in joomla is

$baseURL  = JUri::base();
		$baseURL  = rtrim($baseURL, '/');
		$baseURL .= (substr($baseURL, -13) !== 'administrator') ? '/administrator/' : '/';
		$baseURL .= 'index.php?option=com_joomlaupdate';
		$uri      = new JUri($baseURL);

	$substitutions = array(
			'[NEWVERSION]'  => $newVersion,
			'[CURVERSION]'  => $currentVersion,
			'[SITENAME]'    => $sitename,
			'[URL]'         => JUri::base(),
			'[LINK]'        => $uri->toString(),
			'[RELEASENEWS]' => 'https://www.joomla.org/announcements/release-news/',
			'\\n'           => "\n",
		);

If you go to https://[2607:1b00:93b2:e42c::1f87]:443/ you get a SSL Error... so obviously if something DID go to that url to generate this email - it was not human, or if it was, it was ignoring all SSL Errors too...

Lets check with CloudAccess, I have just posted that to our Launch Contact with them. So I think they might can help us to reproduce and understand the issue.

Any update @zero-24

Thanks for the reminder I have not got any reply from CloudAccess will try to check with them again

Sorry for delay, We are discussing the case with Joomla devs.

@PhilETaylor the IPv6 address you're seeing there is not incorrect - that's the address allocated to your site.

We're still discussing with @zero-24 on what the solution should be here.

It's incorrect in so much as "a regular Joomla admin" would be expecting their domain name and not an IP address.

The fact that Joomla is capable of emailing based on an IP address is incorrect.

One IP address could host (and does host in the real world) multiple websites.

The fact that you are, If you are, "allocating" a single IPv6 Address to a single web site is irrelevant here...

The fact that CloudAccess are being involved with this is irrelevant to the underlying problem and just a waste of your time.

Other users have reported the same bug with non CloudAccess sites. This is not a CloudAccess problem.

Hmm I was under the impression that the host header should not be a IP in the firstplace but I have been proven wrong: https://stackoverflow.com/questions/50321842/http-is-an-ip-address-allowed-in-the-host-header-field

I have contacted CloudAccess in order to understand and how to reproduce the issue (as mentiond above). So it looks like we have to introduce a trusted_domains setting similiar to what NextCloud does:
https://help.nextcloud.com/t/howto-add-a-new-trusted-domain/26

https://github.com/nextcloud/server/blob/905e1918d2796b9a79025283cd6edf2c40f49d77/lib/private/Security/TrustedDomainHelper.php#L74-L108

I think you would come up against stiff opposition from many attempting to introduce an array of allowed domains from which a Joomla set of file can be accessed by over http through a webserver...

A correctly configured webserver would not allow a site to be loaded on an IP address (or the domain of another site, as others report). Its 2021 and most web servers are name based virtual hosts.

This is 100% a webserver issue I now believe - especially if Cloud Access is assigning a single IPv6 to a single site #fail. That would explain my own emails.

@PhilETaylor the purpose of IPv6, among others ofc, is to assign an address to an entity. We would be happy to do the same with IPv4 but that is not possible for the obvious reasons.

Joomla used to implement live_site config variable that was specifying the domain the Joomla runs on. Since the Joomla is domain agnostic it's not easy to determine the domain name of your site.

Also you said that hosting platform is irrelevant to the issue and then you're contradicting yourself by saying this is 100% web server issue. The fact we are assigning individual IPv6 addresses is not a failure but it's an advantage.

As per your earlier statement the underlaying problem is in Joomla and the way it's using the Host header.

Joomla used to implement live_site config variable that was specifying the domain the Joomla runs on.

Factually incorrect. Live Site has always been a hack to overcome some SEF and proxy issues. It has never been fully implemented (as evidenced by the fact that you cannot set it using the Joomla! Global configuration interface) and is not globally used. It's a throw back to real early mambo days.

Correctly configured Web servers should not show a website when browsing with an IP address in the browser window - even if that website has a one to one relationship with that IP address. your platform has decided to provide a single IP address for a single domain, and you have chosen to route traffic that is being sent to a IP address in the browser, to the virtual host of a domain name. This is an incorrectly configured server for mass market web hosting.

What I said previously still stands that Joomla! can do better and handle when servers are incorrectly configured.

I reopen this, actually this can only be fixed when joomla has the live_site config or the webserver doesn't show the site it self when only a IP is given.

This problem will actually be covered with the multisite project, since then you can bind a domain to a IP.

@HLeithner I think the setting mentioned here joomla/joomla-websites#1841 (comment) doesn't exists anymore.

For the purpose of this notification there should be some kind of 'default URL' defined. Currently when the notification is triggered the subject line can be populated with something like:

http://clouddevbox.net/ or
http://clouddevbox.net/administrator/ or
http://www,clouddevbox.net/ or
http://www.clouddevbox.net/administrator/ or
https://clouddevbox.net/ or
https://www.clouddevbox.net/ or
[...]
http://[2607:1b00:93b2:e42c::bbcf]/ and
https://[2607:1b00:93b2:e42c::bbcf]/

This means the "site URL" is determined by protocol, Host header and the URL path. Two of those are client controlled values.

If I would allocate dedicated IPv4 address to this site it would be also triggering that notification. The same goes for each alias name. So this could be quite confusing.

The default URL should be used for the notifications only to resolve the confusion about the origin of those messages. Making whole Joomla domain dependent is really bad idea.

btw
Possible additional use of default URL can be in <link> tag with rel="canonical" attribute. Currently this attribute can't be used because the changing href.

@Pawel-Panek the live_site parameter have to be set in the configuration.php manually, it's used to have a canonical url for the joomla installation. The value is the front end, ex. https://clouddevbox.net/. this parameter is used to find the Joomla base url in Uri::base();.

Setting this parameter is also needed for cli scripts which doesn't have a "host header" set manually.

Thanks for the explanation. Indeed it's there, in the default config. I'll give it a try and check if that affects the notifications.

It looks like live_site worked good. The notifications are now generated only with live_site URL. No matter what request triggered it.

The <base> tag is generated as before, eg <base href="http://www.clouddevbox.net/" /> when the site is visited with http://www.clouddevbox.net/ so that's good.

We will include this setting in our processes and this will resolve the original issue.

thanks for the confirmation @Pawel-Panek can you comment in joomla/joomla-websites#1841 when it's done? only that we know that this should be fix for joomla.com

I consider this rather a matter of wrong configuration and thus don't see any need for action on our part. Cloudaccess has fixed their setup of the site, so this should be good now. Closing this issue.