Jump to content

hank

Membera
 View Profile  See their activity

  • Posts

    180

  • Joined

  • Last visited

 Content Type 

Posts posted by hank

    Is this phishing?

    in SpamCop Lounge

    Posted

    Here's the full report:

    X-spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on f.spam.sonic.net
    X-spam-Level:
    X-spam-Status: No, score=-6.1 required=4.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
        DKIM_VALID,RCVD_IN_DNSWL_HI,SNF4SA,SONIC_BX_A2,SPF_HELO_NONE,
        T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=disabled version=3.4.6
    X-spam-SNF-Result: 0 (Standard White Rules)
    X-spam-MessageSniffer-Scan-Result:
    X-spam-MessageSniffer-Rules:
        0-0-0-2429-c
    X-spam-GBUdb-Analysis:  1, 184.94.240.112, Ugly c=0.357145 p=-0.1875 Source
        Normal
    Received: from d.mx.sonic.net (a.spam-proxy.sonic.net [157.131.224.145])
        by b.local-delivery (8.14.7/8.14.7) with ESMTP id 24BHxOUk006899
        (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT)
        for <xxxxxxxx@lds.sonic.net>; Wed, 11 May 2022 10:59:24 -0700
    Received: from vmx.spamcop.net (vmx.spamcop.net [184.94.240.112])
        by d.mx.sonic.net (8.14.7/8.14.7) with ESMTP id 24BHxNqN107202
        (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT)
        for <xxxxxxxx@sonic.net>; Wed, 11 May 2022 10:59:24 -0700
    DomainKey-Signature: s=devnull; d=spamcop.net; c=nofws; q=dns;
      h=IronPort-SDR:X-Corpus-CASE-Score:Received:Received:From:
       To:Subject:Precedence:Message-ID:Date:X-Mailer;
      b=KkvP5aBl9Md+4drBRSvljnJEAe3hevTgrPPG9aq8eJI+L5ZBTpstUh23
       xCa44jj5nnkVlI6Mycnv2MvtKrBozt9G7mb+FJKINxKEGXkUvkQqHKA/E
       ausfD3p8pn5jzDh;
    IronPort-SDR: eXGcifgOTQE0pAsvFRW89f+ynULjxySmlh6vohXzvc95FKXZvT2UqhXWlGW6eQnRD8/5l6/hxy
     ffjnIaPZyO5t2pTyPUZVy6iFQ2gKMn1b3WKibBmx8/sjg18AXCwPdLvbri/XbkdgydvkpxwMro
     JNoJ6l4CUpU4wB0nWH4vOrB9ncxmUUY5h+y5qsRMoRiph+MrelrGRwBuf5VXqHoI7G22uV3DzR
     NFPKK1VEOZus6GuX5AMmSvKACSLyHjJKKLQg12YVKc4zVdHtVBrnp8jrmNwBUTY7x2hrxjVcAC
     ONI=
    X-Corpus-CASE-Score: 0
    Received: from prod-sc-www02.sv4.ironport.com (HELO prod-sc-www02.spamcop.net) ([10.8.129.226])
      by prod-sc-smtp-vip.sv4.ironport.com with SMTP; 11 May 2022 10:58:18 -0700
    Received: from [135.180.216.255] by spamcop.net
        with HTTP; Wed, 11 May 2022 17:58:12 GMT
    From: SpamCop <spamcop@devnull.spamcop.net>
    To: xxxxxxxx@sonic.net
    Subject: [SpamCop] Email Delivery Confirmation
    Precedence: list
    Message-ID: <wh627bf934g75b2@msgid.spamcop.net>
    Date: Wed, 11 May 2022 17:58:12 GMT
    X-Mailer: https://www.spamcop.net/ v5.4.0
    X-Orthrus: tar=0 grey=no co=US os=FreeBSD/9.x or newer/2 spf=pass dkim=pass

    Please confirm email delivery for SpamCop account:
    hank@spamcop.net

    Click here:
    https://www.spamcop.net/mcgi?conf=un6FJSBii5iMUvqCILI1ihJWw8CkUP0o

    Or send email to:
    deliver.un6FJSBii5iMUvqCILI1ihJWw8CkUP0o@cmds.spamcop.net

    sendmail woes

    in SpamCop Reporting Help

    Posted

    How about "mail.spamcop.net" -- shouldn't that be a good address?

    Suddenly my reporting of spam is rejected, password reset doesn't help, ping says it's an unknown host, sometimes, and other times gives very long delays, viz:

    30 packets transmitted, 29 packets received, 3.3% packet loss
    round-trip min/avg/max/stddev = 201.782/228.961/292.230/29.676 ms

    obscuring personal IDs in reports

    in New Feature Request

    Posted

    I know spammers are increasingly hiding addressee names/email in the spam text so automatic reports end up disclosing the info about the reporter and confirming an email address is valid and thus saleable to other spammers.

    Could Spamcop allow each user to specify a few strings that would become XXXX in reports?  That would be one's personal name and email, to find them and wipe them out of the reports.

     

    For a while I was doing that by hand, editing reports --- and that did reduce the amount of followon spam I was getting --- but it's a tedious process at best.

     

     

    [Resolved] Mailhost configuration problem, identified internal IP as source

    in SpamCop Reporting Help

    Posted

    And a reply after I reported it:

     

    Quote

    Thanks.  I looked at the patterns and proactively added a bunch. Hopefully I'm ahead of them 🙂
    Richard

    So, I'm guessing the problem occurs because of mail senders adding new servers -- thinking about how when we set up a mail source we're offered a list of servers to verify, and told we can do one or more of them --- I guess after the fact the sender must  be creating new servers that we don't get a chance to list for Spamcop.

    [Resolved] Mailhost configuration problem, identified internal IP as source

    in SpamCop Reporting Help

    Posted

    It was the familiar "Mailhost configuration problem ...."
    No point requoting the tracking URL link here, as I believe that we have learned that the destination of those links will have changed as soon as Richard of Spamcop fixed the problem.

    He replied to my followup question -- I asked whether there is a way that I could fix these myself.  The answer is no:

    Quote

    Sorry, there really isn't.  When new servers are added or newly discovered, they have to be manually added to the mailhost record.

    And he went on to say
     

    Quote

     I'm not sure what's going on with Apple expansion.

    I guess we're lucky though.  It was a real mess when AOL and Yahoo merged everything, then merged into Verizon.  The MS mess of them merging everything together is going to take them another four years to get everything straight.

     

    So am happy to settle for knowing we have a guardian angel working at Spamcop who can resolve the "Mailhost configuration problem" error messages.

    [Resolved] Mailhost configuration problem, identified internal IP as source

    in SpamCop Reporting Help

    Posted

    Quote

    SCA seem to be able to "fix" everything that can be fixed, however (I'm) reluctant to have them as 1st go to


    This kind of reminds me of asking my first UNIX host's sysop about a problem connecting with my acoustic coupler, vt-100 terminal, and 300 baud modem.
    He replied "that's trivial."

    I inquired further and he explained:  "'Trivial' means not worth my time to fix and you'll never figure it out in a million years."
     

    Lessons in humility, these experiences are.

    [Resolved] Mailhost configuration problem, identified internal IP as source

    in SpamCop Reporting Help

    Posted

    I have no idea what changed. 
    Spamcop's Richard replied to my inquiry, with this:

    Quote

    Thanks.  Added those in.  I really don't like what I'm seeing from Apple with their network setup  ;-(


    The result of whatever he fixed is:
    That extremely long link with the error message used to just loop back to the same reporting page where it appeared, but now it took me to an accepted spam analysis page with the usual button that let me report it.

    So I guess  the lesson here is, when that error pops up, contact Spamcop's support line.

    [Resolved] Mailhost configuration problem, identified internal IP as source

    in SpamCop Reporting Help

    Posted · Edited by hank

    Oh, lord, it's back again:
    ========================
    https://www.spamcop.net/sc?id=z6551699441z220188f8a2c708121149565d782f7ac9z

    Mailhost configuration problem, identified internal IP as source

    Mailhost:
    Please correct this situation - register every email address where you receive spam

    No source IP address found, cannot proceed.

    =======================

    I emailed the Spamcop guy who replied to my last inquiry.  Here's hoping.

    [Resolved] Mailhost configuration problem, identified internal IP as source

    in SpamCop Reporting Help

    Posted

    Quote

    SpamCop always does a fresh parse on every lookup.
    So yes it dissapears on new info has always done this even in the last millennium 

    Well fooey.  Sure makes me look like an idiot to my ISP support folks who were told their headers were broken, and they followed the newly improved links to find no problem.

    So I guess I tell them there's no problem with their mail headers, it was just an artifact of something that the Spamcop support guy found wrong and fixed.  Eh?  Or is there still something wrong needing fixing?

    Well, I'll be back if I get more error messages.

     

    [Resolved] Mailhost configuration problem, identified internal IP as source

    in SpamCop Reporting Help

    Posted · Edited by hank
    disgruntled

    Quote

    SpamCop reparses every time you call it up once fixed problem won't reappear

    I couldn't find it either, and I doggone well know it was there.

    So they made it disappear, eh? 

    Sure makes me look like an idiot to the folks at my ISP who I asked to look into this.

    They ought to insert some warning about the change into the destination page (just as someone inserted "[Resolved]" into the title of the thread, thank you.

    Dagnabbit.  That's not how hypertext was meant to work.    It's terrible when you can't trust an older link to take you to where it was originally intended to go.


    Thanks for figuring out what's been going on with the pointers.

    [Resolved] Mailhost configuration problem, identified internal IP as source

    in SpamCop Reporting Help

    Posted · Edited by hank

    > where did (forums.sonic.net) Ankh get: https://www.spamcop.net/sc?id=z6551256550z0ed85f5a7d03a6f2cbf8b615d226c5f0z from?

    That's from one of the Spamcop bounces I got telling me about the mailhost configuration problem.
    Posted earlier in this thread.

    I haven't had any more of those bounces since Spamcop support found and fixed the mailhost configuration problems, so maybe the headers aren't an issue any more.

    [Resolved] Mailhost configuration problem, identified internal IP as source

    in SpamCop Reporting Help

    Posted

    SOLVED by Spamcop staff, after I sent another bounce to them in email and asked for more help. Problem found and fixed.
    Here is the explanation:
    ==========
    a.local-delivery was in the mailhosts, but b.local-delivery wasn't. At one time that would have been ignored as a local hop, but some of the coding for IPv6 screwed things up so even versions numbers of some things look like IP addresses.
    --
    Richard
    ============

×
×
  • Create New...