sendmail & localhost rDNS

[Thomas Liske-3]

Hi,

last week, there was an article on heise security about MTAs[1] which
relay mails for hosts having a reverse resolution of 'localhost'. Doing
a small test shows that sendmail on etch seems to be vulnerable, too. I
need to have a localhost RELAY line in my access file (which is not
default AFAIK).

Will there be a DSA on this issue, since it seems to turn Sendmail
installations with allowed localhost RELAYing into Open Relays?


Cheers,
Thomas


[1]
http://www.h-online.com/security/Naming-trick-opens-mail-servers--/news/113946

--
support@...                              Tel. [phone]
www.ibh.de                                  Fax  [phone]

-----------------------------------------------------------------------
Dipl.-Ing. Thomas Liske
Netzwerk- und System-Design


IBH IT-Service GmbH                         Amtsgericht Dresden
Gostritzer Str. 61-63                       HRB 13626
D-01217 Dresden                             GF: Prof. Dr. Thomas Horn
Germany                                     VAT DE182302907
-----------------------------------------------------------------------
Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV
-----------------------------------------------------------------------
        professioneller IT-Service - kompetent und zuverlässig
-----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lupe Christoph]

On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote:

> last week, there was an article on heise security about MTAs[1] which  
> relay mails for hosts having a reverse resolution of 'localhost'. Doing  
> a small test shows that sendmail on etch seems to be vulnerable, too. I  
> need to have a localhost RELAY line in my access file (which is not  
> default AFAIK).

> Will there be a DSA on this issue, since it seems to turn Sendmail  
> installations with allowed localhost RELAYing into Open Relays?

Are you saying you want a DSA for a package that does not have that
particular vulnerability, but allows a user to create it?

"Doctor, it hurts when I do this!" "Don't do it, then."

Lupe Christoph
--
| There is no substitute for bad design except worse design.                   |
| /me                                                                          |


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Thomas Liske-3]

Re,

#Lupe Christoph wrote:

> On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote:
>
>> last week, there was an article on heise security about MTAs[1] which  
>> relay mails for hosts having a reverse resolution of 'localhost'. Doing  
>> a small test shows that sendmail on etch seems to be vulnerable, too. I  
>> need to have a localhost RELAY line in my access file (which is not  
>> default AFAIK).
>
>> Will there be a DSA on this issue, since it seems to turn Sendmail  
>> installations with allowed localhost RELAYing into Open Relays?
>
> Are you saying you want a DSA for a package that does not have that
> particular vulnerability, but allows a user to create it?

if an access line like:

Connect:localhost               RELAY

turns a MTA into an Open Relay than I would prefere a DSA, since the ACL
implementation is broken IMHO.


Regards,
Thomas

--
support@...                              Tel. [phone]
www.ibh.de                                  Fax  [phone]

-----------------------------------------------------------------------
Dipl.-Ing. Thomas Liske
Netzwerk- und System-Design


IBH IT-Service GmbH                         Amtsgericht Dresden
Gostritzer Str. 61-63                       HRB 13626
D-01217 Dresden                             GF: Prof. Dr. Thomas Horn
Germany                                     VAT DE182302907
-----------------------------------------------------------------------
Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV
-----------------------------------------------------------------------
        professioneller IT-Service - kompetent und zuverlässig
-----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lupe Christoph]

On Monday, 2009-08-10 at 14:03:44 +0200, Thomas Liske wrote:
> #Lupe Christoph wrote:
>> On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote:

>>> last week, there was an article on heise security about MTAs[1] which
>>>  relay mails for hosts having a reverse resolution of 'localhost'.
>>> Doing  a small test shows that sendmail on etch seems to be
>>> vulnerable, too. I  need to have a localhost RELAY line in my access
>>> file (which is not  default AFAIK).

>>> Will there be a DSA on this issue, since it seems to turn Sendmail  
>>> installations with allowed localhost RELAYing into Open Relays?

>> Are you saying you want a DSA for a package that does not have that
>> particular vulnerability, but allows a user to create it?

> if an access line like:

> Connect:localhost               RELAY

> turns a MTA into an Open Relay than I would prefere a DSA, since the ACL  
> implementation is broken IMHO.

Well, a line like this:

Connect:spammer.com                RELAY

does the same, so, as I said, just don't do it. I still don't see why
on one hand you say that you need a localhost line, and then complain
that it hurts you.

Why can't you use 127.0.0.1 or localhost.mydomain?

Lupe Christoph
--
| There is no substitute for bad design except worse design.                   |
| /me                                                                          |


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jan de Groot]

On Mon, 2009-08-10 at 14:03 +0200, Thomas Liske wrote:
> if an access line like:
>
> Connect:localhost               RELAY
>
> turns a MTA into an Open Relay than I would prefere a DSA, since the
> ACL
> implementation is broken IMHO.

As long as reverse DNS can be faked, I would never use hostnames in my
configuration files like that. If the debian package doesn't ship with
this ACL as default, I don't see reason for a DSA.


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Thomas Liske-3]

Re,

Jan de Groot wrote:

> On Mon, 2009-08-10 at 14:03 +0200, Thomas Liske wrote:
>> if an access line like:
>>
>> Connect:localhost               RELAY
>>
>> turns a MTA into an Open Relay than I would prefere a DSA, since the
>> ACL
>> implementation is broken IMHO.
>
> As long as reverse DNS can be faked, I would never use hostnames in my
> configuration files like that. If the debian package doesn't ship with
> this ACL as default, I don't see reason for a DSA.

the problem is even more worse. Replacing localhost with 127.0.0.1 as
suggested by Lupe Christoph doesn't change anything. I can still relay
if my reverse DNS resolves to localhost.


Regards,
Thomas


--
support@...                              Tel. [phone]
www.ibh.de                                  Fax  [phone]

-----------------------------------------------------------------------
Dipl.-Ing. Thomas Liske
Netzwerk- und System-Design


IBH IT-Service GmbH                         Amtsgericht Dresden
Gostritzer Str. 61-63                       HRB 13626
D-01217 Dresden                             GF: Prof. Dr. Thomas Horn
Germany                                     VAT DE182302907
-----------------------------------------------------------------------
Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV
-----------------------------------------------------------------------
        professioneller IT-Service - kompetent und zuverlässig
-----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bernhard R. Link-2]

* Jan de Groot <jan@...> [090810 14:22]:

> On Mon, 2009-08-10 at 14:03 +0200, Thomas Liske wrote:
> > if an access line like:
> >
> > Connect:localhost               RELAY
> >
> > turns a MTA into an Open Relay than I would prefere a DSA, since the
> > ACL
> > implementation is broken IMHO.
>
> As long as reverse DNS can be faked, I would never use hostnames in my
> configuration files like that.

How common is programs verifying reverse DNS by doing forward DNS of the
result? At least all programs relying on this information I've yet met
consciously had it.

Hochachtungsvoll,
        Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bernhard R. Link-2]

* Lupe Christoph <lupe@...> [090810 13:53]:

> On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote:
>
> > last week, there was an article on heise security about MTAs[1] which  
> > relay mails for hosts having a reverse resolution of 'localhost'. Doing  
> > a small test shows that sendmail on etch seems to be vulnerable, too. I  
> > need to have a localhost RELAY line in my access file (which is not  
> > default AFAIK).
>
> > Will there be a DSA on this issue, since it seems to turn Sendmail  
> > installations with allowed localhost RELAYing into Open Relays?
>
> Are you saying you want a DSA for a package that does not have that
> particular vulnerability, but allows a user to create it?
>
> "Doctor, it hurts when I do this!" "Don't do it, then."

"Help, help my computer does funny things!" "Don't power it up, then."

Almost all security holes need to user to do something. (If only to
power up the machine, to install some packages, to connect to the
internet, to give accounts to users). The question cannot be that
something has to be done do make people vulnerable, but whether properly
sane and educated people can guess that something opens a security
problem.

Hochachtungsvoll,
        Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lupe Christoph]

On Monday, 2009-08-10 at 14:35:06 +0200, Bernhard R. Link wrote:
> * Lupe Christoph <lupe@...> [090810 13:53]:
> > On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote:

> > > last week, there was an article on heise security about MTAs[1] which  
> > > relay mails for hosts having a reverse resolution of 'localhost'. Doing  
> > > a small test shows that sendmail on etch seems to be vulnerable, too. I  
> > > need to have a localhost RELAY line in my access file (which is not  
> > > default AFAIK).

> > > Will there be a DSA on this issue, since it seems to turn Sendmail  
> > > installations with allowed localhost RELAYing into Open Relays?

> > Are you saying you want a DSA for a package that does not have that
> > particular vulnerability, but allows a user to create it?

> > "Doctor, it hurts when I do this!" "Don't do it, then."

> "Help, help my computer does funny things!" "Don't power it up, then."

That's not what I meant. Admitted, the quote is more funny than exact
(and it isn;t particularly funny...). What I mean is that a lot of
software allows the user to shoot himself in various body parts. One
such example is rm. As in "rm * .o". Oooops.

More related to the OP, sendmail allows you to configure an open relay
in a number of ways, not all of them as easily identified as the
"localhost" problem. It has a built-in write-only language...

But why would the posssibility to configure the package to open a relay
warrant a DSA? It would IMNSHO only when the package came preconfigured
to do that.

> Almost all security holes need to user to do something. (If only to
> power up the machine, to install some packages, to connect to the
> internet, to give accounts to users). The question cannot be that
> something has to be done do make people vulnerable, but whether properly
> sane and educated people can guess that something opens a security
> problem.

I interpret this to mean that there should be DSAs for all problems *made
possible* by Debian packages, rather than those *caused* by the package.

Lupe Christoph
--
| There is no substitute for bad design except worse design.                   |
| /me                                                                          |


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Thomas Liske-3]

Re,

Lupe Christoph wrote:

> On Monday, 2009-08-10 at 14:35:06 +0200, Bernhard R. Link wrote:
>> * Lupe Christoph <lupe@...> [090810 13:53]:
>>> On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote:
>
>>>> last week, there was an article on heise security about MTAs[1] which  
>>>> relay mails for hosts having a reverse resolution of 'localhost'. Doing  
>>>> a small test shows that sendmail on etch seems to be vulnerable, too. I  
>>>> need to have a localhost RELAY line in my access file (which is not  
>>>> default AFAIK).
>
>>>> Will there be a DSA on this issue, since it seems to turn Sendmail  
>>>> installations with allowed localhost RELAYing into Open Relays?
>
>>> Are you saying you want a DSA for a package that does not have that
>>> particular vulnerability, but allows a user to create it?
>
>>> "Doctor, it hurts when I do this!" "Don't do it, then."
>
>> "Help, help my computer does funny things!" "Don't power it up, then."
>
> That's not what I meant. Admitted, the quote is more funny than exact
> (and it isn;t particularly funny...). What I mean is that a lot of
> software allows the user to shoot himself in various body parts. One
> such example is rm. As in "rm * .o". Oooops.

If 'rm foo' has the same effect like 'rm -rf /', than rm would be
broken. If '127.0.0.1 RELAY' has the same effect like '* RELAY' than
sendmail is broken.

> More related to the OP, sendmail allows you to configure an open relay
> in a number of ways, not all of them as easily identified as the
> "localhost" problem. It has a built-in write-only language...

This has nothing todo with the OP.

> But why would the posssibility to configure the package to open a relay
> warrant a DSA? It would IMNSHO only when the package came preconfigured
> to do that.

yep, I think most of the recent DSAs shouldn't be published. The
packages can be exploided if feed with user data - this is a change to
the preconfigured setup !!!

>> Almost all security holes need to user to do something. (If only to
>> power up the machine, to install some packages, to connect to the
>> internet, to give accounts to users). The question cannot be that
>> something has to be done do make people vulnerable, but whether properly
>> sane and educated people can guess that something opens a security
>> problem.
>
> I interpret this to mean that there should be DSAs for all problems *made
> possible* by Debian packages, rather than those *caused* by the package.

It is caused by the package, due the implementation of the access.db
handling. If netfilter wouldn't drop/reject any packets, you won't issue
an DSA? The preconfiguration doesn't ship any rules, so  nobody should
care if netfilter doesn't work in stable...


Regards,
Thomas

PS: The guy who went to the doctor has died by disease last week. If the
doc would have take a look at the guy, he would still be alive.

--
support@...                              Tel. [phone]
www.ibh.de                                  Fax  [phone]

-----------------------------------------------------------------------
Dipl.-Ing. Thomas Liske
Netzwerk- und System-Design


IBH IT-Service GmbH                         Amtsgericht Dresden
Gostritzer Str. 61-63                       HRB 13626
D-01217 Dresden                             GF: Prof. Dr. Thomas Horn
Germany                                     VAT DE182302907
-----------------------------------------------------------------------
Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV
-----------------------------------------------------------------------
        professioneller IT-Service - kompetent und zuverlässig
-----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bernhard R. Link-2]

* Lupe Christoph <lupe@...> [090810 21:13]:
> > Almost all security holes need to user to do something. (If only to
> > power up the machine, to install some packages, to connect to the
> > internet, to give accounts to users). The question cannot be that
> > something has to be done do make people vulnerable, but whether properly
> > sane and educated people can guess that something opens a security
> > problem.
>
> I interpret this to mean that there should be DSAs for all problems *made
> possible* by Debian packages, rather than those *caused* by the package.

What I try to tell you is that I do not share your interpretion of
"caused".

If bash had a bug to always include . in PATH, would that cause
a problem or make a problem possible? (After all, noone forces you do
switch to other peoples directories before doing ls).

If a webbrowser has a problem executing arbitrary stuff told by the
website visited, is that a security problem "caused" or made possible by
the webbrowser. (After all, if you do not visit untrusted sites, there
is no problem).

If sshd had a bug so that "PermitRootLogin without-password" (which is not
the default) allowed people to login without any identification as root
instead of what it is supposed to be, would that be bug caused by ssh
or a bug made possible by ssh?

So it is in my eyes to criteria at all that the user has to change some
configuration. The question is whether this change is supposed to cause
the effects it does and if a user can be expected to understand the
effects.

Hochachtungsvoll,
        Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lupe Christoph]

OK, I give up. And shut up.

Please file a bug against the sendmail package, with the information
that sendmail allows you to enter "Connect:localhost RELAY" in
/etc/mail/access.

And another one that "Connect:127.0.0.1 RELAY" opens up the same hole as
"Connect:localhost RELAY".

Since I have no sendmail installation to use for testing, I can't
reproduce the second problem. The sendmail package maintainer will
probably require the submitter to provide details which I can't.

Thank you,
Lupe Christoph
--
| There is no substitute for bad design except worse design.                   |
| /me                                                                          |


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lupe Christoph]

On Tuesday, 2009-08-11 at 10:32:04 +0200, Bernhard R. Link wrote:
> * Lupe Christoph <lupe@...> [090810 21:13]:
> > > Almost all security holes need to user to do something. (If only to
> > > power up the machine, to install some packages, to connect to the
> > > internet, to give accounts to users). The question cannot be that
> > > something has to be done do make people vulnerable, but whether properly
> > > sane and educated people can guess that something opens a security
> > > problem.

> > I interpret this to mean that there should be DSAs for all problems *made
> > possible* by Debian packages, rather than those *caused* by the package.

> What I try to tell you is that I do not share your interpretion of
> "caused".

> If bash had a bug to always include . in PATH, would that cause
> a problem or make a problem possible? (After all, noone forces you do
> switch to other peoples directories before doing ls).

That would be a defect in the package that requires no user
configuration. The equivalent of "Connect:localhost RELAY" would be this
in .bashrc: PATH=.:$PATH .

> If a webbrowser has a problem executing arbitrary stuff told by the
> website visited, is that a security problem "caused" or made possible by
> the webbrowser. (After all, if you do not visit untrusted sites, there
> is no problem).

That is a defect in the webbrowser. It requires no user configuration.

> If sshd had a bug so that "PermitRootLogin without-password" (which is not
> the default) allowed people to login without any identification as root
> instead of what it is supposed to be, would that be bug caused by ssh
> or a bug made possible by ssh?

That is a bug because sshd does not what is documented. Suppose
sshd_config had an option "PermitRootLogin always", meaning that no
password or key is required to log in as root. Would it be a bug of sshd
to include this option or a misfeature?

> So it is in my eyes to criteria at all that the user has to change some
> configuration. The question is whether this change is supposed to cause
> the effects it does and if a user can be expected to understand the
> effects.

Please go ahead and file security-related bugs against all packages that
allow the user to open security holes by changing the default
configuration.

I suppose we should agree to disagree and terminate this thread here. Of
course I will not restrict your freedom to answer to this mail, but I
will leave your reply unanswered because I believe we won't ever
agree.

Lupe Christoph
--
| There is no substitute for bad design except worse design.                   |
| /me                                                                          |


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Joerg Morbitzer]

Lupe Christoph wrote:

> OK, I give up. And shut up.
>
> Please file a bug against the sendmail package, with the information
> that sendmail allows you to enter "Connect:localhost RELAY" in
> /etc/mail/access.
>
> And another one that "Connect:127.0.0.1 RELAY" opens up the same hole as
> "Connect:localhost RELAY".
>
> Since I have no sendmail installation to use for testing, I can't
> reproduce the second problem. The sendmail package maintainer will
> probably require the submitter to provide details which I can't.
>
> Thank you,
> Lupe Christoph

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:~#


Regards, Joerg.


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michiel Klaver-2]

If sendmail would do a double lookup verify on the reverse DNS records,
there would be no problem at all.

When some obscure IP address has reverse DNS pointer record "localhost"
and sendmail would do another lookup to see what IP address belongs to
"localhost", then it would not match (obscure IP != 127.0.0.1) and the
access DB rule should not be valid for this connection.

Could someone from the Debian security team do some test and check if
sendmail does the double lookup verify? If not, a DSA would be
appropriate and it should be patched.


With kind regards,

Michiel Klaver
IT professional


At 11-8-2009 10:45, Lupe Christoph wrote:

> OK, I give up. And shut up.
>
> Please file a bug against the sendmail package, with the information
> that sendmail allows you to enter "Connect:localhost RELAY" in
> /etc/mail/access.
>
> And another one that "Connect:127.0.0.1 RELAY" opens up the same hole as
> "Connect:localhost RELAY".
>
> Since I have no sendmail installation to use for testing, I can't
> reproduce the second problem. The sendmail package maintainer will
> probably require the submitter to provide details which I can't.
>
> Thank you,
> Lupe Christoph

--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bernhard R. Link-2]

* Lupe Christoph <lupe@...> [090811 10:56]:

> > So it is in my eyes no criteria at all that the user has to change some
> > configuration. The question is whether this change is supposed to cause
> > the effects it does and if a user can be expected to understand the
> > effects.
>
> Please go ahead and file security-related bugs against all packages that
> allow the user to open security holes by changing the default
> configuration.
>
> I suppose we should agree to disagree and terminate this thread here. Of
> course I will not restrict your freedom to answer to this mail, but I
> will leave your reply unanswered because I believe we won't ever
> agree.

Thanks for "not restricting" my "freedom" to reply to a mail that ridicules
what I say by drawing absurd conclusions out of it.

I never said that being able to change a configuration to open holes is
in itself and always a security problem. What I am saying is that
needing user action or having to change a configuration file is no
reason at all to claim that something is not a security problem.

Annoyed,
        Bernhard R. Link

> That is a bug because sshd does not what is documented. Suppose
> sshd_config had an option "PermitRootLogin always", meaning that no
> password or key is required to log in as root. Would it be a bug of sshd
> to include this option or a misfeature?

Of course not. And being able to add an option to sendmail to allow
everyone to relay would of course also definitely be no problem if it was
documentated to do so and has a sensible name. And noone in this thread
claimed it would be.


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Will Aoki-2]

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

--
William Aoki     KD7YAF    waoki@...    5-1924


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...