Jump to content

RobiBue

Membera
  • Content Count

    135
  • Joined

  • Last visited

Posts posted by RobiBue


  1. FYI reporting that specific address (the one given in the "obviously" fake received s.okazik.pl header) is pointless and makes no sense.

    all it is, is a fake injected header line by the spammer or by the spammer software.

    the actual Received: header line is

    Received: from fervently.site (fervently.site. [103.1.12.91])
            by mx.google.com with ESMTP id c16si308648pgh.545.2019.02.09.06.43.54
            for <x>;
            Sat, 09 Feb 2019 06:43:54 -0800 (PST)
    Received-SPF: temperror (google.com: error in processing during lookup of return@asciidic.com: DNS error) client-ip=103.1.12.91;
    Authentication-Results: mx.google.com;
           spf=temperror (google.com: error in processing during lookup of return@asciidic.com: DNS error) smtp.mailfrom=return@asciidic.com

    but as you can see, even Google mail sees a DNS problem with that IP address.

    everything below these headers in the original spam is injected by the spammer's software


  2. 4 hours ago, MIG said:

    RobiBue, 

    Apologies for no response to your brilliant 🕵️‍♂️analysis, documenting same and your lethal humor, YOU'RE a bloody legend!

    No response (from me) due to 💻 crashed & burned during massive storm, all bu's, recovery, etc failed, needed admission to ER! 

    BC some SCF doco disappears into some black hole from which nothing can be retrieved, I'm now archiving all great, helpful, useful posts, of which, many are yours.

    🙏Thank you🙏 so much🙏!

    sorry to hear that. hope y'all are ok though.

    btw I wasn't expecting a reply, just passing information I find for the good of everyone ;)

    if someone does have info that doesn't support my theory, I would gladly look at it from a different objective standpoint. 🔭🔍🔬


  3. 1 hour ago, petzl said:

    I get the IP 216. 244.76.116 located in USA
    https://www.talosintelligence.com/reputation_center/lookup?search=216. 244.76.116

    most likely a infected/compromised server  

    yeah, that's why I'm saying, I believe that injected Received line acts somewhat as a signature placed there by the designer of the malware...

    that IP might, at one time, have been assigned there... I don't know if there is a historical IP database available ;)

    but I understand now what you meant. thanks.


  4. On 2/10/2019 at 6:59 PM, petzl said:

    The email server (probably infected) is not stamping a received line. Instead it's stamping 
    Received: from s.okazik.pl (s.okazik.pl. 216.244.76.116)
     

    hehe :) I noticed, on google maps, that okazik.pl is a fully "blacked-out" 24h internet c@fe in a Polish city called Poznań, right between Berlin and Warsaw...

    might even be the home of the original developer of the spamming malware...


  5. 18 hours ago, petzl said:

    not stamping recived IP spammer is adding this to headers
    Received: from s.okazik.pl (s.okazik.pl. 216.244.76.116)  

    Sorry, could you explain what you mean here? other language maybe? Deutsch? Español? Italiano? Français? Portugues?

    I Know that the spammer is placing this there. or at least the software he uses. that's why I said that whoever wrote the spammer's software it is using it as some kind of a signature. maybe to see how many different spammers are using his software...


  6. 2 hours ago, MIG said:

    Hi Petzel & RobiBue, 

    Thank you, both of you; I concur, however these are the replies I get from Sendgrid:

    quote:

    "the domain sendgrid.net is not currently registered through our service. The IP address 50.31.49.41 does not belong to our service,  &  the URL of virustotal.com shows, the current registrar of the domain sengrid.net is GoDaddy.com, LLC. We therefore suggest to contact GoDaddy.com, LLC or the registrant of the domain. & as we mentioned in our previous mail, the domain is not registered through our service, and the IP address belongs to  GoDaddy.com, LLC. Therefore the responsible registrar in question is GoDaddy.com, LLC. Please contact abuse@godaddy.com for further investigation:

    addresses        50.31.49.41
    Domain Whois record

    Queried whois.internic.net with "dom sendgrid.net"...

       Domain Name: SENDGRID.NET
       Registry Domain ID: 1552841547_DOMAIN_NET-VRSN
       Registrar WHOIS Server: whois.godaddy.com
       Registrar URL: http://www.godaddy.com
       Updated Date: 2018-04-21T14:31:24Z
       Creation Date: 2009-04-20T09:09:23Z
       Registry Expiry Date: 2019-04-20T09:09:23Z
       Registrar: GoDaddy.com, LLC
       Registrar IANA ID: 146
       Registrar Abuse Contact Email: abuse@godaddy.com
       Registrar Abuse Contact Phone: 480-624-2505"

    😕

    unquote

    very interesting:

    02/08/19 22:49:04 whois dom sendgrid.com@whois.internic.net
    
    whois -h whois.internic.net dom sendgrid.com ...
       Domain Name: SENDGRID.COM
       Registry Domain ID: 1552841541_DOMAIN_COM-VRSN
       Registrar WHOIS Server: whois.godaddy.com
       Registrar URL: http://www.godaddy.com
       Updated Date: 2018-04-21T14:31:24Z
       Creation Date: 2009-04-20T09:09:19Z
       Registry Expiry Date: 2019-04-20T09:09:19Z
       Registrar: GoDaddy.com, LLC
       Registrar IANA ID: 146
       Registrar Abuse Contact Email: abuse@godaddy.com
       Registrar Abuse Contact Phone: 480-624-2505

    and

    02/08/19 22:48:32 whois dom sendgrid.net
    .net is a domain of Network services
    Searches for .net can be run at http://www.crsnic.net/
    
    whois -h whois.crsnic.net dom sendgrid.net ...
       Domain Name: SENDGRID.NET
       Registry Domain ID: 1552841547_DOMAIN_NET-VRSN
       Registrar WHOIS Server: whois.godaddy.com
       Registrar URL: http://www.godaddy.com
       Updated Date: 2018-04-21T14:31:24Z
       Creation Date: 2009-04-20T09:09:23Z
       Registry Expiry Date: 2019-04-20T09:09:23Z
       Registrar: GoDaddy.com, LLC
       Registrar IANA ID: 146
       Registrar Abuse Contact Email: abuse@godaddy.com
       Registrar Abuse Contact Phone: 480-624-2505

    so, interestingly, sendgrid.com and sendgrid.net are both registered through godaddy, and, coincidentally, both sendgrid domains were created 2009-04-20T09:09 with a 4 second time difference, and both were also coincidentally updated exactly at the same time and date 2018-04-21T14:31:24Z

    also the registry domain ID is very odd:
    Registry Domain ID: 1552841541_DOMAIN_COM-VRSN
    Registry Domain ID: 1552841547_DOMAIN_NET-VRSN

    the numbers are waaaaaaaaaaaay too close....

    and digging deeper, I look at godaddy's whois database search:

    https://www.godaddy.com/whois/results.aspx?domain=sendgrid.net
    
    
    WHOIS search results
    Domain Name: SENDGRID.NET
    Registry Domain ID: 1552841547_DOMAIN_NET-VRSN
    Registrar WHOIS Server: whois.godaddy.com
    Registrar URL: http://www.godaddy.com
    Updated Date: 2018-04-21T14:31:23Z
    Creation Date: 2009-04-20T09:09:23Z
    Registrar Registration Expiration Date: 2019-04-20T09:09:23Z
    Registrar: GoDaddy.com, LLC
    Registrar IANA ID: 146
    Registrar Abuse Contact Email: abuse@godaddy.com
    Registrar Abuse Contact Phone: +1.4806242505
    Domain Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
    Domain Status: clientUpdateProhibited http://www.icann.org/epp#clientUpdateProhibited
    Domain Status: clientRenewProhibited http://www.icann.org/epp#clientRenewProhibited
    Domain Status: clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited
    Registry Registrant ID: Not Available From Registry
    Registrant Name: Operations Team
    Registrant Organization: SendGrid, Inc
    Registrant Street: 1801 California Street
    Registrant Street: Suite 500
    Registrant City: Denver
    Registrant State/Province: Colorado
    Registrant Postal Code: 80202
    Registrant Country: US
    Registrant Phone: +1.8779698647
    Registrant Phone Ext:
    Registrant Fax:
    Registrant Fax Ext:
    Registrant Email: domains-abuse@sendgrid.com
    Registry Admin ID: Not Available From Registry
    Admin Name: Operations Team
    Admin Organization: SendGrid, Inc
    Admin Street: 1801 California Street
    Admin Street: Suite 500
    Admin City: Denver
    Admin State/Province: Colorado
    Admin Postal Code: 80202
    Admin Country: US
    Admin Phone: +1.8779698647
    Admin Phone Ext:
    Admin Fax:
    Admin Fax Ext:
    Admin Email: domains-abuse@sendgrid.com
    Registry Tech ID: Not Available From Registry
    Tech Name: Operations Team
    Tech Organization: SendGrid, Inc
    Tech Street: 1801 California Street
    Tech Street: Suite 500
    Tech City: Denver
    Tech State/Province: Colorado
    Tech Postal Code: 80202
    Tech Country: US
    Tech Phone: +1.8779698647
    Tech Phone Ext:
    Tech Fax:
    Tech Fax Ext:
    Tech Email: domains-abuse@sendgrid.com
    Name Server: NS10.DNSMADEEASY.COM
    Name Server: NS11.DNSMADEEASY.COM
    Name Server: NS12.DNSMADEEASY.COM
    Name Server: NS13.DNSMADEEASY.COM
    Name Server: NS14.DNSMADEEASY.COM
    Name Server: NS15.DNSMADEEASY.COM
    DNSSEC: unsigned 

    wait a minute... what's that?
    Domain Name: SENDGRID.NET
    Registrant Email: domains-abuse@sendgrid.com

    hmmm.... let's look up the other one now:

    https://www.godaddy.com/whois/results.aspx?domain=sendgrid.com
    
    
    WHOIS search results
    Domain Name: SENDGRID.COM
    Registry Domain ID: 1552841541_DOMAIN_COM-VRSN
    Registrar WHOIS Server: whois.godaddy.com
    Registrar URL: http://www.godaddy.com
    Updated Date: 2018-04-21T14:31:23Z
    Creation Date: 2009-04-20T09:09:19Z
    Registrar Registration Expiration Date: 2019-04-20T09:09:19Z
    Registrar: GoDaddy.com, LLC
    Registrar IANA ID: 146
    Registrar Abuse Contact Email: abuse@godaddy.com
    Registrar Abuse Contact Phone: +1.4806242505
    Domain Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
    Domain Status: clientUpdateProhibited http://www.icann.org/epp#clientUpdateProhibited
    Domain Status: clientRenewProhibited http://www.icann.org/epp#clientRenewProhibited
    Domain Status: clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited
    Registry Registrant ID: Not Available From Registry
    Registrant Name: Operations Team
    Registrant Organization: SendGrid, Inc
    Registrant Street: 1801 California Street
    Registrant Street: Suite 500
    Registrant City: Denver
    Registrant State/Province: Colorado
    Registrant Postal Code: 80202
    Registrant Country: US
    Registrant Phone: +1.8779698647
    Registrant Phone Ext:
    Registrant Fax:
    Registrant Fax Ext:
    Registrant Email: domains-abuse@sendgrid.com
    Registry Admin ID: Not Available From Registry
    Admin Name: Operations Team
    Admin Organization: SendGrid, Inc
    Admin Street: 1801 California Street
    Admin Street: Suite 500
    Admin City: Denver
    Admin State/Province: Colorado
    Admin Postal Code: 80202
    Admin Country: US
    Admin Phone: +1.8779698647
    Admin Phone Ext:
    Admin Fax:
    Admin Fax Ext:
    Admin Email: domains-abuse@sendgrid.com
    Registry Tech ID: Not Available From Registry
    Tech Name: Operations Team
    Tech Organization: SendGrid, Inc
    Tech Street: 1801 California Street
    Tech Street: Suite 500
    Tech City: Denver
    Tech State/Province: Colorado
    Tech Postal Code: 80202
    Tech Country: US
    Tech Phone: +1.8779698647
    Tech Phone Ext:
    Tech Fax:
    Tech Fax Ext:
    Tech Email: domains-abuse@sendgrid.com
    Name Server: NS10.DNSMADEEASY.COM
    Name Server: NS11.DNSMADEEASY.COM
    Name Server: NS12.DNSMADEEASY.COM
    Name Server: NS13.DNSMADEEASY.COM
    Name Server: NS14.DNSMADEEASY.COM
    Name Server: NS15.DNSMADEEASY.COM
    DNSSEC: unsigned 

    Domain Name: SENDGRID.COM
    Registrant Email: domains-abuse@sendgrid.com

    and last but not least:

    Domain Name: SENDGRID.NET
    Registrant Name: Operations Team
    Registrant Organization: SendGrid, Inc
    Registrant Street: 1801 California Street
    Registrant Street: Suite 500
    Registrant City: Denver
    Registrant State/Province: Colorado
    Registrant Postal Code: 80202
    Registrant Country: US
    Registrant Phone: +1.8779698647

    vs.

    Domain Name: SENDGRID.COM
    Registrant Name: Operations Team
    Registrant Organization: SendGrid, Inc
    Registrant Street: 1801 California Street
    Registrant Street: Suite 500
    Registrant City: Denver
    Registrant State/Province: Colorado
    Registrant Postal Code: 80202
    Registrant Country: US
    Registrant Phone: +1.8779698647

    And the winner is: Rule#1!

    Oh, you got the wrong sendgrid in colorado! you need the other sendgrid in colorado!
    The one with the same address and same phone number.
     


  7. 14 minutes ago, MIG said:

    Hi Petzel & RobiBue, 

    Thank you, both of you; I concur, however these are the replies I get from Sendgrid:

    quote:

    "the domain sendgrid.net is not currently registered through our service. The IP address 50.31.49.41 does not belong to our service,  &  the URL of virustotal.com shows, the current registrar of the domain sengrid.net is GoDaddy.com, LLC. We therefore suggest to contact GoDaddy.com, LLC or the registrant of the domain. & as we mentioned in our previous mail, the domain is not registered through our service, and the IP address belongs to  GoDaddy.com, LLC. Therefore the responsible registrar in question is GoDaddy.com, LLC. Please contact abuse@godaddy.com for further investigation:

    addresses        50.31.49.41
    Domain Whois record

    Queried whois.internic.net with "dom sendgrid.net"...

       Domain Name: SENDGRID.NET
       Registry Domain ID: 1552841547_DOMAIN_NET-VRSN
       Registrar WHOIS Server: whois.godaddy.com
       Registrar URL: http://www.godaddy.com
       Updated Date: 2018-04-21T14:31:24Z
       Creation Date: 2009-04-20T09:09:23Z
       Registry Expiry Date: 2019-04-20T09:09:23Z
       Registrar: GoDaddy.com, LLC
       Registrar IANA ID: 146
       Registrar Abuse Contact Email: abuse@godaddy.com
       Registrar Abuse Contact Phone: 480-624-2505"

    unquote

    😕

    I would like to know how they can explain the following ARIN entry:

    https://whois.arin.net/rest/net/NET-50-31-32-0-1/pft?s=50.31.49.41

    which clearly names
    Origin AS: AS11377
    Organization: SendGrid, Inc. (SENDG)
    and is definitely sendgrid.com and not sendgrid.net

     


  8. 1 hour ago, petzl said:

    abuse[AT]steadfast.net.

    I concur. Sendgrid is a spammer friendly host and needs to be made aware that this is not acceptable. Thus:

    https://whois.arin.net/rest/net/NET-50-31-32-0-1/pft?s=50.31.49.41

    gives me parent: STEADFAST-6 (NET-50-31-0-0-1)

    which in turn returns Related organization's POC records.

     

    from which I can take (extrapolate?(sic))

    Abuse: ABUSE959-ARIN (ABUSE959-ARIN) -> https://whois.arin.net/rest/poc/ABUSE959-ARIN.html

    and you have the aforementioned abuse email address ;)

     


  9. G'day Chris,

    On 1/31/2019 at 8:38 PM, csouter said:

    If a message has been correctly identified as spam, normally I will still report it to SpamCop, (having first redacted those lines that Gmail inserts into the headers, causing SpamCop to think that there's "nothing to do").

    Redacting/removing those lines for gmail spam is not necessary anymore since the new SpamCop upgrade to version 5 :)

    You can save/skip that step entirely.

    Greetings to the other side of the world :) (it's cold up here ;) )


  10. 9 hours ago, Lking said:

    Of course it is possible to set the forum to require approval for all first post, spam or otherwise.  Admin would still need to look at each first/new post to process as spam or approve and/or respond.  The only difference would be members would not see spam and new members would have to wait until Admin approves their post before getting any help.  JMHO

    :( yeah, that's not what I meant though :( admins like you have already plenty on their plate, and I've noticed, there aren't many around... in fact, I've only seen two or maybe three admins around...

    what I meant was, to make it easier on y'all, have the system automatically sort newbies and forum spammers maybe through a learning curve, which would in the end benefit the users and the admins. Of course, such a system would have to be written and implemented and I'm not sure if one like that already exists -- although I would think so...


  11. back in May 2018 I started receiving a slew of spew which peaked in the hundreds in June-August, where I finally got the Gmail faux-pas with 6to4 IPv6 problem completely figured out and was able to report correctly to the necessary abuse desks. The spam started diminishing again and now, finally, with a few oddballs, the last one so far I received was on 4 days ago! YAY!

    Thanks for all that helped me figure out the IPv6 problem and that gave me tips and showed me tricks ;)

    I believe in the end it has been a combination of SpamCop and manual reporting where SC didn't find the correct abuse desk or couldn't follow the region's whois server ("refuse to bother lacnic" or "apnic") because the address is/was an old grandfathered transfer from "internic"...

    Anywho... 2 - 3 spams a week seems like a pretty good deal where it was over 100 a day...

    if now, the forum spam could be handled the same way and reduced to nil... wouldn't that be great... not a question, just a loud thought ;)

    I know, since SC deals with spam (duh) it would be pointless to implement a spam filter in the fora since many valid posts would be marked as spam (again duh) but there should be a way where newbies and forum spammers could be sorted out at the beginning, and have a few newbie posts get the warning that a forum admin will need to approve their post.

    I believe that could work, as it would burden the admins less since they wouldn't have to take care of every forum spam -- at least I believe so...


  12. On 1/25/2019 at 7:59 AM, stan55 said:

    I am getting this message very often.  I check the number of bytes in my word processor.  I never send anything more than 40K bytes.  Why does SpamCop complain very often about these message sources?  How do you count the number of characters anyway?  I suspect that if I sent one of 100 characters, you would also complain that it was too long, although you would have numerous other complaints.

    Also, there seems to be no problem when I submit the report.  Almost every time I login, there is a message for me that says I am submitting a report that is too large. Is it possible for your code writers to catch the real problem and report it as soon as I submit the wrongly formatted report?  Sometimes, I wonder if SpamCop is still actually operational at all. The coders don't really seem to have it all together.

    depending on the email program/UI you use, if you run into a >50k problem, you might want to try to export the spam as .eml or .txt (depending on the ability of your emailer) and check the size like that. You can then use a text program like notepad (if you use M$) and go down about half the way into the message and just delete the rest from there on down. then attach the truncated file to a new email and send it to your secret email code at spamcop.

    w/r to the login, that happens when you are not logged in and end up with a link to a previously reported spam

    I get that often and all I do is click on the report spam tab/link at the top of the page. that solves it.


  13. I wouldn't bother with the links in the spam body. Oftentimes they are just sites that spammers try to get in trouble.

    I know, in this case they are not, or most probably not, but many times, when they are connected to the spammer themselves, they contain a tracking link which links you (or better, your address) to the received spam, and every time the link gets a hit, it means for the spammer:

    a) they get paid
    b) they can send one or more spams to that email address

    The less (or zero) activity the spammer gets on the link, the more likely your address will get dropped from his list.

    And as you have already noticed, cloudflare doesn't care what or who they are hosting as long as they get paid

    so again, my suggestion here is either:
    a) don't report these kind of links
       or
    b) don't even bother reporting this type of spam

    I know, the latter sounds counter intuitive, but taking into consideration that spamcop checks the link, that means that the spammer gets their activity and you'll get another swarm of spam delivered...

    Of course, you are welcome to do some manual work and edit those links by removing the tracking path completely (with the notice for the abuse desk that the link has been modified to protect yourself)

    here is a boilerplate I place in the spams I receive for that purpose:

    Comments: The recipient of the email wishes to stay anonymous and therefore
           has munged his name and/or address for privacy reasons to strings like "x-x-x" or "x".
           Please respect his privacy. 

    I was hoping SC version 5 would have the full links reduced to host/domain only and not the full path... pity
     


  14. 5 hours ago, MIG said:

    Hello Lking, thanks for replying:).

    I have submitted both modified & unmodified data, end result, different, hence my question.

    I've asked this question on other's posts, provided examples, no-one responded, hence this post - leading me to cogitate, which method is more accurate, more likely to produce the best outcome, i.e, get notifications sent to those responsible that will really pay attention & take action?

    No modified source data, i.e 1st {Received) not removed: 

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

    Modified source data, i.e 1st {Received) removed:

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

    & a v5 general ?, do you know if there's any available v5 information/changes faq available please? If so where? Please!:)

    I do wish as well, that parser changes could/would be posted, but that's up to Cisco/Talos to decide if a changelog or list of fixes wouldn't compromise their secrecy in security and vulnerability holes that they want to keep hidden from us mere mortals.

    That said/vented, see my latest post here:

     


  15. 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


  16. 12 hours ago, gnarlymarley said:

    RobiBue, I just tried your tracking URL and it seems to be pointing properly to a leaseweb abuse address.  I think the 5.0 upgrade may have solved this issue.

    Thanks for checking, alas, the reason for the "correct" reporting address is:

    https://www.spamcop.net/sc?action=showroute;ip=209.58.179.237;typecodes=16

    1/15/2019, 3:16:28 PM -0600
    [Note added by x-x-x]
    Route added without comment

    not the new SC version :(


  17. On 1/12/2019 at 5:36 PM, Borgholio said:

    Yes, call me impatient, but I'm excited to find out what changes are coming in Spamcop 5.0.  Anybody have any release notes yet or probably not until tomorrow?

    and six hours after my post:

    Drum Roll 🥁

    SpamCop v 5.0.0 © 2019 Cisco Systems, Inc. All rights reserved.

    and better:

    Gmail's fess-up with IPv6 6to4 WORKS!!!! 🤩

    no release notes (yet) but at least some good news !!!

×