[Something wrong with Outlook reporting]

3 hours ago, RobiBue said:

Sorry it's taken me so long to reply, but I've been busy and could only do minimalistic replies, so I have waited until I had more time to delve in deeper...

While the Gmail hack is no longer necessary, unfortunately Microsoft's outlook "hack" is still needed due to its difference...

looking at the unmodified Received: headers in https://www.spamcop.net/sc?id=z6513483714z596b7c076a2121c3ce82e632cf6e31a3z

[line]  (Received origin/destination)
[0001]  Received: from PU1APC01HT007.eop-APC01.prod.protection.outlook.com (2603:10a6:800:92::20)
[0002]              by VI1PR06MB5360.eurprd06.prod.outlook.com
[0003]  Received: from PU1APC01FT052.eop-APC01.prod.protection.outlook.com (10.152.252.54)
[0004]              by PU1APC01HT007.eop-APC01.prod.protection.outlook.com (10.152.252.101)
[0005]  Received: from iainternalmeds.com (69.160.26.74)
[0006]              by PU1APC01FT052.mail.protection.outlook.com (10.152.253.137)
(only the Received: lines are relevant here. Omitting the timestamps as well as the transfer method/protocol)

Line [0002] is the host from which you picked the email up.
Lines [0001] and [0004] should have the same host name and number, but only the host name is the same, so SC cannot safely confirm that it is the same host and with right determines the following: "Internal handoff or trivial forgery".
Lines [0003] and [0006] also should have the same host name/address, but neither are equal, and therefore line [0005] is also a possible forgery.

It looks complicated like this, but by keeping in mind, that the header lines are actually filled from the bottom up, let's "flip" the above Received: header lines:

[line]  (Received origin/destination)
[0005]  Received: from iainternalmeds.com (69.160.26.74)
[0006]              by PU1APC01FT052.mail.protection.outlook.com (10.152.253.137)
[0003]  Received: from PU1APC01FT052.eop-APC01.prod.protection.outlook.com (10.152.252.54)
[0004]              by PU1APC01HT007.eop-APC01.prod.protection.outlook.com (10.152.252.101)
[0001]  Received: from PU1APC01HT007.eop-APC01.prod.protection.outlook.com (2603:10a6:800:92::20)
[0002]              by VI1PR06MB5360.eurprd06.prod.outlook.com
(only the Received: lines are relevant here. Omitting the timestamps as well as the transfer method/protocol)

[0005] sent it
[0006] received it which then in turn sent it as [0003]  (PU1APC01FT052 is the same, but then the sub-domain name differs as well as the private IP address)
[0004] received it which then in turn sent it as [0001] (here all: host, sub-domain, and domain are exactly the same, but unfortunately the address is not)
[0002] received it in the end, waiting for you to pick it up.

Therefore, unfortunately, Received: line [0001]/[0002] is the only trusted Received header: and the rest: [0003]/[0004], and [0005]/[0006] are possible forgeries in the eye of SC.

By removing the top Received: line (here [0001]/[0002]) in outlook recipients, SC treats the following Received lines as Private/internal handoffs and correctly identifies the culprit in [0005].

This is not SC's fault, and SC cannot fix it. This fix has to come from M$ themselves, and, although SC did fix it in Gmail's sector, which, though Gmail's fault, and rightly also in Gmail's mail-server's code to be fixed, as 6to4 addresses should not propagate with private networks, is in the end a needed fix in SC's parser, and hopefully, whoever fixed it, made sure that only private networks are affected in the 2002:: 6to4 range, because it is possible (and allowed) to have valid IPv4 networks translated and propagated in IPv6 6to4 addresses. (please forgive the long-winding-ultra-long-complex-sentence. I hope it is understandable 🙃.)

So in the end, the answer is as follows:

For Gmail users: you do not have to remove/replace the 1st (topmost) Received: header.

For Outlook users: you still have to remove/replace the 1st (topmost) Received: header. Sorry.

This should answer both parts of the question. HTH

RobiBue,

Thank you so much for taking super care and investing time and energy to provide comprehensive explanation. As I'm still on my SCLplates logical/comprehensive responses aid my learning & understanding.

I'm really grateful!

I do understand why MS is in such a state, SCAdmin have previously advised MS made some "errors" when trying to fix other MS errors, SCA also advised the time frame for MS fix is likely to be years; so I'm cool with still modifying any source data I submit to SC.

Rome wasn't built in a day, MS architects don't seem to often refer to their building sketches so, fix years away, may happen after I'm dead in which case I don't expect to be worrying about scum🤥🦹‍♂️🦹‍♀🤥s.

Back to your excellent information, dunno what your day job is but you could easily/successfully be writing tech training doco.

Don't answer this by telling me you make a quid by being a 🤥🦹‍♂️🦹‍♀🤥r!

Thanks a bunch

 

 

 

 

 

[Something wrong with Outlook reporting]

1 hour ago, lisati said:

What I'm seeing is that the modification(s) still seem to be necessary.

Thank you Lisati There's a bunch of us asking this ❔.

As a SC🔰🚗🔰, info from experienced SCF members & other SC posters is invaluable; has  helped me understand some of the 🦹logic/motivation & how to effectively☠️🦹☠️as many as possible 

The (v4/v5) difference (I observe) is v5 is now providing:

Message source: 2603:10c6:1:0:0:0:0:25:; Routing details for 2603:10c6:1:0:0:0:0:25
whois for 2603:10c6:1:0:0:0:0:25 : abuse@microsoft.com; abuse@hotmail.com redirects to report_spam@hotmail.com

That's a good thing, as, previously, when I forwarded ANY [source data spam] to MS, they'd always refuse to accept.

I'm waiting to hear from MS now that I provided msg source/routing details (from a spam today)...

Additionally, it'll be good if SC let us know what the v5 changes are (unless of course those changes are not for publication) 

Thanks again & cheers!

 

 

 

 

[Something wrong with Outlook reporting]

RobiBue, you may be able to answer my question please (specific to SCv5)(IPv6 624)

With V5, do we no longer have to  "cut"

1st [Received: from PU1APC01HT007.eop-APC01.prod.protection.outlook.com(2603:10a6:800:92::20) blah, blah, blah, Mon, 14 Jan 2019 06:08:02 +0000]

?

instead post to parser ENTIRE source data?

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

• And, anyone who's game may be able to answer:

if the answer's "yes"; why parsing the entire source data would result in different [Reports sent to] distributions?

https://www.spamcop.net/sc?id=z6513483714z596b7c076a2121c3ce82e632cf6e31a3z

as opposed to parsing modified source data  [Reports sent to] distributions

https://www.spamcop.net/sc?id=z6513484404zf0c78fe42b97237ee395ad8a37facc9cz

Thanks in advance!

 

 

 

 

 

 

[Unable to submit spam: "This header is incomplete. Please supply full headers of the spam.. etc"]

Sorted, used the split form submission & removed the first "Received: from... etc" statement.

Dogged determination = monkeys can be trained!

[No source IP address found, cannot proceed.]

Sorted, used the split form submission & removed the first "Received: from... etc" statement.

See, monkeys can be trained!

[Unable to submit spam: "This header is incomplete. Please supply full headers of the spam.. etc"]

Microsoft Outlook (all versions) Outlook does not properly forward mail with the headers and message body intact. It is not possible to use SpamCop's email submission system with Outlook unless you use one of the below add-on programs or similar macro.

This is not making sense, up until today I've successfully submitted spam received by https://outlook.live.com/mail/ have always been able to extract source & no issues with formatting, empty spaces, nor have I had to use add-on programmes/macros... ?

This doco - https://www.spamcop.net/fom-serve/cache/122.html - Microsoft Outlook (all versions) doesn't seem to cover OL Live or OL 2016 app...

Tad confused...

 

[Unable to submit spam: "This header is incomplete. Please supply full headers of the spam.. etc"]

Hmmm, well accessing the "source" via OL 2016 application only provides [Internet Headers] up to MIME-Version: 1.0, too easy i thought, I'll merge both "sources, result:

https://www.spamcop.net/sc?id=z6497304898z7fabab608a9bb85e2813e9a087b130fbz

No body text provided, check format of submission. spam must have body text.

??

Back to reading " SpamCop Parsing and Reporting Service : How do I get my email program to reveal the full, unmodified email?"?

If anyone has any information please it will be gratefully received?

 

 

 

[Unable to submit spam: "This header is incomplete. Please supply full headers of the spam.. etc"]

Hello LKing,

thanks for the appraisal & guidance.

Re: retrieving the source, I used the same method I've been using since joining SC  & for several years, lamely reporting to MS, however, today, MS have shipped their new wizzbang (not) upgraded Outlook, has been in beta for many months, now in production... I'm not sure if this may be the source of the issue, this is the 3 spam email I've had today with these results from SC & they're not errors I've encountered before...?

Even tho I can clearly see the blank lines in your assessment, when I extract the source this is what I see:
Received: from CO1NAM05HT092.eop-nam05.prod.protection.outlook.com (2603:10a6:802:28::17) by VI1PR0601MB2318.eurprd06.prod.outlook.com with HTTPS via VI1PR09CA0049.EURPRD09.PROD.OUTLOOK.COM; Tue, 30 Oct 2018 21:10:23 +0000 Received: from CO1NAM05FT040.eop-nam05.prod.protection.outlook.com (10.152.96.56) by CO1NAM05HT092.eop-nam05.prod.protection.outlook.com (10.152.97.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1294.4; Tue, 30 Oct 2018 21:10:21 +0000 Authentication-Results: spf=none (sender IP is 201.157.183.34) smtp.mailfrom=pharmacy.can; hotmail.com; dkim=none (message not signed) header.d=none;hotmail.com; dmarc=none action=none header.from=pharmacy.can; Received-SPF: None (protection.outlook.com: pharmacy.can does not designate permitted sender hosts) Received: from pharmacy.can (201.157.183.34) by CO1NAM05FT040.mail.protection.outlook.com (10.152.96.153) with Microsoft SMTP Server id 15.20.1318.5 via Frontend Transport; Tue, 30 Oct 2018 21:10:18 +0000 X-IncomingTopHeaderMarker:

Truncated - I've read your advice to not fill up the Forum with spam source files

The only thing I can thing to do is test extracting it with the mail app rather than the mail via browser & see if I get a different result.

 

[No source IP address found, cannot proceed.]

Unable to submit spam:

https://www.spamcop.net/sc?id=z6497285331z69cf215c2810e4c269e23c502673fab1z

Help please....