[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sendmail & localhost rDNS



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: user1@a.test
| 250 2.1.0 user1@a.test... Sender ok
| rcpt to: user2@a.test
| 550 5.7.1 user2@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=user2@a.test, relay=localhost [x.x.x.5] (may be forged), reject=550 5.7.1 user2@a.test... Relaying denied. IP name possibly forged [x.x.x.5]
| Aug 12 16:43:16 vmtest1 sm-mta[4761]: n7CMh4Q5004761: from=user1@a.test, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=localhost [x.x.x.5] (may be forged)

-- 
William Aoki     KD7YAF    waoki@umnh.utah.edu    5-1924


Reply to: