On Saturday 08 May 2004 16:12, Pat Masterson wrote:Does anybody have a rule to recognize my own IP in the HELO ?
Heinz Ulrich Stille wrote:
It's much simpler to let the mta reject the connection outright. No chance that there could come something good over it.
There are also many spams that use the recipient's IP address as a hostname, so their Received headers look like this:
Received: from UNKNOWN(218.1.160.93), claiming to be "1.2.3.4" via SMTP by mail.someplace.com, id smtpdZ0ZVgY; Wed May 5 18:51:28 2004
where "1.2.3.4" is mail.someplace.com's IP address. These can't be caught at the SMTP level, so I have these SA rules:
header SENDER_CLAIMS_PRI_MX Received =~ /claiming to be "1.2.3.4/ describe SENDER_CLAIMS_PRI_MX Sender uses primary MX IP as hostname
header SENDER_CLAIMS_SEC_MX Received =~ /claiming to be "5.6.7.8/ describe SENDER_CLAIMS_SEC_MX Sender uses secondary MX IP as hostname
header SENDER_CLAIMS_DOMAIN Received =~ /claiming to be ".*someplace.com" via/i
describe SENDER_CLAIMS_DOMAIN Sender claims his server is in our domain
where 1.2.3.4 and 5.6.7.8 are the IP's of the primary and secondary MX server and "someplace.com" is replaced by your domain name. Most of the times when SENDER_CLAIMS_PRI_MX is triggered, I also see SENDER_IP_NO_REVERSE. This is a custom rule that's triggered when the sending host has no reverse resolution. (It's keyed to something in reports from the email proxy server I use, so it's not worth posting here.) I also see a lot of SPAMCOP_URI_RBL reports when SENDER_CLAIMS_PRI_MX is triggered.
I score all these rules high enough that I'm sure anything matching them will be marked as spam. Since all of these patterns indicate deception on the part of the sender, they shouldn't ever appear in legitimate messages.
Peter
