unitacx

Resolved! One fairly easy work-around for Outlook running through an "Office 365" server, obviously routed through hotmail: On mine, the first 3 headers which include "outlook.com" render spam reporting addresses as "report_spam@hotmail.com". So here's the fix: 1. Set your mailhost on Spamcop (obviously) 2. On Spamcop reporting, copy the headers from a sample email, preferably from a known source. (As expected, Spamcop will show the hotmail.com reporting address) 3. Repeat with sequential "Received:" headers removed. When doing this, remove the headers all the way from the top, so ... - on the initial try, remove the first "Received:" header; - on the next try, remove the first and second "Received:" headers; - on the next try, remove the first, second, and third "Received:" header; - ... etc. Eventually you will get the spam reporting address as the outside server. On mine, there were three outlook.com "Received:" headers, followed by an "Authentication-Results:" header. By removing those first three "Received:" headers, I was able to get to the source of my sample email. Then I carefully read the text of that suspected spam and determined that an email from my home account with the word "test" on the subject line was possibly not spam. So after all that effort, I didn't even report it. On my version of "Outlook 365" running through an office server, it's just a matter of stripping the first three "Received:" headers.

Solved: Spamcop will give a waiver on this by request. There is a suggestion that the user can gain acceptance by using a incrementally authenticating (first) the original host (Verizon) and then (second) authenticating the full headers (Verizon with AOL), but that did not work for me. EDIT: Was able to get it to work in 2 steps (see below) There is a convenient work-around for this... at least it is convenient for me because I generally inspect the email for identifying data: Look at the headers to identify the aol.com routing. On mine it's easy to spot because it is partially indented: Received: from vms172087.mailsrvcs.net ... by mtaiw-mca01.mx.aol.com (Internet Inbound) with ESMTPS id E0123456789AB for <[verizon email address]>; Mon, 24 Apr 2017 08:01:03 -0400 (EDT) This shows up in the email header and in the Spamcop error message. Re-send the authentication request quoted in the Spamcop error message, but without that aol.com routing header. That lobs off the second mailhost (aol.com) header. You should get a "success" unless you are front ended with yet another mailhost (in which case you would need to go one deeper). After the first host (verizon) is authenticated, try to go through the full authentication process again, but this time do not lob off the 2nd header (aol.com). This requires the full authentication process, meaning a 2nd host authentication request. This step authenticates the 2nd host (aol.com). If it doesn't work, then spams can still be reported if the 2nd header (aol.com) is lobbed off. When reporting spams, lob off the same aol.com header (if you were unable to authenticate with the full aol.com headers). That 2nd header would not be part of the actual spam because it is nothing more than your own ISP's routing. If the second host header (aol.com) is indented, this should be a "no brainer" step. Obviously, if you had been able to get the full authentication process to work, you need not lob off anything. The usual precautions: Look at what you are reporting, especially the first few times, to be sure you are reporting the actual spammer.