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>