Jelmer Jellema

O that would be great! I'll try it out today.

I agree. There is now enough information in the form of positive and negative examples for Spamcop to fix this. The fix probably involves some backslash in a regexp or something like that. Is there anything we can do to speed it up (or fix it)?

I'm afraid I am not looking into that. I just thought I fixed our "parse and report spam" scri_pt to check for the .issue before sending it to spamcop. What we do now: Any received spam (either by us or by trusted clients who can report it to us) is send to spamcop and our "leerspam" parser (learn spam) Spamcop is then handled through the web interface for checking and reporting The leerspam parser will check the attachments and feed them to sa-learn What I want to change (when I have time) Any received spam is send to a new "report spam" parser, as an attachment The "report spam" parser will check the attachments and feed them to sa-learn It will also check the attachments, when needed fix the .issue, and send them to spamcop The essential part of this essay being when I have time, as always. Regards, Jelmer

That's such a warm feeling!

That would be nice!! As I told before, we also send the mails to our own parser, which hands them over to sa-learn. I am looking into a small addon for this scri_pt, which would send the mail to spamcop as well, after checking for and fixing any .domain issues... I'm a bit busy, but will try to do this soon. It can't be more than a few (extra) lines of code. Because of the fact that this parser scri_pt was first built somewhere around 2007, It will be in Perl though. Still going strong 🙂

Even though this .issue appears with mailhosts enabled, I don't think it has anything to do with the dotted entry not being a mailhost. Remove the dot and it parsed fine, even though the host mentioned is not a mailhost of the SC user. So my (quite uninformed, I admit) opinion is that the .issue crashed the code that checks for mailhosts, so the best message would be "error parsing for mailhosts, continuing with mailhosts disabled"... In my opinion as a SC user, I think "manually remove the dot" is no solution. We forward a lot of spam to SC, and cannot manually edit each of them, also because we forward it to SA-learn as well and I am not sure if changing the content of the mail will changes the Bayes detection. Finally: Am I the only one to suspect the .issue is created by spammers to make it impossible for SC to parse the spam? Jelmer

I'm sorry I have not responded earlier, looks like I did not get any notifications, I will look into my forum settings. I apologize for this. Thanks a lot for thinking about this problem. It is good to see something like this is picked up by advanced members to discuss and educate. As I understand correctly everything works fine with mailhosts disabled. I guess we should check our mailhosts anyway, because of recent network changes. So, how should we interpret this? The mailhost check code of SC "crashes" when it tries to parse a host with a dot, - and could be fixed - or The mailhost check code "crashes" when it tries to parse a host with a dot, while the mailhost setup for the particular reporter is out of date (but as I get it, other people, with different mailhosts, experience the same issue), We should not use mailhosts as it crashes stuff I will now first reconfigure our mailhosts, and see what happens. I will keep you posted! Jelmer

We have the same trouble with more and more e-mails. See for example https://www.spamcop.net/sc?id=z6541277205z262b53d0d8f53ad38a6303589a630c33z If I understand this correctly, it is because of the dot in the seconds Received header? Could it be that spammers found a new way to block Spamcop from parsing their mails? We send the spams as an attachment to spamcop, so it would be hard to change each of them manually. Would it be possible to fix the parser in such a way that it won't hickup on messages like this? Cheers, Jelmer