Jump to content

A.J.Mechelynck

Membera
  • Content count

    227
  • 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

587 profile views
  1. 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.
  2. 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.
  3. A.J.Mechelynck

    No unique hostname found for source

    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.
  4. A.J.Mechelynck

    ipv6 still unsupported?

    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.
  5. A.J.Mechelynck

    ipv6 still unsupported?

    P.S. Anyway, like Miss Betsy used to say, fighting spam is like busting molehills, it's a never-ending battle. Best regards, Tony.
  6. A.J.Mechelynck

    ipv6 still unsupported?

    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.
  7. A.J.Mechelynck

    ipv6 still unsupported?

    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?
  8. A.J.Mechelynck

    ipv6 still unsupported?

    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.
  9. A.J.Mechelynck

    ipv6 still unsupported?

    Well, then, "if there is a bogus-IPv6 X-Received line", etc.
  10. A.J.Mechelynck

    ipv6 still unsupported?

    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.
  11. A.J.Mechelynck

    ipv6 still unsupported?

    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.
  12. A.J.Mechelynck

    ipv6 still unsupported?

    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.
  13. A.J.Mechelynck

    ipv6 still unsupported?

    I still have that spam somewhere on my HD. I suppose that cutting away that first 10.x.x.x Received-line and what follows it (including the ipv6 X-Received line) until, but not including, the next Received-line, which says (as the parser displays it) might let SpamCop parse the email; but OTOH "tampering" with spam in that kind of way is supposed to be frowned upon, to say the least; so I wonder what I could do, if anything. Best regards, Tony.
  14. A.J.Mechelynck

    No unique hostname found for source

    See also
  15. A.J.Mechelynck

    ipv6 still unsupported?

    P.S. This seems related to the following topic:
×