Re: Reporting Spam from Microsoft

"David E. Ross" <[email protected]> wrote:

> NO!  This is not spam.  I try to report spam to the spammer's host.
> Spam from Microsoft, however, requires that I know which Microsoft
> service is the origin (e.g., Azure, 360).  Each service has a different
> reporting process.
> 
> How can I tell which Microsoft service is the source of spam?

You might want to become a spam reporter at spamcop.net.  They will
parse the headers to determine to where the spam should get reported.
However, it is still your responsibility to know if they correctly
parsed the Received headers.  Sometimes the chaining of Received headers
gets confusing, because chaining is not shown for internal servers.
Also, spammers may add Received headers to confuse spam reporters or
parsers as to the origin of an e-mail; however, they can only add bogus
Received headers to their message which means those are listed first (at
the bottom of the header section since Received headers are prepended by
each mail server through which a message passes).  You have to ensure
the 'from' clause in a Received header matches up with the 'by' clause
in the prior Received header.

To match up the chaining in the Received headers, I copy the headers
into, say, Notepad, and reverse the order of the 'from' and 'by' clauses
in each Received header.  Then it is easier to see the 'by' clause in a
Received header matches up with the 'from' header in the next (later)
Received header.  I end up with:

Received: 
  by   <host5> ------- by is last host
  from <host4> ---.
Received:         |--- from matches prior by
  by   <host4> ---'
  from <host3> ---.
Received:         |--- from matches prior by
  by   <host3> ---'
  from <host2> ---.
Received:         |--- from matches prior by
  by   <host2> ---'
  from <host1> ---.
Received:         |--- from matches prior by (1st host)
  by   <host1> ---'

The chaining gets a bit confusing when the from-host doesn't match the
prior by-host due to internal routing within an e-mail service, or the
Received header for an internal host doesn't show a by-host, just the
from-host.  The from-host won't of a subsequent legit Received header
won't match a bogus by-host in a Received added by a spammer.

Then there are the hyperlinks within the message.  Usually they point to
the spammer's/scammer's/phisher's website, but not always.  For example,
if you use Microsoft's Hotmail/Live/Outlook.com e-mail services,
Microsoft modifies the hyperlinks to point at their own anti-malware
servers.  When clicking on the modified hyperlinks, you first go to the
MS server that checks their blacklist.  If the link is okay, you then
get redirected by the MS server to the original target.  If the target
website is blacklisted, you are blocked.  This is Microsoft's Safe Links
"feature" as part of their ATP (Advanced Threat Protection) service.  It
interferes with spam reporters trying to submit spam reports to both the
e-mail source, and to the domain owners of the spam websites.  If you
have a freebie account, you have to use their feedback to request ATP be
disabled on your account.  If you have a school or company account, you
can ask your e-mail admin to change your account to disable ATP: it's an
option in the admin control panel on configuring accounts.  If you have
a paid account, maybe you have an option to disable ATP, but I don't
have a paid MS account to check.  I have a free account, so I had to use
feedback to get ATP disabled.  I requested, they disabled, later it got
reenabled, I requested to disable, they disabled, reenabled again, and
asked again to disable.  

I only know Safe Links got disabled by inspecting the HTML code for the
hyperlinks (the href attribute in the <A> tag) within messages to see if
they point to:

https://<varHost>.safelinks.protection.outlook.com/<args>

The <args> contain the original website's URL.  I don't know if
Microsoft is the only asshole modifying hyperlinks in received e-mails.
The moment Microsoft decides to discontinue ATP means all hyperlinks in
your e-mails that utilize redirect to MS hosts become unusable; i.e.,
instant link rot.  To avoid the possibility of link rot, I have MS
disable their Safe Links "feature" in my MS account, but it days several
days before they respond and act, and repeated requests if and when they
decide to later reenable ATP.

While looking at the href attribute in an <A> HTML tag will show the
target for a hyperlink, nowadays a lot of web pages are using Javascript
to construct the URLs on-the-fly, or to obfuscate them.  I've even seen
URLs that were split across cells in a row in a table, so they were not
seen as URLs, and Javascript added the protocol prefix (HTTP[S]://), and
built the URL from entries in the table.  All to hide to where a link
points.  Either from the <A> tag's href attribute, or by walking through
the Javascript (if you leave it enabled for e-mails -- which I don't),
you can tell to where the link points.

I don't if by "origin" you are looking at the headers of an e-mail, or
at the hyperlinks (or what looks like hyperlinks) within the body of an
e-mail.  For many e-mail client, you can hover the mouse pointer over a
hyperlink to see a help bubble appear (usually at the bottom left of the
window) that tries to show to where the hyperlink points.  However, if
the link is scripted, what the bubble shows may not be to where the link
will drop you when you click on what looks like a hyperlink.