Jump to content
klappa

Something wrong with Outlook reporting

Recommended Posts

On 11/30/2018 at 9:29 PM, klappa said:
On 11/29/2018 at 12:15 PM, petzl said:

Just send email to whatever the abuse address is for your email provider forward as attachment.

What are you talking about? I don't think you understand my initial question. It always sends to report_spam at hotmail dot com no matter what.

Just forward spam as attachment from your email to abuse desk (not through SpamCop if there are parsing problems). 

Share this post


Link to post
Share on other sites
46 minutes ago, petzl said:

Just forward spam as attachment from your email to abuse desk (not through SpamCop if there are parsing problems). 

But that will expose my e-mail isn't that why i am using Spamcop in the first place? Something I've paid to work but doesn't work as intended?

Edited by klappa

Share this post


Link to post
Share on other sites
14 minutes ago, klappa said:

But that will expose my e-mail

See my longer post at the top of thread.

There are other reasons to use SpamCop: Normally SpamCop correctly does the work of finding abuse addresses, and reporting to SpamCop feeds the SCBL.

Share this post


Link to post
Share on other sites
48 minutes ago, klappa said:

But that will expose my e-mail isn't that why i am using Spamcop in the first place? Something I've paid to work but doesn't work as intended?

Only to YOUR email provider. The spammer already has your email addy anyhow, 

Share this post


Link to post
Share on other sites
On 11/30/2018 at 11:29 PM, klappa said:

Editing it how? Changing it Receive line to X-Received? For Gmail i just delete the Receive line and Spamcop can parse it otherwise it can't.

Instead of forwarding the spam as an attachment to "my" reporting adddres, I use the "view source" option of whichever email client, copy it to the submission form on the reporting page, and change the "Received" to "X-Received" before  clicking "submit"

Share this post


Link to post
Share on other sites

Hi Lisati, I've not tried the method you've suggested (but I'd like too), looking at recent spam source data, there's 2 or more "Received" lines: do you change only the first "Received" to "X-Received" or ?

And, I've read (SC Faq & SCF) to not modify source data, how does this guidance fit with changing "X-Received" etc... ?

Thanks in advance☺️

Share this post


Link to post
Share on other sites
On 11/28/2018 at 5:51 PM, klappa said:

So you're telling me i have to remove the top most Recieve line header to get Spamcop to parse the email spam right? Just like with Gmail?

yep, I do remove the top line, just like I do with gmail.  I think this is a mailhosts problem where the mailhost section probably records every address.  It seems to be too many address for it the parser to be able to detect that any address for 2603:1000::/24 is a valid mailhosts.  I think the problem becomes that 20,282,409,603,651,670,423,947,251,286,016 (2^104) is just too many addresses for the mailhosts entry to record.

Share this post


Link to post
Share on other sites

Well, after several months of complaining and work-arounds, the SC update to v 5.0.0 finally did it (at least one part of this post's problem):

IPv6 6to4 WORKS!!! 🤩

Share this post


Link to post
Share on other sites

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:P 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!

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

What I'm seeing with th

On 1/15/2019 at 5:20 PM, ANGEL said:

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

  • And, anyone who's game:P 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!

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

Share this post


Link to post
Share on other sites
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!

 

 

 

 

Edited by ANGEL
txt correction

Share this post


Link to post
Share on other sites
On 1/14/2019 at 10:20 PM, ANGEL said:

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:P 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!

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

Share this post


Link to post
Share on other sites
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:)

 

 

 

 

 

Share this post


Link to post
Share on other sites
On 1/17/2019 at 5:02 AM, 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

 

On 1/17/2019 at 8:22 AM, ANGEL said:

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:)

 

 

 

 

 

Thank you RobiBue! Great job explaining it.

I wonder why MS did this in the first place? Didn't they think this would break spamreports?

Share this post


Link to post
Share on other sites
6 hours ago, klappa said:

I wonder why MS did this in the first place? Didn't they think this would break spamreports?

Hey Klappa:

From SCAdmin:

quote:
"A couple of years ago Hotmail had to give up two /16 networks they were 
using (33,554,432 IP addresses) as they were not assigned to them. 
Microsoft had to quickly reconfigure their network and used IPv6 to do so.

Unfortunately when doing so, they did not do it carefully and make sure 
they had full name resolution through out the network, where the forward 
and reverse dns on each server matches.  This means SC can't trust their 
headers and will often take them as the source of the spam.

All is not lost though, as Hotmail's parsing engines when they receive 
the report does pass through the report to the right party.  It also 
helps Hotmail block new spam from that source.

Microsoft is working on resolving the issue, but it is a couple of 
hundred thousand servers.  They have told us (SC) though, the fix is measured 
in years, not weeks or months."

Unquote

Given the above & other "evidence", I'm not entirely sure MS's default position involves thinking😞


 

Edited by MIG
text correction

Share this post


Link to post
Share on other sites
On 1/24/2019 at 7:22 AM, MIG said:

Hey Klappa:

From SCAdmin:

quote:
"A couple of years ago Hotmail had to give up two /16 networks they were 
using (33,554,432 IP addresses) as they were not assigned to them. 
Microsoft had to quickly reconfigure their network and used IPv6 to do so.

Unfortunately when doing so, they did not do it carefully and make sure 
they had full name resolution through out the network, where the forward 
and reverse dns on each server matches.  This means SC can't trust their 
headers and will often take them as the source of the spam.

All is not lost though, as Hotmail's parsing engines when they receive 
the report does pass through the report to the right party.  It also 
helps Hotmail block new spam from that source.

Microsoft is working on resolving the issue, but it is a couple of 
hundred thousand servers.  They have told us (SC) though, the fix is measured 
in years, not weeks or months."

Unquote

Given the above & other "evidence", I'm not entirely sure MS's default position involves thinking😞


 

So we never have to delete the first receive header ever again? The problem is that if we don't the spam will always be passed to abuse at microsoft dot com. Do you think they manually pass through to the right ISP or host owner? I can't believe that, it would require to much work on their part.

Share this post


Link to post
Share on other sites
Posted (edited)
8 hours ago, klappa said:

1. So we never have to delete the first receive header ever again? 2. The problem is that if we don't the spam will always be passed to abuse at microsoft dot com. 3. Do you think they manually pass through to the right ISP or host owner? 4. I can't believe that, it would require to much work on their part.

1. Until MS fix the "hundred thousand servers,  the fix is measured 
in years, not weeks or months", 
we (spamfighters) must continue to manually remove the 1st receive header. 
2. Correct.
3. No, I don't they (MS) manually pass to the right ISP/Host owner, in fact, in my experience, MS simply engage in  "hot potato-mind-numbing" converstions with statements like "not our responsibility"🤬 
This is completely contrary to Richards statement "All is not lost though, as Hotmail's parsing engines when they receive the report does pass through the report to the right party.  It also helps Hotmail block new spam from that source".
I've never experienced this result from MS, not saying Richard is wrong, simply saying, my experience with MS, on this specific subject, has never resulted in MS being proactive with the actions Richard describes.
4. Agreed, however, MS don't have a good track record when it comes to "fixing" their products.

G🦗H

Edited by MIG

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×