Post History

I think to some extent, you actually answered your own question, possibly without realizing it.

[A URL is a specialization of a URI.](https://www.rfc-editor.org/rfc/rfc3986#section-1.1.3) (Or more technically accurate, a URI is a generalization of a URL.) URIs are required to specify a scheme (`https`, `mailto`, `gopher`, `tel`, ...) but they aren't necessarily required to [separate the two using `://`](https://www.rfc-editor.org/rfc/rfc3986#section-3); many URI schemes use a simple `:`.

However, a URI will always separate the scheme and the remainder by *either* `:` *or* `://`.

A `https` scheme URI (which is one type of "URL", if by URL we mean a string which specifies the location of a web resource) will always use `://` to separate the scheme from the rest of the URL. (In a web context it's also valid to omit the scheme *and* the `:`, such as in `//example.com/page.html`, which is a *protocol-relative* URL instructing the client to access the named resource through the same scheme as that which was used to access the page on which the reference exists.)

However, *people are imperfect* and make mistakes. Since browsers try to be user-friendly, they will often provide various forms of autocompletion or correction of URL syntax where the intention of the user can reasonably be determined even though the exact syntax is incorrect. (An early form of this likely was not requiring the user to type `http://` all the time. A later form was adding prefixes and suffixes such as `www.` and `.com` to non-fully-qualified host names, so that if you typed `codidact` into the address field the browser would take you to `http://www.codidact.com/`.)

**Substituting `://` for `:/` immediately following a recognized scheme** seems a low-impact such fix to make, and is almost certainly what you saw the effect of.

So whoever is behind the email likely took advantage of that *something* won't recognize such a string as a valid URL and therefore not subject it to in-depth scrutiny, *whereas* the email client will likely see the `https` scheme and pass it to whatever program is configured for handling `https` scheme URIs, likely a web browser, and the browser in turn will happily correct the syntax such that the effect is the same as if it had contained `://` instead of `:/`.

In other words: in this particular case, there is *likely* no particular shenanigans involved; just someone taking advantage of different software handling slightly invalid input differently.

**Which is not to say that there aren't Unicode domain name shenanigans out there**, such as for example using `∕` (U+2215) instead of `/` (U+002F) to give the appearance of the domain name being different from what it technically is. But if your example is representative, that does not appear to be what's going on here.