[ On Wednesday, October 13, 2004 at 09:26:19 (-0700), Tor Slettnes wrote: ]
> Subject: Re: [exim] Is there and logical reason to reject mail from: <> ?
>
> On Wed, 2004-10-13 at 12:23, Greg A. Woods wrote:
> > There is simply NO VALID EXCUSE for rejecting transactions with an empty
> > return path when the sole recipient is the <postmaster> mailbox.
>
> Oh, I can come up with an excuse, all right (basically, a fair amount of
> phishing/spam is sent "From: <postmaster@...>" -- with alarming subjects
> like "your account will be disabled" etc..; there is backscatter).
Well, first of all it's _extremely_ rare (for now, at least in my
experience) for such junk to be sent with a null return path.
In any case that's still _not_ a valid excuse for rejecting the mail
transaction.
If you need/want to block that kind of junk then there are a zillion
other better and more effecitive ways to do so which don't also block
legitimate use by human testers, etc.
> Then again, even if an RFC says something, it is not neccessarily the
> Universal Truth(tm). For instance, I note that you advocate rejecting
> DSNs/bounces sent to more than one recipient. I am sure you know that
> RFC2505, section 2.6.1, states:
As I'm sure you're awayre RFC 2505 is only a "Best Common Practice"
guideline. :-)
Note also that RFC 2505 refers to many of the ill-concieved excuses for
using null return paths that have been dreampt up by others who are
trying to extend the mail protocols without considering all the protocol
layering violations their half-baked ideas cause.
The SMTP envelope must be the sole domain of the MTA and a sane MTA will
not allow applications to set a null return path, be they privileged or
not. Confusing the layers here is the kind of mistake that has lead to
much of the recent insanity of ill-begotten bogus attempts at sender
address verification. The envelope sender address has one and only one
purpose in SMTP, and that's to give _an_ address where error reports are
to be sent by another MTA. The null return path is only to be used when
by an MTA sending a delivery error report. Attempts to read _anything_
more into the authenticity of a sender address, or the use of a null
return path, is simply wrong.
> Similarly, because no outgoing mail is sent from <postmaster>, it is my
> opinion that bounces to postmaster is perfectly rejectable, for the same
> reason.
As I've demonstrated that's simply not a valid reason.
The <postmaster> mailbox _must_ exist for testing purposes and it is
demonstrably extremely counter productive to block SMTP testing.
Furthermore unless your MTA explicitly blocks relaying of any message
transaction attempting to use <postmaster@???> then you
cannot say authoritatively that no mail is ever sent from your domain(s)
using the postmaster mailbox as the return path. :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
