petzl Posted December 1, 2018 Share Posted December 1, 2018 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). Quote Link to comment Share on other sites More sharing options...
klappa Posted December 1, 2018 Author Share Posted December 1, 2018 (edited) 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 December 1, 2018 by klappa Quote Link to comment Share on other sites More sharing options...
Lking Posted December 1, 2018 Share Posted December 1, 2018 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. Quote Link to comment Share on other sites More sharing options...
petzl Posted December 1, 2018 Share Posted December 1, 2018 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, Quote Link to comment Share on other sites More sharing options...
lisati Posted December 2, 2018 Share Posted December 2, 2018 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" Quote Link to comment Share on other sites More sharing options...
MIG Posted December 4, 2018 Share Posted December 4, 2018 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☺️ Quote Link to comment Share on other sites More sharing options...
gnarlymarley Posted December 4, 2018 Share Posted December 4, 2018 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. Quote Link to comment Share on other sites More sharing options...
RobiBue Posted January 14, 2019 Share Posted January 14, 2019 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!!! 🤩 Quote Link to comment Share on other sites More sharing options...
ANGEL Posted January 15, 2019 Share Posted January 15, 2019 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! Quote Link to comment Share on other sites More sharing options...
lisati Posted January 17, 2019 Share Posted January 17, 2019 What I'm seeing with th On 1/15/2019 at 5:20 PM, ANGEL said: ------------------------------------------------------------------------------------------------------------------------------------ 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! What I'm seeing is that the modification(s) still seem to be necessary. Quote Link to comment Share on other sites More sharing options...
ANGEL Posted January 17, 2019 Share Posted January 17, 2019 (edited) 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 January 17, 2019 by ANGEL txt correction Quote Link to comment Share on other sites More sharing options...
RobiBue Posted January 17, 2019 Share Posted January 17, 2019 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 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 Quote Link to comment Share on other sites More sharing options...
ANGEL Posted January 17, 2019 Share Posted January 17, 2019 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 Quote Link to comment Share on other sites More sharing options...
klappa Posted January 24, 2019 Author Share Posted January 24, 2019 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? Quote Link to comment Share on other sites More sharing options...
MIG Posted January 24, 2019 Share Posted January 24, 2019 (edited) 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 January 24, 2019 by MIG text correction Quote Link to comment Share on other sites More sharing options...
klappa Posted July 3, 2019 Author Share Posted July 3, 2019 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. Quote Link to comment Share on other sites More sharing options...
MIG Posted July 3, 2019 Share Posted July 3, 2019 (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 July 3, 2019 by MIG Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.