On 10/17/2013 2:09 PM, Jonas Eckerman wrote: > I answer privately since this really isn't about SpamAssassin any more, and > SpamAssassin isn't about RFC conformance.
Oh, but it does directly relate to the above two rules. And I believe this is a healthy discussion. It will educate others as to exactly why these rules break when analyzing some list mail, lists which are the backbone of the FLOSS community. Before now the maintainers were making decisions about applying these rules to list mail based solely on statistics. This discussion has fleshed out the 'why'. The resulting knowledge may be helpful in writing better, more intelligent rules in the future. So I hope it's ok with you that I'm copying this back to the list. >>> In what way are they forged? > >> Do you honestly not get it, or are you being a troll or pedant? > > I honestly didn't get it, and I'm not a troll. Whether I'm a pedant or not > would be a matter of opinion (where you're free to hold one different from > mine). I hope I didn't sound accusatory here Jonas. I've been around the 'interwebs' long enough to know that now and then people try to suck you into an argument over minutia for the sake of arguing. I thought there was a chance that was the case here, so I simply asked. >> Or, if you simply re-read my msg maybe it will become clear. > > I've re-read the message. I can see that I might have quoted badly (I read > and replied with my mobile phone, which I know think was a bad idea), and I > apologize for that. No problem. > It still seems that you're saying the received headers are forged when they > were inserted for transfers not involving SMTP though, even if you also > pointed to other errors in the headers in question. Only one that is claimed to be "esmtp" is forged. That's the 2nd header. The first is not, as it clearly stated "local" injection. That's the PHP end of it. >> To create a record apparently in case of abuse, Gmane in particular injects >> the rDNS string of the HTTP client machine into the EHLO position of a >> Received: header, using the bare IP upon NXDOMAIN or SERVFAIL. > > I see two problems with calling that a forgery: Yeah, scratch that. I painted with an overly broad brush in my first post. Only the 2nd header is the problem, the first is fine. > 1: The idea of a EHLO position is only relevant for protocols with a EHLO > command. When the message is received using HTTP, NNTP, UUCP, local pipes, > etc, there is no EHLO command. Of course. > 2: The Received headers have not always been as strictly defined as one might > wish. Absolutely agreed. Not all MTAs use the same Received: header format. But I assume this was taken into account in these two tests. I've not actually looked at the regexes yet. > Even now putting in the EHLO parameter is a SHOULD, not a MUST, for SMTP. Thankfully most serious MTA writers treat these directives the same. > On to the first set of received headers, I'm commenting the first (in > insertion order) two headers. > >> Received: from stan by mo-65-41-216-221.sta.embarqhsd.net with local (Gmexim >> 0.1 (Debian)) >> id 1AlnuQ-0007hv-00 >> for <debian-u...@lists.debian.org>; Tue, 15 Oct 2013 09:40:02 +0200 > > Was mo-65-41-216-221.sta.embarqhsd.net your RDNS when posting that? If it was > I agree that this header is a forgery. If, oth, > mo-65-41-216-221.sta.embarqhsd.net really was the machine receiving a locally > submitted message (possibly from a PHP script) from "stan" (wich I'd guess is > a user name since that is common to put in that position for locally > submitted mesages), it seems just fine. Yes. This is my PC's FCrDNS. This injection stamping is warranted, and wanted by receivers, and is clearly stated as 'local' injection. This is a good thing, absolutely. >> Received: from mo-65-41-216-221.sta.embarqhsd.net ([65.41.216.221]) >> by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) >> id 1AlnuQ-0007hv-00 >> for <debian-u...@lists.debian.org>; Tue, 15 Oct 2013 09:40:02 +0200 > > If the previous header was correctly listing it's own address in the "by" > clause, this seems just fine. If the address, > mo-65-41-216-221.sta.embarqhsd.net, was actually your address, this header is > of course incorrect as well. Yes, this is the one that is forged. There was no ESMTP transaction between 65.41.216.221, my PC, and main.gmane.org, as this header above clearly states there was. Maybe "fabricated" or "manufactured" is a better word. They're not pretending it to be something it is not, but merely creating it out of thin air. Whether Gmane is violating RFC or not isn't my concern. What is my concern is that the way they create these headers is breaking the two rules in the subject line. Apparently a fix is already in place to prevent these two rules from being applied to list mail. Now that the exact nature of the problem is known, maybe the test can be modified to work with some list mail, but not this particular 'flavor'. > If mo-65-41-216-221.sta.embarqhsd.net was your address, a combination of the > two icnorrect headers could become one correct one header... Getting Gmane to change their headers isn't the goal here. Changing the SA tests to deal with it, is, I think, a reasonable goal. > Maybe I got it right now, maybe not. I think you were close. :) -- Stan
