Jump to content

RobiBue

Membera
  • Content Count

    252
  • Joined

  • Last visited

Everything posted by RobiBue

  1. Ever wanted to follow the http or https headers but not visit potentially dangerous websites? here I found a perfect toy: https://www.webconfs.com/http-header-check.php for example, today I received a sex-spamvertised email (no need to post the tracking URL, as here I'm only interested in the redirects that the spammer goes through) so in the spam I have the following html line (without the spaces, so that nobody damages their computer by following the link): <a href="https: //bit.ly/ 2IQVHa2"> I enter the address in the text box, and receive the following result: HTTP/1.1 301 Moved Permanently => Server => nginx Date => Wed, 06 Mar 2019 05:00:02 GMT Content-Type => text/html; charset=utf-8 Content-Length => 139 Connection => close Cache-Control => private, max-age=90 Content-Security-Policy => referrer always; Location => http: //trk.linoaura.com/ c/ 1a57c646b0bf375e?src=issam Referrer-Policy => unsafe-url Set-Cookie => _bit=j26502-4d7f647156d7ea24c4-00y; Domain=bit.ly; Expires=Mon, 02 Sep 2019 05:00:02 GMT oh, Referrer-Policy => unsafe-url !!! (again, the location with spaces to prevent someone to inadvertently follow the link) so I enter that Location => link into the box and get: HTTP/1.1 302 Found => Server => nginx Date => Wed, 06 Mar 2019 05:05:45 GMT Content-Type => text/html; charset=UTF-8 Content-Length => 0 Connection => close Location => https: //lintwor.com /198f1cdb040fb11800 //aijxs5c7f55298ff4e752045131/ Set-Cookie => tid=aijxs5c7f55298ff4e752045131; path=/; HttpOnly Status => 302 Found yet another redirect (I again added spaces) so I follow that one: HTTP/1.1 200 OK => Date => Wed, 06 Mar 2019 05:08:39 GMT Content-Type => text/html; charset=UTF-8 Content-Length => 133 Connection => close Server => Apache Set-Cookie => uid9599=814165625-20190305230839-05d567ed43eab684d1ec95bd5d3f4aff-; expires=Sat, 06-Apr-2019 04:08:39 GMT; Max-Age=2674800; path=/ end station HTTP/1.1 200 OK => so all I need to do now, is get the IP for the last domain with netDemon, SamSpade, or just a simple ping from the cmd line, and send manual complaints with my specific anti-spam email to abuse[at]name.com (since they are the registrar for the domain) and nforce.com: who is the administrative IP block owner of spamvertised IP address as well as knownsrv.com: who is the owner of IP block of spamvertised IP address the latter two found in the RIPE db with the IP address from the ping.
  2. RobiBue

    http/https header check

    Hi MIG, with re to the first q, no, it wasn’t then. It is now, though, but bit.ly already removed their link shortcut, so the original spam link wouldn’t work anyway. i do have the feeling, hat my complaint to name.com, nforce and knownsrv was fruitful since the spammer had to change their link redirect to your latter q: Let’s start with sc on lintwor.com: https://www.spamcop.net/sc?track=lintwor.com there i get both, IP address and reporting/abuse address. now i’m Not done, as I want to make sure that I don’t just email the spammer, so I look up the ripe.net db: https://apps.db.ripe.net/db-web-ui/#/query?searchtext=194.145.208.166%23resultsSection gives me more or less the same info, but at the end of the page, I see MNT-NFORCE entry, so I check there https://apps.db.ripe.net/db-web-ui/#/lookup?source=RIPE&key=MNT-NFORCE&type=mntner and in the end decide also to contact the admin-c entry listed. that’s how I got name.com, knownsrv and nforce And as you can see by the absence of the last redirect the way I had it at the beginning, something worked
  3. if you click on the top [Report spam] "tab" it should reload the page without the current spam, just the empty report box but possibly with the following : is the Remove all unreported spam link missing, but the Report Now link there?
  4. I hear you MisterBill, and I understand the frustration when the fight with spammers is being hindered by the own tools that are supposed to help. I used to be adamant with regard to submitting the links, but eventually I realized that, even though most links are spammer's own links or redirects to them, or even redirects to redirects... and so on and so forth... some links are third party links that a) have nothing to do with the spam, or b) are being used as retaliatory measures to get them in trouble. why this spam isn't parsing the links, unfortunately, I do not know. entering the address directly into the SC parser works and gives you the abuse address if you want to submit it manually. https://www.spamcop.net/sc?track=http://148.253.73.95ashlee.org.perske.club/204/3-2-2019-clickersin
  5. 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.
  6. 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.
  7. 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.
  8. 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...
  9. Oooh! This last part means that RIPE is blocking ironport/SpamCop/Cisco from accessing their Whois database... now that’s bad.
  10. 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...
  11. 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)
  12. 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.
  13. 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.
  14. 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
  15. 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
  16. 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...
  17. 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
  18. 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
  19. 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. 🔭🔍🔬
  20. 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.
  21. 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...
  22. 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...
  23. 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...
  24. 👍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.
  25. 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.
×