Bug#337922: too much aggressive HELO_DYNAMIC_* tests
Hello, This may not have been the wisest choice by the administrator considering the circumstances, but I think it's hard to argue that people should use an HELO string different from the rDNS... Philip Armstrong writes: Quite. If I set it differently to the rDNS then I hit another set of reject rules. Unfortunately, my ISP doesn't currently offer the ability to set my own rDNS to match my personal domain, which is what I'd prefer to do obviously. On Tue, Nov 08, 2005 at 09:52:49AM -0800, Justin Mason wrote: What are those other reject rules? On 08.11.05 19:17, Philip Armstrong wrote: I'm not referring to spamassissin specifically -- I've had mail rejected by smtp servers for both having a address the HELO which didn't match the reverse DNS string and for using a bare IP address. Such servers are breaking the RFCs of course, but it's understandable. actually, server only breaks the RFC if it refuses the mail _just because_ helo string does not match the connecting hostname/IP address. if a server refuses mail because of any other reason, even if it's related to helo string (nonexistent host in HELO/EHLO, bare IP not enclosed in [], IP in blacklist, ...), they don't violate the RFC (unless they violate it elsewhere). The problem here is *not* simply that your rDNS looks dynamic in any way. We in SpamAssassin understand that many ISPs still do that, c'est la vie. The problem, instead, is threefold: 1. that the rDNS string appears symptomatic of a dynamic pool fine for assigning score 2. that you're delivering direct-to-MX fine for rejecting the mail at all 3. that the HELO string matches the dynamic-looking rDNS this is correct behaviour of SMTP clients required by RFC 2821, so it should not be penalized in any way. I much often have problems with machines that do NOT send their hostname (worms, viruses, spamware, etc.) The easiest part to fix is number 3. Change your MTA to use its own name (e.g. mail.yourdomain.com) as the HELO string, instead of whatever rDNS it has been assigned. I don't think this has to be changed in any way. It turns out that my ISP has got around to offering custom rDNS entries, so I suspect I'll be doing that in order to fix this. if the IP is statically allocated, the DNS record should clearly say so. It seems, currently this IP has different record (kantaka.co.uk). I'd like to heas SA maintainers' opinion on my notes above... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337922: too much aggressive HELO_DYNAMIC_* tests
Apparently I'm hitting spamassassin tests :( On Mon, Nov 07, 2005 at 11:41:50PM +0100, Marco d'Itri wrote: On Nov 07, Duncan Findlay [EMAIL PROTECTED] wrote: The SpamAssassin scores are carefully optimized -- I won't change any scores from upstream. What seems more likely is that your Yes, I am arguing that the scores for these two tests are too much aggressive. The message was rejected (even after a -2.3 bonus score!) *only* because it had a generic-looking rDNS hostname also used in the HELO[1]: Received: from dsl-217-155-153-11.zen.co.uk (dsl-217-155-153-11.zen.co.uk [217.155.153.11]) That's a static IP allocation. Check the whois data for 217.155.153.11 It should never *be* triggering any dynamic IP rulesets (in a perfect world). If it does, then the ruleset is broken. (Or my ISP is putting my IP address in the DUL which is possible I suppose -- I've never checked.) This may not have been the wisest choice by the administrator considering the circumstances, but I think it's hard to argue that people should use an HELO string different from the rDNS... Quite. If I set it differently to the rDNS then I hit another set of reject rules. Unfortunately, my ISP doesn't currently offer the ability to set my own rDNS to match my personal domain, which is what I'd prefer to do obviously. If after this you still believe that a 7.7 score is correct then please say so, at least he (who I Cc'ed) will know why in the future all his mail will be rejected by spamassassin. :-) 7.7! Seems extreme for someone who has a static ip address has set the SMTP HELO to match the rDNS for that ip. Given that this is *precisely* what is suggested by the relevant RFCs I'm slightly peeved! Should I prod spamassassin upstream to whinge? cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
Bug#337922: too much aggressive HELO_DYNAMIC_* tests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philip Armstrong writes: This may not have been the wisest choice by the administrator considering the circumstances, but I think it's hard to argue that people should use an HELO string different from the rDNS... Quite. If I set it differently to the rDNS then I hit another set of reject rules. Unfortunately, my ISP doesn't currently offer the ability to set my own rDNS to match my personal domain, which is what I'd prefer to do obviously. What are those other reject rules? The problem here is *not* simply that your rDNS looks dynamic in any way. We in SpamAssassin understand that many ISPs still do that, c'est la vie. The problem, instead, is threefold: 1. that the rDNS string appears symptomatic of a dynamic pool 2. that you're delivering direct-to-MX 3. that the HELO string matches the dynamic-looking rDNS The combination of all 3 has been a very strong spam signature with virtually nonexistent nonspam hits, for over a year. The easiest part to fix is number 3. Change your MTA to use its own name (e.g. mail.yourdomain.com) as the HELO string, instead of whatever rDNS it has been assigned. To the best of my knowledge and experience, using a HELO string that doesn't match rDNS will not cause issues with filtering elsewhere, as it's SOP for many other domains. If after this you still believe that a 7.7 score is correct then please say so, at least he (who I Cc'ed) will know why in the future all his mail will be rejected by spamassassin. :-) 7.7! Seems extreme for someone who has a static ip address has set the SMTP HELO to match the rDNS for that ip. Given that this is *precisely* what is suggested by the relevant RFCs I'm slightly peeved! I'm seeing 4.7 here, nowhere near 7.7. - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Exmh CVS iD8DBQFDcOXxMJF5cimLx9ARAipXAJ9mu7L8z6j9KAPK5+eFMjzixCvpwgCgiA6j n9OkiyHTFXkltKzcHBqO+F0= =WqqW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337922: too much aggressive HELO_DYNAMIC_* tests
On Nov 08, Justin Mason [EMAIL PROTECTED] wrote: Seems extreme for someone who has a static ip address has set the SMTP HELO to match the rDNS for that ip. Given that this is *precisely* what is suggested by the relevant RFCs I'm slightly peeved! I'm seeing 4.7 here, nowhere near 7.7. X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on wonderland.linux.it X-Spam-Level: * X-Spam-Status: Yes, score=5.4 required=5.0 tests=BAYES_00,HELO_DYNAMIC_DHCP, HELO_DYNAMIC_IPADDR autolearn=no version=3.1.0 X-Spam-Report: * 3.8 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 3.9 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * -2.3 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.] -- ciao, Marco signature.asc Description: Digital signature
Bug#337922: too much aggressive HELO_DYNAMIC_* tests
On Tue, Nov 08, 2005 at 09:52:49AM -0800, Justin Mason wrote: Philip Armstrong writes: This may not have been the wisest choice by the administrator considering the circumstances, but I think it's hard to argue that people should use an HELO string different from the rDNS... Quite. If I set it differently to the rDNS then I hit another set of reject rules. Unfortunately, my ISP doesn't currently offer the ability to set my own rDNS to match my personal domain, which is what I'd prefer to do obviously. What are those other reject rules? I'm not referring to spamassissin specifically -- I've had mail rejected by smtp servers for both having a address the HELO which didn't match the reverse DNS string and for using a bare IP address. Such servers are breaking the RFCs of course, but it's understandable. The problem here is *not* simply that your rDNS looks dynamic in any way. We in SpamAssassin understand that many ISPs still do that, c'est la vie. The problem, instead, is threefold: 1. that the rDNS string appears symptomatic of a dynamic pool 2. that you're delivering direct-to-MX 3. that the HELO string matches the dynamic-looking rDNS The combination of all 3 has been a very strong spam signature with virtually nonexistent nonspam hits, for over a year. The easiest part to fix is number 3. Change your MTA to use its own name (e.g. mail.yourdomain.com) as the HELO string, instead of whatever rDNS it has been assigned. To the best of my knowledge and experience, using a HELO string that doesn't match rDNS will not cause issues with filtering elsewhere, as it's SOP for many other domains. I've had mail rejected. I'm seeing 4.7 here, nowhere near 7.7. Still peeved :) It turns out that my ISP has got around to offering custom rDNS entries, so I suspect I'll be doing that in order to fix this. Are the available DUL lists so unreliable that your pattern matching is better? Many ADSL ISPs in this country are using this kind of naming scheme with both static and dynamic IP allocation. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337922: too much aggressive HELO_DYNAMIC_* tests
Package: spamassassin Version: 3.1.0a-1 Severity: important A single generic rDNS in a Received header is enough to raise way too much the score. Also, it appears that this check would be applied even to mail delivered trought an ISP relay. X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on wonderland.linux.it X-Spam-Level: * X-Spam-Status: Yes, score=5.4 required=5.0 tests=BAYES_00,HELO_DYNAMIC_DHCP, HELO_DYNAMIC_IPADDR autolearn=no version=3.1.0 X-Spam-Report: * 3.8 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 3.9 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * -2.3 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.] X-Original-To: ...wonderland.linux.it Delivered-To: ...wonderland.linux.it Received: from attila.bofh.it (localhost [127.0.0.1]) by wonderland.linux.it (Postfix) with ESMTP id 65F211C7C7 for ...wonderland.linux.it; Mon, 7 Nov 2005 10:44:17 +0100 (CET) Received: from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by attila.bofh.it (Postfix) with ESMTP id C099A5F7AA for ...wonderland.linux.it; Mon, 7 Nov 2005 10:44:17 +0100 (CET) Received: from dsl-217-155-153-11.zen.co.uk (dsl-217-155-153-11.zen.co.uk [217.155.153.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by picard.linux.it (Postfix) with ESMTP id 4D32F3F00 for [EMAIL PROTECTED]; Mon, 7 Nov 2005 10:44:16 +0100 (CET) Received: from phil by dsl-217-155-153-11.zen.co.uk with local (Exim 4.54) id 1EZ3Xz-0002SP-MZ for [EMAIL PROTECTED]; Mon, 07 Nov 2005 09:44:15 + -- ciao, Marco signature.asc Description: Digital signature
Bug#337922: too much aggressive HELO_DYNAMIC_* tests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 HELO_DYNAMIC_DHCP and HELO_DYNAMIC_IPADDR both will not match if an ISP's relay is used; they fire only if the last untrusted IP delivered them directly. They also do not act on rDNS; they act on HELO strings that match that kind of rDNS. Major difference. - --j. Marco d'Itri writes: A single generic rDNS in a Received header is enough to raise way too much the score. Also, it appears that this check would be applied even to mail delivered trought an ISP relay. X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on wonderland.linux= =2Eit X-Spam-Level: * X-Spam-Status: Yes, score=3D5.4 required=3D5.0 tests=3DBAYES_00,HELO_DYNAMI= C_DHCP, HELO_DYNAMIC_IPADDR autolearn=3Dno version=3D3.1.0 X-Spam-Report:=20 * 3.8 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DH= CP) * 3.9 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (= IP addr * 1) * -2.3 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.] X-Original-To: ...wonderland.linux.it Delivered-To: ...wonderland.linux.it Received: from attila.bofh.it (localhost [127.0.0.1]) by wonderland.linux.it (Postfix) with ESMTP id 65F211C7C7 for ...wonderland.linux.it; Mon, 7 Nov 2005 10:44:17 +0100 (CET) Received: from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by attila.bofh.it (Postfix) with ESMTP id C099A5F7AA for ...wonderland.linux.it; Mon, 7 Nov 2005 10:44:17 +0100 (CET) Received: from dsl-217-155-153-11.zen.co.uk (dsl-217-155-153-11.zen.co.uk [= 217.155.153.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by picard.linux.it (Postfix) with ESMTP id 4D32F3F00 for [EMAIL PROTECTED]; Mon, 7 Nov 2005 10:44:16 +0100 (CET) Received: from phil by dsl-217-155-153-11.zen.co.uk with local (Exim 4.54) id 1EZ3Xz-0002SP-MZ for [EMAIL PROTECTED]; Mon, 07 Nov 2005 09:44:15 + --=20 ciao, Marco --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Digital signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDbyVbFGfw2OHuP7ERAhBtAJ9PdhbYtSk47bAKgC6SkwTT/4kDwACfcsKY qT6szMyk+xgiAC3fX55j8nE= =Ib10 -END PGP SIGNATURE- --PEIAKu/WMn1b1Hv9-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Exmh CVS iD8DBQFDb5clMJF5cimLx9ARAovXAKCPI2a8BFbJcsMlOpbeS24o7HpgJQCggyht 8ifMQM3++qIOzrb5q4LMk2Y= =vLps -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337922: too much aggressive HELO_DYNAMIC_* tests
severity 337922 normal thanks On Mon, Nov 07, 2005 at 10:58:51AM +0100, Marco d'Itri wrote: A single generic rDNS in a Received header is enough to raise way too much the score. Also, it appears that this check would be applied even to mail delivered trought an ISP relay. The SpamAssassin scores are carefully optimized -- I won't change any scores from upstream. What seems more likely is that your trusted_networks and/or internal_networks settings are not set correctly (the guessing algorithm isn't perfect). Can you please set them and try checking this e-mail again? You may find that it will no longer hit. (Either way, please let me know.) I'm going to add a note about trusted_networks to the README.Debian. -- Duncan Findlay signature.asc Description: Digital signature
Bug#337922: too much aggressive HELO_DYNAMIC_* tests
On Nov 07, Duncan Findlay [EMAIL PROTECTED] wrote: The SpamAssassin scores are carefully optimized -- I won't change any scores from upstream. What seems more likely is that your Yes, I am arguing that the scores for these two tests are too much aggressive. The message was rejected (even after a -2.3 bonus score!) *only* because it had a generic-looking rDNS hostname also used in the HELO[1]: Received: from dsl-217-155-153-11.zen.co.uk (dsl-217-155-153-11.zen.co.uk [217.155.153.11]) This may not have been the wisest choice by the administrator considering the circumstances, but I think it's hard to argue that people should use an HELO string different from the rDNS... If after this you still believe that a 7.7 score is correct then please say so, at least he (who I Cc'ed) will know why in the future all his mail will be rejected by spamassassin. :-) trusted_networks and/or internal_networks settings are not set correctly (the guessing algorithm isn't perfect). Can you please set Not relevant in my case, the message was sent by that host (static IP, even with an inetnum record for the customer) directly to my MX. [1] You can skip the lecture about drones doing this too, I am aware of it. -- ciao, Marco signature.asc Description: Digital signature
