Jump to content

RobiBue

Membera
  • Content Count

    168
  • Joined

  • Last visited

Everything posted by RobiBue

  1. Oooh! This last part means that RIPE is blocking ironport/SpamCop/Cisco from accessing their Whois database... now that’s bad.
  2. 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...
  3. 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)
  4. 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.
  5. 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.
  6. 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
  7. 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
  8. 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...
  9. 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
  10. 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
  11. 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. 🔭🔍🔬
  12. 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.
  13. 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...
  14. 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...
  15. 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...
  16. 👍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.
  17. 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.
  18. 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
  19. 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
  20. yeah, unfortunately, for Outlook/Hotmail (M$) users, that step is still necessary due to their internal mismatched handoffs just a heads up...
  21. 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 )
  22. 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...
  23. RobiBue

    spam has eased up in my inbox

    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...
  24. 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.
  25. 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
×