Jump to content

A.J.Mechelynck

Membera
  • Content Count

    240
  • Joined

  • Last visited

Community Reputation

0 Neutral

About A.J.Mechelynck

  • Rank
    Advanced Member
  • Birthday 01/25/1951

Contact Methods

  • Website URL
    http://users.skynet.be/antoine.mechelynck/
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Schaerbeek (near Brussels, Belgium)
  • Interests
    Homo sum, et humani nihil a me alienum puto. (I'm human, and I don't regard anything human as foreign to me.)

Recent Profile Visitors

717 profile views
  1. spam filtering jargon or internal handoff, be that as it may; in any case that line holds no more spam-tracking information than any (let's say) 10.20.30.40 IPv4 Received-line. The parser skips the latter, IMHO it ought likewise to skip the equivalent 2002:a14:1e28:: Or is Google really a black-hat ISP, trying all possible ways (and at times succeeding) to thwart SpamCop and let spammers have the run of the town? Best regards, Tony.
  2. 2002:ab0:11d9:0:0:0:0:0 does not "belong" to Google: it is a 6to4 translation of a non-routable IPv4 address. Any IPv6 address whose first 16-bit word is 2002: is an IPv6 translation of an IPv4 address. Which IPv4 address? That can be found by translating, byte by byte, the next two words from hex to decimal: in the present case, if I fill in the high-order zero, 0a b0 and 11 d9, or in decimal 10.176.17.217 — which also, like any IPv4 address in the 10.0.0.0/8 block, belongs to nobody, or to anybody but only for internal use inside a private network but not as an address where something will be sent over the open Internet. See for instance https://en.wikipedia.org/wiki/6to4#Address_block_allocation
  3. Hm, it's true Gmail diagnoses these notifications as "spam" (and sends them to my spam webmail folder), but that 2002:axx: etc. header which throws SC off-balance comes from Gmail, not from a spammer. So I hope that (when they get around to it) the SC programmer(s) will have the parser skip that header for an "internal, non routable" IP address. Best regards, Tony.
  4. https://www.spamcop.net/sc?id=z6464697204z2165e89310576216d31304dd9309724ez for the notification about your newer post quoted above. Or you can see the full message (headers & body) at http://users.skynet.be/antoine.mechelynck/other/SC_notification.eml N.B. I'm moving tomorrow, and the phone line will only be reconnected Thursday at my new address, so I may be AFK for ½ week starting tomorrow morning. Best regards, Tony.
  5. Do your non-spam email have a Received line at that place (i.e. 2nd header from top)? If they do, I would think that line isn't spoofed. — Oh, and BTW, the notification email I got about your latest post had the following line there (2nd header, topmost Received-line, imediately below the "Delivered-To" line): Received: by 2002:adf:aa91:0:0:0:0:0 with SMTP id h17-v6csp2888495wrc; Sat, 12 May 2018 18:21:24 -0700 (PDT) So, what do you think? Are SC forum notification email messages "spoofed" with a spammy Received-line? I wouldn't think so.
  6. I'm not convinced that it's spoofed by spamware: remember, routers add their Received-line before anything already present, so a topmost Received-line could only have been spoofed by spamware if said spamware were intercepting incoming mail at the client sites (i.e. both mine and yours), or outgoing mail being sent from gmail to its clients. IMHO that line with some address in the IPv6 2002:a00::/24 range, just like the equivalent Received-lines in the IPv4 10.0.0.0/8 range, means that the message was passed from one router to another at Google's. Experiment shows that removing only the Received line with 2002:axx: etc. (including any continuation lines) makes the parse succeed. Then I paste it back as part of the "user comments".
  7. The 2002:a17:90a:b016:0:0:0:0 IPv6 address in your top Received line is a 6to4 address for 10.23.9.10, and that's what SC converts it to when I paste the naked IPv6 address into the reporting page. Now IIRC all addresses in 10.0.0.0/8 are non-routable so I suppose that that Received line is for an internal handoff and IMHO it should be skipped by the parser as "internal handoff or trivial forgery". Similarly for all addresses in 2002:a00::/24 which are in the same category. Best regards, Tony.
  8. That thread I read, though maybe not post by post from A to Z: that's where I got the idea of snipping away the 2 headers between "Delivered-To" and "X-Received" exclusive (see earlier up). Recently there was a problem with IPv6 (or, it seems, the IPv6 side of 6to4) X-Received lines (see "IPv6 still unsupported?" ) but that went away after some time. I hope (and I believe) that SC programmers will fix the present problem like they did the earlier one.
  9. No luck looking for both "gmail" and "resent" in the subject. Do you mean resend (send again) or recent (latest)? Or do you have a topic URL?
  10. P.P.S. https://www.spamcop.net/sc?id=z6464487608z235a710f4a3681c5c236b5073b8b8ab0z
  11. P.S. Looks to me like Google is adding IPv6 mailhosts by the boatload and SC is having a hard time keeping up. Best regards, Tony.
  12. Applying an idea from next topic (No source address found, cannot proceed), I tried to snip away as little as possible (to paste it back in a user comment). I kept the "Delivered-To" line, the "X-Received" line, and removed the two headers in-between ("Received" and "Google-Smtp-Source"). Then it parsed. Best regards, Tony.
  13. See spamcop parse result https://www.spamcop.net/sc?id=z6464480599z64a33ffd866670e22830aad1a6dd529fz parsing a mail I got (AFAIK) from gmail. The topmost Received line says: Received: by 2002:adf:aa91:0:0:0:0:0 with SMTP id h17-v6csp1171932wrc; Fri, 11 May 2018 10:04:10 -0700 (PDT) but SC cannot parse that, it says: host 2002:adf:aa91:0:0:0:0:0 (getting name) no name 0: Received: by 2002:adf:aa91:0:0:0:0:0 with SMTP id h17-v6csp1171932wrc; Fri, 11 May 2018 10:04:10 -0700 (PDT) No unique hostname found for source: 2002:adf:aa91:0:0:0:0:0 Possible forgery. Supposed receiving system not associated with any of your mailhosts Will not trust this Received line. 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. Well, the only address where I receive _any_ mail is my @gmail address. How do I reconfigure my _already existing_ mailhost? Should I edit the header and change the mailhost address in it to the equivalent (but more usual) 2002:adf:aa91:: ? Best regards, Tony.
  14. A.J.Mechelynck

    ipv6 still unsupported?

    Since then I've occasionally had spam with IPv6 X-Received lines, and it was never necessary to remove it. I think this particular issue can be declared FIXED. Best regards, Tony.
  15. A.J.Mechelynck

    ipv6 still unsupported?

    The problem seems to be cured < knockonwood target=head /> : my spam reported as https://www.spamcop.net/sc?id=z6452798672z1a3d3ae2090acb11915fdf4075409c55z had an IPv6 X-Received line and it was parsed correctly even with that header in place.
×