From owner-freebsd-hackers Sun Sep 7 17:33:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA21144 for hackers-outgoing; Sun, 7 Sep 1997 17:33:58 -0700 (PDT) Received: from pandora.hh.kew.com (root@kendra.ne.mediaone.net [24.128.53.73]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21114; Sun, 7 Sep 1997 17:33:47 -0700 (PDT) Received: from sonata (sonata.hh.kew.com [192.195.203.135]) by pandora.hh.kew.com (8.8.5/8.8.5) with ESMTP id UAA25801; Sun, 7 Sep 1997 20:33:45 -0400 (EDT) Message-ID: <3413480B.BADF1376@kew.com> Date: Sun, 07 Sep 1997 20:34:19 -0400 From: Drew Derbyshire Organization: Kendra Electronic Wonderworks X-Mailer: Mozilla 4.01 [en]C-MOENE (WinNT; U) MIME-Version: 1.0 To: "Jonathan M. Bresler" CC: hackers@hub.freebsd.org, support@kew.com Subject: Re: spam and the FreeBSD mailing lists X-Priority: 3 (Normal) References: <199709072335.QAA17881@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jonathan M. Bresler wrote: > Drew Derbyshire wrote: > > The TCP/IP protocol implicitly requires public IP address to be properly > > registered to be routed (otherwise, you don't get your ACK's back!), > > please remember to distinguish between "mail from:" addresses > and relays. The relay name (host name of the SMTP client) need not be resolvable in DNS, I didn't mean to imply it did. I mean the actual IP addresss had to be routable. Someone else was confused by my wording as well. > if the "don't get your ACK's back" they cant establish the TCP > session in order to transfer the mail in the first place. Correct, which goes back to my original statement that the network routing must be registered -- not with DNS, but with the backbone routers. > there is *not* reasone that i know of that a > "mail from:" address must be resolvable. Yes, there is. The address in the SMTP "MAIL FROM" line is used for bounce messages by sendmail. Consider if you send mail via a third-party relay (such as a back-up MX forwarder, something both kew.com and freebsd.org have) and mail lands on the backup MX forwarder because the primary is down. When the intermediate relay connects to the ultimate destination, if the user id on the final is bad then the intermediate relay's bounce message will be sent to the "MAIL FROM" address. Thus, the bounce message is lost if the "MAIL FROM" address is bad. -ahd- -- Internet: ahd@kew.com Voice: 617-279-9812 "MS-DOS didn't get as bad as it is overnight -- it took over ten years of careful development." - dmeggins@aix1.uottawa.ca