[11756] in bugtraq
Re: I found this today and iam reporting it to you first!!! (fwd)
daemon@ATHENA.MIT.EDU (Daniel W. Dulitz x108)
Wed Sep 8 20:43:23 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <14292.7511.913350.588346@grouper.valleytech.com>
Date: Mon, 6 Sep 1999 17:12:31 -0400
Reply-To: "Daniel W. Dulitz x108" <dulitz@VALLEYTECH.COM>
From: "Daniel W. Dulitz x108" <dulitz@VALLEYTECH.COM>
X-To: Bret Watson <ticm@pop.softhome.net>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <3.0.3.32.19990905110303.030db6e0@10.100.1.1>
[ We're veering into technical mail stuff, so this will be my last
cc: to Bugtraq. ]
Bret Watson writes:
> Exactly... however - many mail servers _are_ misconfigured. especially
> those using an external-internal relay...
Preventing infinite error bouncing is not terribly difficult to begin
with, and it's no more or less difficult on a boundary relay than it
is on an ordinary MX relay. It takes quite a bit of work to
misconfigure sendmail or qmail so that they will cause mail loops for
bounce messages. Remember that the original claim was:
> basically find two sites whose FW is conf'd to accept all mail and forward
> it to the real mailserver. If this mailserver bounces invalid addresses
> then you're on your way...
And that's just wrong, as was the original suggestion that the problem
is caused by delayed error notification. The problem is caused by a
difficult-to-accomplish misconfiguration: either (a) the Return-Path
header was incorrectly set, or (b) the bounce message was sent with a
non-null envelope address.
Best,
daniel dulitz
