Tesseract

So, I finally got to the bottom of my issue. I was correct that what SpamCop was displaying was not what I sent. But with the help of one of the deputies (thanks Richard!), I discovered that SpamCop was displaying exactly what it received, but that was different to what I sent! The modification was being made in between by one of my outgoing mail servers. I thought I had ruled that out by forwarding the messages to myself and verifying that they were unmodified, but the issue only affected one of the many servers, which happened not to be used in my initial tests. That also explains the seemingly intermittent nature of the problem. Thanks to everyone who helped. I've learned once again never to make assumptions, no matter how unlikely or absurd the alternatives may seem…

I found out from the other end that the hostname being used is prod-sc-www03.spamcop.net, which does not resolve.

Yes, that's exactly what I did. It failed with the error message I quoted in my first post.

I really don't know what you mean by this. All I'm doing is using the straightforward form at https://www.spamcop.net/mcgi?action=mhconf by entering the address I want to register and a name for the provider, and then clicking "Proceed" on the following page in order to send the test email. That worked in the past; now it fails.

I deleted one of my mailhosts in order to re-add it and see if that helps with the "internal IP identified as source" issue. But when I try to re-add, the test message fails to send with the error: 450 4.7.1 : Helo command rejected: Host not found Does anyone know what hostname is used in the HELO command? Whether it's valid or not determines who I need to complain to.

SpamCop doesn't normally modify my headers either, but clearly did in this one case. The message as submitted has these Received headers (email addresses redacted but otherwise unmodified): Received: from braeburn.macports.org (braeburn.macports.org [IPv6:2a01:4f8:211:2c54::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.root.id.au (Postfix) with ESMTPS id 615BA16ECC8 for <x>; Fri, 19 Nov 2021 03:28:00 +1100 (EST) Received: from braeburn.macports.org (localhost.localdomain [127.0.0.1]) by braeburn.macports.org (Postfix) with ESMTP id F2A1F100775; Thu, 18 Nov 2021 16:27:55 +0000 (UTC) Received: from m.transcrow.online (m.transcrow.online [80.208.228.181]) by braeburn.macports.org (Postfix) with ESMTPS id 9D62F100238 for <x>; Thu, 18 Nov 2021 16:27:51 +0000 (UTC) Received: from transcrow.online (::ffff:80.246.31.11 [::ffff:80.246.31.11]) by m.transcrow.online with SMTP; Thu, 18 Nov 2021 15:25:08 -0000

Here's a recent one of mine that had the same problem: https://www.spamcop.net/sc?id=z6730785981zece71ee274804ca8f17de9c61c757879z The Received headers have been modified by SpamCop. The IP address in all of them is listed as [127.0.0.1] and the hostname is listed as localhost, instead of the actual hostnames and IP addresses that were in the message as I submitted it.

It happened again today: https://www.spamcop.net/sc?id=z6645759962zf8698377d1581a4b17606f61a9f5575bz

That could well be it. I remember there was a problem last year where invalid hostnames starting with a dot would break the parser, which was eventually fixed. Hope they can fix this one too.

The analysis by petzl seems correct (braeburn.macports.org is in my mailhosts). I don't know why the parser would fail on this particular message alone, as it doesn't seem significantly different to many others I've reported successfully. I'll contact the deputies as suggested, thanks.

https://www.spamcop.net/sc?id=z6643995729z6c0b835925fc83fc6ac686ba27423c1fz The parsing ends almost as soon as it begins, having only looked at one host. Other recent reports have been OK.

https://www.spamcop.net/sc?id=z6637142364zdc54ead736a47ce567fa990ae31abf26z The actual originating IP seems to be 95.70.49.44, but hop 7 seems to be mis-parsed. It's an internal handoff with no IP address given, and the parser is pulling out part of "Oracle Communications Messaging Server 8.1.0.5.20200312" and treating it as the IP address 8.1.0.5. I'm not sure whether that Received header is RFC-compliant, but this seems problematic either way.

Of course. Just getting it out of the queue so I'm only notified of actual unreported messages.

Good news, this seems to have been fixed (oddly without a change in the SpamCop version.) Now to click through all the saved "unreported" spam from the last few months… 🙂

Yes, the hostname in the Received header is clearly invalid, but given the parser's job, it really needs to not stop working when there's something invalid in a part of the headers that spammers control. This has been broken since at least April. If it's not at least on some internal to-do list by now, I would submit that there's something wrong with the process here.

I don't think there's really anything more to learn from them at this point, as it's the same behaviour documented earlier in the thread with the same type of invalid hostname in the messages. But here are two from today: https://www.spamcop.net/sc?id=z6558374359zf6c6bc297b1bf5ec039668d1d2ea7f81z https://www.spamcop.net/sc?id=z6558374020zba4d5b7c0c1112bc566769c280cda976z

Meanwhile, nearly all the spam that makes it into my inbox is now of this variety.

Sure, here you go: https://www.spamcop.net/sc?id=z6545317828zc1d3eb3c90dba4ddb2914565fe8e6670z https://www.spamcop.net/sc?id=z6545318251ze1faf58f3225047c10340689918d5169z https://www.spamcop.net/sc?id=z6545409098z16a4a69219a64d0a10d0585d38e310dcz Apart from all being variations of the same message, the common factor seems to be an invalid hostname in the "by" field of the final Received line, as noticed earlier in the thread. E.g. .MpZLHMzHGsR6NQ@cpcloud.co.uk (an invalid hostname both for starting with . and for containing @)

I received 3 pieces of spam today that broke SpamCop like this. Here's one: https://www.spamcop.net/sc?id=z6545317169z5c4be98b29b2c765f89119bfce136732z Very irritating, hope it can be fixed soon.