On Tue, Aug 11, 2009 at 10:56:57AM +0200, Joerg Morbitzer wrote: > I just did a fresh sendmail installation on Debian Etch getting this > auto-generated new /etc/mail/access file: > > titan:~# grep "^Connect:.*RELAY" /etc/mail/access > Connect:localhost RELAY > Connect:127 RELAY > Connect:[IPv6:::1] RELAY > titan:~#
Although it only binds to 127.0.0.1 and ::1 by default, Debian Lenny has the same default /etc/mail/access, which turns the whole "Doctor, it hurts when I do this!" discussion into "Doctor, it hurts when you do this to me!" On the other hand, I was not able to reproduce the problem on a Lenny virtual machine in my test environment. After I tampered with rDNS so that the sending system would resolve to 'localhost', Sendmail did indeed record the hostname 'localhost' in log messages, but it was always accompanied by the sending system's IP address and the note 'may be forged'. Even with the ability to control forward resolution of localhost (which requires commenting out the localhost lines in /etc/hosts or altering NSS configuration), I was able to get rid of the "may be forged" warnings but wasn't able to relay. I don't have any suitable Etch images prepared (and didn't want to sit through an installation), so I didn't run a test from a clean install, but in limited testing on an existing Etch system with the default "Connect:localhost RELAY" line in /etc/mail/access, I could not get the system to relay mail that it shouldn't have. Notes on test procedure: The Lenny Sendmail installation was entirely default, except that sendmail.mc was edited to allow Sendmail to bind all interfaces on the system. BIND was installed on the same system and provided with a suitably altered version of my number-to-name zone. The /etc/resolv.conf file was altered to point only at this new nameserver. To test ability to control forward resolution of 'localhost', I commented out all 'localhost' lines in /etc/mail/access and added a new line which matched the information my test DNS server was delivering. I did not perform tests on the Etch system that required altering /etc/hosts. On the Etch Here is a session transcript from a conversation with the Lenny system (with hostnames and IP addresses altered). Note that the same results happend regardless of whether I HELO'd with 'localhost', the target system's hostname, or some other name. | 220 vmtest1.a.test ESMTP Sendmail 8.14.3/8.14.3/Debian-5; Wed, 12 Aug 2009 16:43:04 -0600; (No UCE/UBE) logging access from: [x.x.x.5](FORGED)-localhost [x.x.x.5] (may be forged) | helo myhostname | 250 vmtest1.a.test Hello localhost [x.x.x.5] (may be forged), pleased to meet you | mail from: us...@a.test | 250 2.1.0 us...@a.test... Sender ok | rcpt to: us...@a.test | 550 5.7.1 us...@a.test... Relaying denied. IP name possibly forged [x.x.x.5] | quit | 221 2.0.0 vmtest1.a.test closing connection Here is a (hand-retyped) section of the mail log for the above session: | Aug 12 16:43:15 vmtest1 sm-mta[4761]: n7CMh4Q5004761: ruleset=check_rcpt, arg1=us...@a.test, relay=localhost [x.x.x.5] (may be forged), reject=550 5.7.1 us...@a.test... Relaying denied. IP name possibly forged [x.x.x.5] | Aug 12 16:43:16 vmtest1 sm-mta[4761]: n7CMh4Q5004761: from=us...@a.test, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=localhost [x.x.x.5] (may be forged) -- William Aoki KD7YAF wa...@umnh.utah.edu 5-1924 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
