Date: Fri, 25 Jul 1997 03:31:09 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Anthony.Kimball@East.Sun.COM Cc: jflists@calweb.com, current@FreeBSD.ORG Subject: Re: (over)zealous mail bouncing Message-ID: <19970725033109.17747@hydrogen.nike.efn.org> In-Reply-To: <199707241928.OAA03645@pobox.com>; from Tony Kimball on Thu, Jul 24, 1997 at 02:28:32PM -0500 References: <199707241422.HAA00957@hub.freebsd.org> <199707241601.LAA03086@compound.east.sun.com> <3.0.3.32.19970724103920.0094c100@pop.calweb.com> <199707241928.OAA03645@pobox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Kimball scribbled this message on Jul 24: > Quoth jfesler@calweb.com on Thu, 24 July: > : > : We actively block any SMTP session where the MAIL FROM: command lacks a > : valid DNS entry. > > Okay, this is another issue entirely. You are requiring that every > piece of mail have a return path out to the Internet leaf node, yes? > (Coming to an understanding with one correspondent evidently does > not mean that one has come to understand all correspondents!) > That does not guarantee a return path, because there may be further > transports beyond the edge of the Internet, but probably gets you one > in the vast majority of cases. ok... well... I was starting to read up on the RFC's and all you anti-spammers needed to do was quote rfc821 which talks about the specification for the MAIL FROM: line... it reads as follows: The first step in the procedure is the MAIL command. The <reverse-path> contains the source mailbox. MAIL <SP> FROM:<reverse-path> <CRLF> This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. It gives the reverse-path which can be used to report errors. If accepted, the receiver-SMTP returns a 250 OK reply. as you can see, you have EVER right to reject the mail when the reverse-path is invalid... had someone quoted this long ago, I would of shut up... but I was ignorant of the rfc, so I was thinking it was valid... > As I understand it, you are only bouncing mail which cannot be replied > *through* a valid MX or A. I'm guessing that you could probably > construct a valid address from the various "Received:" headers in many > such cases, though. no, they are bouncing mail which doesn't have a valid return-path... and actualy, you are required to specify this... > I suppose this will help to reject casual spam, but it seems to me a > misdirected effort, since most spam, particularly the large-volume > stuff from the pros, will not get filtered in this way. The only > way I can see to do that is to maintain a large kill list. I agree... but I'm going to look at better ways of handling this.. like possibly teaching a machine about our "subdomains" so that we can have addresses like: "jmg@hydrogen.nike.efn.org@resnet.uoregon.edu" which is perfectly valid from the mail stand point... as it is parsed as "<local part> @ domain"... plus I have tested this with godzilla.zeta.org.au, and it was successful in accepting the connection... either that or I'll implement uucp from a host... which might be in the long run better... I'll just have to do research and decide... guess I need to remeber to RTFRFC... :) happy emailing to all... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970725033109.17747>