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.