Jump to content

RobiBue

Membera
  • Content Count

    243
  • Joined

  • Last visited

Posts posted by RobiBue


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


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

     


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

     


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


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


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


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


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


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


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


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

     


  12. 1 hour ago, petzl said:

    abuse[AT]steadfast.net.

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

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

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

    which in turn returns Related organization's POC records.

     

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

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

    and you have the aforementioned abuse email address ;)

     


  13. G'day Chris,

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

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

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

    You can save/skip that step entirely.

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


  14. 9 hours ago, Lking said:

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

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

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


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


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

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

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

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

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

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


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


  18. 5 hours ago, MIG said:

    Hello Lking, thanks for replying:).

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

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

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

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

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

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

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

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

    That said/vented, see my latest post here:

     

×