Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by A.J.Mechelynck

  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) 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 — which also, like any IPv4 address in the 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 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, and that's what SC converts it to when I paste the naked IPv6 address into the reporting page. Now IIRC all addresses in 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. 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. 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.
  16. Cowboy Bob: As described in the thread "IPv6 still unsupported?" mentioned a few posts earlier in this thread, when SpamCop fails because the spam had an "X-Received" line with an (unroutable) address in IPv6 format, just cut that line and any continuatuion (i.e. indented) line(s) following it: the parse will then succeed and you can paste the offending line(s) into the user's comment box at the bottom of the parse, perhaps with a title like "The following line had to be snipped to avoid spamcop malfunction:" or something, before you send the reports. We can hope that someday the parser logic will be slightly modified to take care of this automagically, but AFAIK SpamCop maintenance is a low-priority business, so don't put your hopes too high.
  17. Experiment shows that removing only the "X-Received: by 2002: (etc.)" line ("line" in email headers sense of course, i.e. including any indented continuation lines following it) is enough to make SpamCop parse the spam with no error. (Then I paste the removed line back, of course, into the first "user comments" box at the end of the parse page.) Best regards, Tony.
  18. P.S. Anyway, like Miss Betsy used to say, fighting spam is like busting molehills, it's a never-ending battle. Best regards, Tony.
  19. Chinese spam? What Chinese spam? The access providers from which I see a lot of spam at the moment are: 1and1.com amazonaws.com Internal spamcop handling (bt) ovh.net hetzner.de Others come far behind, and they all speak English (though at times broken English, as in "Your parcel might arrived"). Some years ago I used to get a lot of Korean spam but that seems to have totally disappeared.
  20. In the case displayed here, the X-Received line is just as bogus, but it is in IPv4 format, and in this case SpamCop doesn't choke on it. What puzzles gnarlymarley and me is that it's only when that bogus X-Received line is in IPv6 format (a relatively rare case at the moment, in my experience, but of course you never know what tomorrow will bring) that it makes the SpamCop parse end in error. As a "request for enhancement", would it be to much to ask the SpamCop parse engine to bypass non-routable IPv6 addresses like it already bypasses non-routable IPv4 addresses? Or maybe to bypass X-Received lines altogether?
  21. Indeed. Of the spam I get, most have that X-Received: 10.something (i.e. IPv4 unroutable) line, and SpamCop has no problem with them. Now and then, I get one with an X-Received: 2002:something (IPv6 unroutable) and SpamCop can only process those spam messages if I snip away that line (there was one such earlier today but IIRC it was the first one after the one which made me start this thread). I note that two lines above that X-Received line (of either kind) there is a Received line which is always in unroutable IPv4 format. Don't know if relevant. Best regards, Tony.
  22. Well, then, "if there is a bogus-IPv6 X-Received line", etc.
  23. I did just now. That thread was started 2011-02-10 and its last post, dated "Edited 2013-02-13", says that SC version v4.7.0.111 (and higher, I suppose) supports IPv6. Today SC boasts v4.8.7 but I still got problems a few days ago with an email sent to my @gmail.com account and which had, first, a "Received:" line with a 10.x.x.x address, and just below ("earlier") an "X-Received:" line with an IPv6 address. From petzl's experiments, it seems that the spam will be parsed correctly if these two lines, and a few non-"Received:" lines below them, are snipped away before reporting. Yes, yes, but if there is an IPv6 X-Received line near the top of the headers I will still have to snip it away before sending the spam to SC or the parse will fail. I know I can send one or more spam messages to SC together by attaching them to an email to my SC reporting address, but SC will present them to me one by one, each on its own parse page. Of course if I must paste back the snipped lines into the "User comments" box, I have to do it on the right parse page, and for that I have to identify it. In order to avoid pasting the offending lines into the wrong reports page, it seems simpler to me to simply make sure that I have no queued spam left to report, then click "Save to clipboard" on the right side of Google's "Show original" page (after scrolling horizontally if necessary) then paste into the SC reporting page, but "Cut" the offending lines before sending (to avoid a parsing failure) and immediately afterwards paste them back in the first "User comments" box below the paste, possibly prefixed by "[The following lines were snipped from the top headers of the spam to avoid a spamcop malfunction]" or something similar.
  24. Even if I report it by attaching it to an email to my SC reporting address, I would still have to cut those lines away before sending the email and paste them back below the corresponding parse, wouldn't I? In such a case, pasting the rest of the spam on the reporting page and the offending lines almost immediately afterwards below the parse seems less error-prone to me. Best regards, Tony.
  25. Cut away all this stuff from the top of the header part and paste it back into the "user comments" box on the "parse results" page, is that it? Well, if you say so… Best regards, Tony.
  • Create New...