Jump to content

RobiBue

Membera
  • Content Count

    252
  • Joined

  • Last visited

Posts posted by RobiBue


  1. 4 hours ago, Scott_R said:

    FWIW, it's long past when I could have reported the spam, but now I get a "Unreported spam saved" message, but no way to cancel:

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

    if you click on the top [Report spam] "tab"

    171243141_reportspam.png.1d9f1dae71e72a71fd51fdabd96ea421.png

    it should reload the page without the current spam, just the empty report box but possibly with the following :

    575933796_removeunreportedspam.png.0a1bc1c314a2ac3aedeb1df4f7e3d6c9.png

    is the Remove all unreported spam link missing, but the Report Now link there?


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


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


  4. Link removed due to giving out private information.... ? Sc admins? 

    I was wondering if an admin, or someone with the ability to check the SC address entries can see and post here why the amazonAWS address is devnulled.

    When I report manually to abuse amazonaws com I get both sentient and robot replies.

    Can the devnull redirection be removed so that reports go again to their abuse desk?

    They seem to be taking care of their spammers, but only if the spam can be reported...

    I am not sure if abuse reports going to ipmanagement are actually going anywhere. I have seen 3 different abuse addresses listed for amazon aws and ec2, where ipmanagement seems like a fluke that ended up without an abuse address at amazon web services...


  5. 5 hours ago, gnarlymarley said:

    Yeah, I am not sure if there is someone that has the ability to fix these cache entries.  It is a tragedy now that we are here, but at the same time it is at least populating the blacklist.

    Display data:
    "whois 185.79.243.137@whois.arin.net" (Getting contact from whois.arin.net )
       Redirect to ripe
       Display data:
       "whois 185.79.243.137@whois.ripe.net" (Getting contact from whois.ripe.net)
       whois.ripe.net 185.79.243.137 (nothing found)

    
    [whois.ripe.net]
    %ERROR:201: access denied for 184.94.240.92

     

    Oooh! This last part means that RIPE is blocking ironport/SpamCop/Cisco from accessing their Whois database...

    now that’s bad.


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


  7. 14 hours ago, klappa said:

    It's ridiculous why is that? Please add that and Google Authenticate immediately to stop Spamposts while at it.

    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. 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. 50 minutes ago, euphorique said:

    This one has "validly formed" address in bcc: https://www.spamcop.net/sc?id=z6523551992z5978bb9216921fdbce50eebacde4661az

    
    Received: from mbkd0231.ocn.ad.jp (mbkd0231.ocn.ad.jp. [153.149.233.32])
            by mx.google.com with ESMTP id e96si22718016plb.123.2019.02.21.05.54.06;
            Thu, 25 Feb 2019 05:54:07 -0800 (PST)
    From: spammer@spam.com
    To: me@mailinator.com
    Subject: problem with BCC: header
    BCC: spammer@spam.com
    
    Hey! There is a blank line between the headers and the body!
    

     

    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. Please forgive my ignorance here, but

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


  12. 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. 🔭🔍🔬


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


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


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


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


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

     

×