[ On Sunday, June 19, 2005 at 23:34:38 (+0100), Chris Edwards wrote: ]
> Subject: RE: [exim] a large number of domains fronted by Exim are refusing bounces...
>
> On Sun, 19 Jun 2005, Greg A. Woods wrote:
>
> | [*] that's not to say that all error messages must be accepted --
> | clearly error messages to non-existant recipients are bogus and may
> | safely be rejected (since they're not deliverable anyway), as perhaps
> | are those containing known junk content, etc.
>
> It would be useful if you could explain exactly how you envisage an MTA
> can provide flexibility to:
>
> (1) enable clueful sites to reject bogus bounce messages (pretty darn
> tricky in our experience, but absolutely necessary)
>
> whilst at the same time:
>
> (2) prevent clueless sites rejecting genuine bounce messages
Well it's really quite easy if one separates these things at the right
conceptual level.
If a server isn't going to accept any mail from some given source
address regardless, or if it has some given content (e.g. a virus) then
of course there's no need for it to accept bounce messages, or messages
to postmaster, etc. either.
However if messages would be accepted from the client for "valid"
recipients, then bounce messages MUST NOT be treated specially.
I would think this kind of separation is really quite easy to do if
one's tools are designed robustly and with a certain reasonable degree
of safety in mind.
Of course there are no doubt tricks one can do at any time with any tool
to make it behave unsafely or in a non-failsafe manner, especially with
anything so complex as a full-featured MTA.
However What I've been trying to get across here is that the language
for expressing ACLs on sender addresses should not allow the admin to
specify the null return-path sender address in the first place, or else
never allow transactions with a null return-path to be presented to
ACLs.
The null return path MUST be treated specially since its unique status
is, and always has been, a primary requirement for error handling in the
SMTP protocol specification and the Internet Host Requirements STANDARD.
I.e. an SMTP mailer that allows one to so trivially say something like:
If the sender is the empty string
AND the recipient is Y
THEN deny this message
and have it reject all messages to the stated recipient iff those
messages have a null return path, is broken by design (or at least
seriously hobbled with a noose already firmly tied around all its users'
necks).
That kind of construct should probably result in a syntax or config
error since "the empty string" should not be a valid value with which
sender address comparisons can be made.
Another way to do this without having to cause a syntax error
(i.e. without having to special case the empty string in a context
sensitive way) would of course be to never test any null return path
against such a rule in the first place (though that might just frustrate
the admin unnecessarily).
Either way the clueless admin would be prevented from rejecting valid
messages which happen to have a null return path.
Note that bounces, i.e. error notifications, are not the only type of
message that can be sent with a null return path and so any valid
recipient that receives any e-mail _MUST_ be able to receive messages
with a null return path. If such a recipient does not wish to receive
spam or other junk then said recipient can, and should, use some better
content filtering mechanism that will properly achieve the desired
result without unilaterally rejecting all messages with null return
paths.
--
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@???>
