[ On Saturday, June 25, 2005 at 11:57:43 (+0100), Philip Hazel wrote: ]
> Subject: RE: [exim] a large number of domains fronted by Exim are refusing bounces...
>
> On Sat, 25 Jun 2005, Greg A. Woods wrote:
>
> > However if those addresses do exist then they _MUST_ accept valid
> > messages, from valid sources, especially when those messages are sent
> > with a null return path.
>
> "MUST" in the RFC sense, perhaps yes. But "MUST" in the sense of "You
> may not have your own policy about these things", no.
My point is that a good implementation will make it much harder for any
given site to successfully implement technical controls for a policy
that's in direct contradiction to the protocol standard, especially for
a core protocol feature such as this.
> If I were to follow your rule, I would have to manually look at about
> 100 bounces per day that are nowadays sent to those of my addresses from
> which I never send email. I am not prepared to waste my time doing this.
If that's the problem then your other policy controls are what are lacking.
> So what? I might have an address that is used only for triggering some
> special action (it rings my cellphone, or it collects some statistics,
> or whatever). It is never used as a sender in outgoing mail. It only
> accepts messages from certain hosts and senders (probably using some
> kind of authentication). All other messages, including null-sender
> messages, are rejected. That's my policy for that address. I don't see
> any problem with that.
IFF such a mailbox only accepts mail from certain hosts (or using using
authentication, etc.) then that those controls alone should be
sufficient to block abuse that might try to sneak through using the null
sender path.
Furthmore those are exactly the kinds of address where you do also want
to receive valid error notifications as otherwise there's not likely to
be any out-of-band mechanism to inform you of problems.
> And there's the rub. What is "legitimate"?
That's what your other (those not defined by the return-path) policies
are supposed to define.
> Nobody in this thread, IIRC, has advocated blocking messages just
> because they use a null return path, without looking at other
> conditions.
Perhaps not, but Exim's current design is what has made it possible for
many _millions_ of domains to implement such a policy without a second
thought or apparently even a stern warning.
"We" know it's wrong, and that's not the issue -- what is at issue is
that _you_ should be able to make it more difficult for those doing
wrong (the kind of "wrong" which affects the global community as much or
more than those doing it).
> IF $sender is "" and $recipient is NOT <my sending address> THEN
> discard message
At the basic level that's a nonsensical rule. It is impossible for any
MTA that's designed to operate as a gateway to define what might be
valid relationships between "$recipient" and "<my sending address>".
Very often those kinds of rules can only be made by the sending MUA.
And BTW, one of the related problems to this issue is the fact that it
seems any and every random policy rule implementation results in one
generic content-free and almost totally meaningless SMTP error message.
Worse yet that error is often only returned after the entire message has
been transmitted. Thats a very horrible waste.
SMTP was designed in such a way that the transaction steps proceed in a
natural order the server host can notify the sending host as soon as
possible whenever any problem is detected so as to save all unnecessary
processing steps.
SMTP was also designed in such a way that error responses can return
helpful informative text, and as many lines of it as desired, so that
the sending host, and/or users on the sending side, can determine as
accurately as possible what the cause of the problem might be.
I.e. it is extremely counter-productive to allow admins to implement
policies in such a way that errors are not returned until end-of-DATA.
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
