A.J.Mechelynck

Membera
  • Content count

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

448 profile views
  1. 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.
  2. See also
  3. P.S. This seems related to the following topic:
  4. How do I register an ipv6 mailhost? Trying to parse https://www.spamcop.net/sc?id=z6437551039z397c7682b607208ad3137a9ddf74157ez host 2002:a17:902:6881:0:0:0:0 (getting name) no name 0: Received: by 2002:a17:902:6881:: with SMTP id i1-v6mr7121788plk.323.1516767567431; Tue, 23 Jan 2018 20:19:27 -0800 (PST) No unique hostname found for source: 2002:a17:902:6881: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.
  5. I think I have a similar symptom. I tried to configure mailhosts for my account @gmail.com and I accepted the default settings. Then Spamcop told me it had sent me 5 emails, each through a different SMTP server, as follows: alt1.gmail-smtp-in.l.google.com. alt3.gmail-smtp-in.l.google.com. alt4.gmail-smtp-in.l.google.com. alt2.gmail-smtp-in.l.google.com. gmail-smtp-in.l.google.com. in that order. I got the first four in the same sequence, but the last one never reached me. I dutifully pasted each of the ones I got (headers and data, just like when reporting spam) at the link contained in it, so I suppose it is OK. Each time, after submitting the received email, I was told it had been submitted successfully, and to visit the mailhost configuration page to make sure I had configured all my mail accounts (and yes, the only email account I'm still using is the one mentioned in the rolldown on that configuration page).
  6. :-( Miss Betsy some time ago, and now Ellen. I only saw Ellen's obituary on SC frontpage today, having been AFK for two days. «Prayer should be done in secret» but the loss of a loved one, or just of someone held in high esteem, make us seek the company of common friends. I shan't ever forget you.
  7. I got your three answers by email notification, no worry; and I seem to have been in a bad mood when I saw your former answer and lock, but that is over and done with :-) Sorry I didn't reply faster but I've been busy AFK this week.
  8. Instead of aborting on a Received line lacking a date, couldn't the parser fall back on the date in the Received line above that (the one from the router which received the message from that misconfigured server)? I don't think it likely that all the Received lines (including those from the reporter's mailhosts) would lack a date; I had thought at first to use the Date line as a kind of ultimate fallback, but that line can be "doctored" by the spammer.
  9. Thanks Farelf. When the site's Google search feature told me "about 2,480 results found" (all with some variation of "This email contains no date" as the topic title) I daresay that it was an understatement to say I was baffled.
  10. One more "clever forgery", AFAICT: A Received line before (below) my own ISP says the mail was got "with HTTP" with no date. Here is the tracking URL: http://www.spamcop.net/sc?id=z5984690981z6...e5f197f14e9a5dz I posted it before as a new topic and got rebuffed with "There are already lots of topics on that subject. Go to one of them." Topic closed. Indeed, searching for "email contains date" returns so many threads that I don't know which one to elect. If this one isn't the right one either, please move http://forum.spamcop.net/forums/index.php?...&st=0 to where it belongs rather than just tell me "This isn't the right place! Go away!".
  11. See http://www.spamcop.net/sc?id=z5984690981z6...e5f197f14e9a5dz The parser ends with the error: This email contains no date and aborts. I see dates, both in a "Date:" header and as part of the "Received:" headers. So is this a new parser bug, or have spammers found a new way to get around SC reporting?
  12. lisati: You're right no one size fits all. When my ISP gets a message for me that its filters regard as spam, it's down the trash, up in smoke, never-never land for the message, not even a warning for me. No idea how many genuine (and sometimes important) messages have thus been killed because they were false positives. False negatives I can live with (especially if they come within reach of Bayesian filters — my own mail client's or the server's — which I can “trainâ€), but I absolutely want a way to retrieve false positives, no matter how spammy they might seem for the cybernetic eyes of the mail server's filters. That's why I prefer servers like Google (and, apparently, Yahoo) where "assumed spam" messages are only diverted to a spam folder on their webmail site (instead of forwarded to their POP server) and not dropped into the black hole, so I can at least have a look at them before they are discarded. This way false positives are only delayed by the time it takes me to return to their spam folder, not lost forever.
  13. I just reported one Yahoo spam message a few minutes ago, after getting "500 Internal Server Error, please wait for some time and retry" a few times. Pessimistic hypothesis: I've just been lucky to get a message whose Received line was already in the YahooMain list of mailhost servers. Optimistic hypothesis: the Internal Server Error was because of a software overhaul, and the parser can now puzzle out the new Yahoo headers. Time will tell. ;-)
  14. I get a few spam from my Yahoo account and a few false negatives from my Gmail account, but most of the spam I get is from my ISP (belgacom.net/skynet.be) account, and for a very simple reason: unlike Gmail, they drop "suspected spam" to the blackhole bitbucket, so I cannot rescue false positives: therefore on that account I have disabled server-side spam filtering. All in all this new Yahoo problem is to me only a small nuisance. I suppose Yahoo will have to be "special-cased" in the parser but AFAIK it'll work when it'll work. In the meantime, I suppose Yahoo spam (just like IPv6 spam IIUC) will have to be left aside. Don (and others), let's hope you find how to fix the bug. ;-)
  15. yeah, me too, for a new message: http://www.spamcop.net/sc?id=z5893888384ze...10a064749fae8az I guess there is now a new loophole for spammers: "Send from Yahoo, it won't be reported". Well, let's hope Don and the Yahoo engineers find a solution. In the meantime, is it any use reporting tracking URLs for Yahoo spam here, or should we just dump them down the trash? Here are the Received lines in that spam: Received: from 188.125.68.154 (188.125.68.154) by 188.125.85.148(188.125.85.148); Sun, 25 May 2014 16:08:35 +0000 Received: from 127.0.0.1 (HELO smelektronik.de) (EHLO mta1051.mail.ir2.yahoo.com) (190.100.82.179) by mta1051.mail.ir2.yahoo.com with SMTP; Sun, 25 May 2014 16:08:35 +0000 The topmost (most recent) one seems to be Yahoo-to-Yahoo but not from something known by SC as "YahooMain" (though 188.125.84.186, which comes close, is known). The other (earlier) one seems to come from 127.0.0.1 which is not routable. There are no other Received lines but two lines above them there is X-Originating-IP: [190.100.82.179] which might be the point where the spam entered the net via HTTP webmail. It resolves to something to be reported to italo.sambuceti[at]vtr.cl which is definitely not Yahoo. The same IP appears (with no brackets) even higher in the headers, namely in the "X-YahooFilteredBulk" and "Received-SPF" headers. After writing all this, I finally notice that that entry point is staring me in the face at the very end of the second Received line.