Jump to content

RobiBue

Membera
  • Content Count

    196
  • Joined

  • Last visited

Everything posted by RobiBue

  1. The address is in the parsed email. Clicking on the link below the headers “View entire message” will reveal a base64 block which can be decoded with online tools like: https://www.base64decode.org/ Just paste the whole block (including the last = sign) and vióla! The entire body of the spam including those seemingly obfuscated addresses... 148. 253. 73. 95ashlee . org . perske . club / 204 / 3-2-2019-clickersin ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | domain TLD | | •————————————————————————• •————————————• subdomains paths But they aren’t really obfuscated addresses. They are real, the way they are written.
  2. I am thinking that spamcop has disabled the parsing of links in the newest update. Not sure about it though, but I haven't had any links parsed by SC since then.
  3. Cache refresh disabled to avoid rate-limiting of whois servers [refresh cache] $ whois NET-3-128-0-0-1@whois.arin.net [whois.arin.net] ERROR 503: Unable to service request due to high volume. hmmm interesting.... in the end, although it would go to /dev/nul for amazonaws, it can't find an owner now... No reporting addresses found for 3.208.7.29, using devnull for tracking.
  4. that, as far as I know, is no longer needed to be done since the SC v5 update. The gmail problem was solved with the update. Outlook (hotmail, et.al.) is still not fixed though, but that is definitely on their end...
  5. Oooh! This last part means that RIPE is blocking ironport/SpamCop/Cisco from accessing their Whois database... now that’s bad.
  6. RobiBue

    Any point in reporting spam from AMAZONAWS?

    yeah, pretty sure there's money involved. if someone complains they'll probably slap them on their wrist... if too many complain, they'll probably close the account, but the spamvertiser can easily open a new account and start anew...
  7. RobiBue

    Spamcop forum doesn't use HTTPS?

    First, why https for the forum? There is nothing going on that needs extra encryption overhead. At least not that I know of. Besides, https doesn't necessarily mean secure: Heartbleed vulnerability? Second, unless it's bank or credit card related, I hate every place that requires me to have a 2-step verification. Google or otherwise. Besides, even a place that has 2-step verification can get hacked and the information stolen... google plus rings a bell... oh, right, google authentication... While the spamposts are annoying if you are up before Lking, they are easy to spot and overlook (or just mark them as read - I also mark them as spam while I'm at it)
  8. RobiBue

    "No body text provided" with Bcc: header

    As I mentioned in my previous message, I did a test between Yahoo! and GMail with Bcc: header test. Here the "munged" but true header results: Outgoing test message with Bcc: from Yahoo!: ------------------------------------------- Date: Thu, 21 Feb 2019 15:57:40 +0000 (UTC) From: RobiBue <MyFakeYahooAccount@yahoo.com> Bcc: "RobiBue" <MyFakeGMailAccount@gmail.com> Message-ID: <1883948137.3003972.1550764660065@mail.yahoo.com> Subject: test with Bcc: address MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3003971_1789674874.1550764660064" References: <1883948137.3003972.1550764660065.ref@mail.yahoo.com> X-Mailer: WebService/1.1.13123 YMailNorrin Mozilla/5.0 (Windows NT 6.1; WOW64; rv:67.0) Gecko/20100101 Firefox/67.0 Content-Length: 505 The above outgoing message (in the sent folder) shows that the Bcc: was there when it left the Yahoo! mailbox. Next comes the GMail inbox part: incoming test message in GMail (removed arc seal and other long winding headers in the middle): ----------------------------------------------------------------------------------------------- Delivered-To: MyFakeGMailAccount@gmail.com Received: by 2002:a0c:9de7:0:0:0:0:0 with SMTP id p39csp979189qvf; Thu, 21 Feb 2019 07:57:44 -0800 (PST) X-Google-Smtp-Source: AHgI3IZpr/3XS19bX4AwkcuhfNfYJk7Gk3+ZDjldlb8JVrbDaiU3jh2zVZyJNu8Lr6TtSb9PrFN8 X-Received: by 2002:a37:a407:: with SMTP id n7mr27806250qke.46.1550764664718; Thu, 21 Feb 2019 07:57:44 -0800 (PST) Return-Path: <MyFakeYahooAccount@yahoo.com> Received: from sonic312-20.consmr.mail.bf2.yahoo.com (sonic312-20.consmr.mail.bf2.yahoo.com. [74.6.128.82]) by mx.google.com with ESMTPS id p1si2743950qtp.365.2019.02.21.07.57.44 for <MyFakeGMailAccount@gmail.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 07:57:44 -0800 (PST) Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Thu, 21 Feb 2019 15:57:44 +0000 Date: Thu, 21 Feb 2019 15:57:40 +0000 (UTC) From: RobiBue <MyFakeYahooAccount@yahoo.com> Message-ID: <1883948137.3003972.1550764660065@mail.yahoo.com> Subject: test with Bcc: address MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3003971_1789674874.1550764660064" References: <1883948137.3003972.1550764660065.ref@mail.yahoo.com> X-Mailer: WebService/1.1.13123 YMailNorrin Mozilla/5.0 (Windows NT 6.1; WOW64; rv:67.0) Gecko/20100101 Firefox/67.0 Content-Length: 505 As you can see, the Bcc: seen in the outgoing message was dropped, as it is not expected nor needed. Next, I reply (with Bcc:) to the above message (keep in mind that I am only showing the headers to keep it concise: outgoing reply to test message from GMail: ------------------------------------------ MIME-Version: 1.0 Received: by 2002:a0c:acd6:0:0:0:0:0 with HTTP; Thu, 21 Feb 2019 08:00:49 -0800 (PST) Bcc: RobiBue <MyFakeYahooAccount@yahoo.com> In-Reply-To: <1883948137.3003972.1550764660065@mail.yahoo.com> References: <1883948137.3003972.1550764660065.ref@mail.yahoo.com> <1883948137.3003972.1550764660065@mail.yahoo.com> Date: Thu, 21 Feb 2019 10:00:49 -0600 Delivered-To: MyFakeGMailAccount@gmail.com Message-ID: <CABr3MG+L8J5N2tp5bWir+PyrYOeo5aJs=XsfDeKqROayovyTRQ@mail.gmail.com> Subject: Re: test with Bcc: address From: RobiBue <MyFakeGMailAccount@gmail.com> To: undisclosed-recipients:; Content-Type: text/plain; charset="UTF-8" and Yahoo! receives the following: incoming reply from GMail in Yahoo!: ------------------------------------ X-Apparently-To: MyFakeYahooAccount@yahoo.com; Thu, 21 Feb 2019 16:00:51 +0000 Return-Path: <MyFakeGMailAccount@gmail.com> Received-SPF: pass (domain of gmail.com designates 209.85.160.178 as permitted sender) X-Originating-IP: [209.85.160.178] Authentication-Results: mta4039.mail.bf1.yahoo.com header.i=@gmail.com; header.s=20161025; dkim=pass (ok) Received: from 127.0.0.1 (EHLO mail-qt1-f178.google.com) (209.85.160.178) by mta4039.mail.bf1.yahoo.com with SMTPS; Thu, 21 Feb 2019 16:00:50 +0000 Received: by mail-qt1-f178.google.com with SMTP id z25so10287996qti.13 for <MyFakeYahooAccount@yahoo.com>; Thu, 21 Feb 2019 08:00:50 -0800 (PST) X-Received: by 2002:ac8:2bc1:: with SMTP id n1mr31583604qtn.176.1550764849978; Thu, 21 Feb 2019 08:00:49 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a0c:acd6:0:0:0:0:0 with HTTP; Thu, 21 Feb 2019 08:00:49 -0800 (PST) In-Reply-To: <1883948137.3003972.1550764660065@mail.yahoo.com> References: <1883948137.3003972.1550764660065.ref@mail.yahoo.com> <1883948137.3003972.1550764660065@mail.yahoo.com> From: RobiBue <MyFakeGMailAccount@gmail.com> Date: Thu, 21 Feb 2019 10:00:49 -0600 Message-ID: <CABr3MG+L8J5N2tp5bWir+PyrYOeo5aJs=XsfDeKqROayovyTRQ@mail.gmail.com> Subject: Re: test with Bcc: address To: undisclosed-recipients:; Content-Type: text/plain; charset="UTF-8" Bcc: MyFakeYahooAccount@yahoo.com Content-Length: 82 As you can see, Google leaves the Bcc: in the headers (although I didn't test it, but I believe if I had more bcc addresses there, only the end recipient getting the message would be listed alone) I do note, that if the Content-Length: header wouldn't have been added, the Bcc: line would have been at the bottom and with it, SC would have trimmed the body off, but it's there, and SC parses it for me. To recap: if you have a Bcc: cutting off the body in SC, remove the Bcc: as it's not needed anyway and nobody expects it to be there anyway.
  9. RobiBue

    "No body text provided" with Bcc: header

    while I admit, that the "test" message gets the message body stripped if the Bcc: header line is the last one, I do have a question: Is there an email software that actually does send/receive the Bcc: header as the last line? I tried gmail and yahoo. sending from yahoo to gmail, the bcc header was not the last header line and it works. Sending from yahoo to gmail, the bcc header got removed, so it worked as well. While I understand that there is a problem with the parser, and believe me, it's by far not the only one, the workaround is to remove the bcc header before submitting. Since bcc headers are not expected to appear in headers according to rfc2822, it doesn't matter if the spam is reported without it anyway.
  10. RobiBue

    "No body text provided" with Bcc: header

    Please forgive my ignorance here, but I've never seen receiving headers with bcc in them... afaik they get stripped by the sending mail host and never shown to any recepient. ok, after reading rfc2822 section 3.6.3, I stand corrected that there might be mail software that includes a bcc: header to the recipient. BUT after running a test with case 2 but using a "validly formed" email address, it parses correctly for me... https://www.spamcop.net/sc?id=z6523542341z5a77154fb65b822d44a3e26a007ad52dz
  11. the SC forum software inserts the underscore to prevent spamers/scammers/hackers to run <java s c r i p t> either remotely or locally on the servers or the hosts. it's a security feature
  12. I've had some of those, but when I go to the past reports history, I see: Submitted: 2/8/2019, 8:19:08 PM -0600: Notice: Please verify your address "x" zoid_binding: sp1_ms2_120 No reports filed and of course, I have deleted the spam already... so, even if I wanted to, I couldn't, as SC doesn't let me, if you know what I mean...
  13. RobiBue

    SC parser: average reporting time

    psst 🤫 it's known to be faulty, and has been for ages 🙄 (see this reply ) I just look at it and say "cool" and move on
  14. 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
  15. 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. 🔭🔍🔬
  16. 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.
  17. 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...
  18. 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...
  19. refresh/show shows the right address now sometimes (I learned this just recently) you have to hit the refresh/show link to refresh the cache...
  20. 👍sounds good, would have sent it to both addresses myself I do get these spams with the fake received line "s.okazik.pl" a lot. Looks like whoever wrote the spamming software is using it as something like a signature, as lots of fake "unsubscribe me" and "you have been successfully subscribed" spam contains that line.
  21. 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.
  22. 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
  23. 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
  24. yeah, unfortunately, for Outlook/Hotmail (M$) users, that step is still necessary due to their internal mismatched handoffs just a heads up...
  25. G'day Chris, 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 )
×