XPost: microsoft.public.outlook.outlook, microsoft.public.outlook.usage
Ant <
ant@zimage.comANT> wrote:
Ant <ant@zimage.comant> wrote:
This is in https://www.usc.edu/office365 and Google's Chrome web browser
in macOS Big Sur v11.7.10. All have updates.
I figured it out! Google Chrome was blocking up pop-ups by defaults. I whitelisted it and it worked. Why does MS have to use pop-up method?!
Depends on how you define a pop-up window. Could be a tab (that's a
document window, too). In Chrome, does clicking on a hyperlink result
in opening a new window, a new tab, or a new Chrome instance? Chrome's
setting blocks popups AND redirects. A hyperlink can be a a redirect,
like the URL points to a server that then redirects you to the target
site.
https://www.semrush.com/blog/redirects/
Does the hyperlink actually point to the target site? Or does it point
to a Microsoft/Outlook server which then redirects you to the target
site? Microsoft hand-holds their users by adding protection to
hyperlinks. Instead of the URL pointing directly to the target, it
points to a MS server that check if the destination is safe. If so, you
get redirected to the target site. If not, you get blocked from what is supposedly a malicious site.
I report spam, and Microsoft's Safe Links redirection results in parsers picking the wrong host as the spam source. You have to unmunge their hyperlinks (and headers) to have the message source to the actual source
host to then report spam against that source. Below is my canned
response to Microsoft's use of Spam Links protection. It's long.
Oh, if you have a paid account, or get one through your employer or
school, with Hotmail/Outlook.com, you get an option to disable
Microsoft's protection. Else, like the rest of us freeloaders, there is
no option. You have to use their feedback form to have them contact you whereupon you can then orally request they remove their protection from
your account. Wait a month, and check if hyperlinks are getting
"protected", then report again. Took me twice to get it removed, showed
up a year later, had to get it removed again.
-----
Safe Links, where Microsoft rewrites URLs in emails to redirect them to Microsoft's servers for analysis, tracking, and passing forward the
connection request, is part of Microsoft Advanced Threat Protection
service. It's Big Brother getting in the way ... again. No, it is not
just used at companies employing their own Exchange server and getting
charged $2/seat for the "privilege" of having Microsoft track links
visited in their e-mails. Everyone using the free Microsoft e-mail
services (hotmail.com, live.com, outlook.com) is an involuntary lab rat
getting experimented on by Microsoft. There is no opt-out option of
this added "security" that has some nasty security and stability
ramifications.
Not everyone relies on server-side spam filtering by Microsoft or
whomever is their e-mail provider. Some users are actively involved in reporting spam to DNSBLs (DNS blocklists), like SpamCop and others.
However, when submitting a spam exhibit to those DNSBLs, Microsoft has
altered the e-mail to change the hyperlinks to point at
https://<varHost>.safelinks.protection.outlook.com/?url=<target>.
That's because Microsoft is corrupting e-mail content. The DNSBL might
know that it should deobfuscate the hyperlink to remove the outlook.com
portion and interpret the entity-encoded argument pointing at the actual
target URL. Or they may not and outlook.com gets flagged as the spam
source. Some DNSBLs may simply take the approach that if outlook.com is
in the hyperlink that they will skip parsing and analyzing that URL
because, gee, Microsoft is protecting the user; however, that means the
actual target does not get reported in the DNSBL to help protect other
e-mail users that are not so [un]fortunate as to be using Exchange as
their mail server with whomever is their e-mail provider.
Users of standalone clients (not in corporate environments) should have
control over how much security is applied to their e-mail. Users of hotmail.com, live.com, and outlook.com should not be afflicted with
"security" that they do not want. I have researched online to find
there are vulnerabilities to Safe Links and it has become trivial to
circumvent that protection layer. Besides using a redirection service,
an easy exploit to circumvent Safe Links is to encode the URL using
Punycode. Another is to fool the Safe Links regex parser by inserting
an attribute that contains the greater-than character, like <a x=">" href="targetURL">comment</a>. The parser stops at the first ">" so the
tag becomes <a x=>; however, the e-mail client won't have a problem
deciphering the A tag which still has the original URL. HTML-formatted
e-mails can contain forms, so the targetURL could be coded as <form action="targetURL">args</form>. Safe Links only parses on the href
values in A tags (and tries to find URL strings in text-only e-mails).
A URL could get split up across cells in a row of a table. While not clickable, the user can still copy the string as presented (a
concatenated string of cells) to input into a web browser or, in some
clients, highlight and right-click to go there.
Microsoft prepends a hostname for their Safe Links server, like
https://<varHost>.safelinks.protection.outlook.com/. That means a DNS
lookup is required before the user gets to the target. Oh yes, no one
has ever heard of DNS poisoning, especially on well-known and highly
desirable targets like for Safe Links. They probably figured users
would be more alert to Microsoft's intrusion if IP addresses were used.
They cajole users into accepting the redirection because, gee,
https://nam04.safelinks.protection.outlook.com/<args> has outlook.com in
it whereas
https://104.47.46.28/<args> would look suspicious.
There is a privacy issue involved: clicking on a hyperlink in an e-mail
has the string passed to Microsoft who has already stated they are
tracking the URLs. For some users, privacy (from Microsoft) is more
important than safety of hyperlinks, especially for educated users that
know how to read HTML to see to where a hyperlink really points. I do
NOT want Microsoft to be analyzing or ever touching anything that I am
doing on *my* computer as to where I choose to visit. It's none of
their business! When I click on a hyperlink, whether it be in e-mail, a
web browser, or other web-centric client, I do NOT want it tracked by
whomever authored the client or server program. I don't want Microsoft tracking my visited URLs in Edge, or Mozilla tracking my visited URLs in Firefox, and so on, and I don't want Microsoft logging my visited URLs
in their Safe Links server.
Inserting another node in the route between me and the target incurs
further delay. Anyone that uses a VPN understands the added delay.
Anything that adds links into the chain makes the chain more fragile.
The scheme assumes the safe links server never goes down and malicious
links never get passed. Except the server has gone down and malicious
links have gotten through. Users are getting impacted by a security
feature foisted upon them without their knowledge (most users know
nothing about the Safe Links feature) and without their permission (to
allow Microsoft to alter the contents of their received e-mails).
It already takes sometimes an inordinately long time to get e-mails
received (by the client) when using Hotmail or Outlook.com sent from
some domains. Seems the rivalry between Microsoft and Google is still
waging so e-mails sent from Gmail to Hotmail take longer then when
sending to Hotmail from any other source. Now users get stuck with Safe
Links that further delays use of their e-mails. Seems a DDOS attack
could simply have scripts from multiple sources attempt to connect to
millions of URLs that begin with
https://<varHost>.safelinks.protection.outlook.com/?url=<targetURL>.
With their server occupied with lots of URLs to parse and analyze, good
users will get further slowed on getting their links processed.
From my reading, ATP does not replace links in digitally signed e-mails.
Excuse me, but few users know how to get an e-mail cert, install it in
their client, and then know how to use it (it is an invite scheme: the
one with the cert sends a digitally signed e-mail that the recipient can
use thereafter its public key to encrypt their e-mails sent back to the
one who invited). Any change to the body of the e-mail means
invalidating the digital signature and the e-mail is considered
corrupted. So the simple workaround by spammers is to digitally sign
their e-mails. Since there remains the availability of getting free
e-mail certs, it won't take long for spammers to figure out how to
circumvent Safe Links. Microsoft comes up with a short-lived security
feature that interferes with e-mail and creates a privacy issue with all
links passing through their server. In effect, Microsoft has instituted
an anti-privacy feature to produce an interferring security feature of
dubious value.
In fact, spammers already figured out how to get around Spam Links.
Instead of their URLs pointing directly to their spam or malicious site,
their links point to a benign page (not listed in Microsoft's 'bad'
list). The site then merely uses redirection to push the user at the
spam or malicious site. If Microsoft ever adds the redirection site to
their 'bad' list (which can be tested so spammers can detect), the
spammers will simply move to another redirection domain. Also,
Microsoft published the IP addresses for their Safe Links servers at
https://technet.microsoft.com/en-us/library/dn163583(v=exchg.150).aspx (Microsoft has since removed or moved this list). The spammer's
redirection pages can see if the connection is coming from there to
decide how to handle the redirection.
Spammers don't even have to use their own host to provide redirection
pages to obviate Safe Links. They can use Google's redirection.
Google.com is whitelisted by Microsoft, so a link like
https://www.google.com/url?q=<targetURL> will not get altered by the
Safe Link feature. So redirection can be used to thwart Microsoft's redirection. Plus there are lots of redirection services: TinyURL,
Goo.gl, bit.ly, and many more. Is Microsoft going to blacklist the
entire domain of those redirection services to prevent them from
redirecting to spam or malicious sites? Safe Links doesn't navigate and
then inspect the target page so redirection is an easy means of
bypassing Safe Links. Spammers have been using redirection services
since they showed up. It is up to the users to determine the target is
spam or malicious and then report it to the redirection service to get
that redirection deleted from that service ... but the spammer is moving
on and creating more redirection links in that service.
Safe Links is about redirecting hyperlinks through their server and then
onto the target, if allowed. What if Microsoft is wrong about the classification of the target? Oh yes, false positives never happen, uh
huh. A valid site gets tarnished because of Microsoft's error.
What about link rot? Many users, especially business users, keep
archives of e-mails for decades. Microsoft is modifying the URLs in the e-mails. What if Microsoft changes or drops their Safe Links service.
All those redirection links to the Safe Links servers become invalid as
they will point to a destination that no longer exists. If Microsoft
decides to drop the service, are they really going to provide a tool to
dig into every online account, PST/OST file, and anywhere else to
deobfuscate all their redirection links? Don't count on it. No
software, feature, or service has ever been perpetual. Microsoft has
proven over and over that they tire of a protocol and will switch to
something completely incompatible. Safe Links will go away meaning
everyone's store of e-mail becomes corrupted with unusable hyperlinks. Microsoft is destroying the fidelity of our e-mail archives.
Not all e-mail users are boobs. Some are well educated in deciphering
HTML and how to parse URLs. Safe Links just makes it more difficult to
parse out its crap to determine to where a hyperlink actually points.
Users that configure their e-mail clients to show all e-mails as plain
text (non-HTML) will get nuisanced with even longer URL strings because
of Microsoft prepending their redirection domain onto all URLs. For
URLs that would easily identify the target, like someone's web site in
the signature, the URLs now become more difficult to parse and not
immediately recognizable, especially due to entity encoding for the
target URL in the argument of the redirection URL.
I am a user of hotmail.com (aka outlook.com), not inside a company whose policies dictate what they can do with company-related or any other
e-mail that goes through their servers. Microsoft provides no
server-side config option in a Microsoft account to disable their
corruptive, intrusive, flawed, and spying Safe Links feature. I never
gave them permission to MODIFY my e-mails. I never gave them permission
to redirect the hyperlinks to get processed and tracked through their
Safe Links server. I don't want a covert proxy handling my e-mail
hyperlinks. Microsoft is being rude by shoving down our collective
throats a flawed security scheme at the expense of user convenience
while destroying e-mail fidelity. Corporations have to pay to get ATP (Advanced Thread Protection, $2/seat), so they get to choose whether or
not to participate in Microsoft's experiment. Freeloading users of hotmail.com, live.com, and outlook.com don't get a choice. They are the involuntary guinea pigs in Microsoft's experiment. Users with work or
school accounts (using Microsoft's public Exchange server, not for their company's Exchange server), or those subscribed to Office 365 (renamed Microsoft 365) can go to
https://protection.office.com to login and
disable ATP. Everyone else is stuck with Microsoft forcing ATP upon
them. According to Microsoft's instructions, your MS account must have
the following settings navpath: Settings -> Premium -> Security.
Freeloaders won't have that.
-----
Isn't it great that Microsoft inspects your food before you can eat it.
When you open a jar, that jar is pushed aside, and you're given a
different jar from which to eat.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)