|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14289.14131.519380.482752@enza.valleytech.com> Date: Sat, 4 Sep 1999 11:25:41 -0400 Reply-To: Daniel Dulitz <dulitz@VALLEYTECH.COM> From: Daniel Dulitz <dulitz@VALLEYTECH.COM> X-To: Technical Incursion Countermeasures <lists@TICM.COM> To: BUGTRAQ@SECURITYFOCUS.COM In-Reply-To: <3.0.3.32.19990902222455.031374f0@localhost> Technical Incursion Countermeasures writes: > 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... > > spoof a mail from an invalid address on one end to an invalid address on > the other. and sit back.. Sit back and watch absolutely nothing happen, unless both mailers are misconfigured. Even the venerable RFC821 (http://www.faqs.org/rfcs/std/std10.html) notes that: Of course, server-SMTPs should not send notification messages about problems with notification messages. > the first site will accept the mail (this is the fault - it should reject > if it is to comply with the IETF standard) This cannot be the fault -- otherwise any pair of SMTP servers who happen to send mail to each other by way of a relay (an ordinary MX relay) would be vulnerable to such a spoofing attack. Best, daniel dulitz
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |