On Tue, Nov 15, 2005 at 08:06:45AM +0000, Declan Moriarty wrote: > This is informational, as a lot of you seem to be using poorly > configured mail servers without knowing it. > > There are 2 main errors: > > 1. Allowing IP addresses reserved for private networks onto the net, > e.g. > > Received: from [192.168.1.45] (pool-71-103-104-29.lsanca.dsl-w.verizon.net > [71.103.104.29]) by hops.lfs-matrix.net > > 192.168.xxx.xxx doesn't resolve to anything. For those with spam > filters, this triggers various rules, usually UNPARSEABLE_RELAY, an > excellent spam indicator.
Whoa. Take a step back and read the RFC's. This is totally valid as far as private/public IP's is concerned. The private IP in the example above is not intended to be resolvable, per se. It is the HELO, which can be just about anything. It is only the receiving smtpd's job to decide if it wants to accept that HELO, not any of the following smtpd's it may be passed on to. Any sane mail server that cannot restrict based on what segment of the network the client is on relies on other means of authenticating. The above server I happen to know uses SMTP AUTH which supercedes HELO checks. Note, these HELO checks would be performed by an outsider who is mailing someone local to the above server and one could/should allow for restricting based on that, but that is for the SMTP server, not a spam filter. So back to the example above; the part in parentheses is what the mail server determines on it's own via reverse DNS lookup, so now the IP and the hostname are known valid (assuming the reverse DNS was setup correctly by the ISP or whoever). So now you have your resolvable address. And for postfix users who want to put a stranglehold on spam at the smtp level, and avoid SA and it's huge penalty, look at the postfix man pages for the following (note, this is very restrictive, and order is important): smtpd_recipient_restrictions = reject_non_fqdn_recipient reject_non_fqdn_sender reject_unknown_sender_domain reject_unknown_recipient_domain permit_mynetworks reject_unauth_destination check_recipient_access hash:/etc/postfix/roleaccount_exceptions check_helo_access pcre:/etc/postfix/helo_checks warn_if_reject reject_non_fqdn_hostname reject_invalid_hostname check_sender_mx_access cidr:/etc/postfix/bogus_mx reject_rbl_client sbl-xbl.spamhaus.org reject_rbl_client relays.ordb.org reject_unverified_sender > Received: from p54A52B17.dip0.t-ipconnect.de (EHLO Trollhammer) [84.165. > 43.23] > Received: from fiancee (unknown [81.106.244.9]) > by smtp14 (Coremail) with SMTP id GQBiG7f6dENq1UsC.1 So ahead and fight the good fight, but until everyone in the world stops using Outlook and Outlook express (and others, I'm sure) then netBIOS names will continue to be sent as HELO/EHLO names. :/ -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
