Re: [exim] a large number of domains fronted by Exim are ref…

Greg A. Woods wrote:

> Well it's really quite easy if one separates these things at the
> right conceptual level.

The level _you_ consider right.

> However if messages would be accepted from the client for "valid"
> recipients, then bounce messages MUST NOT be treated specially.

Wrong. If an address never sends out mail, it is no good to accept empty
sender mails to this recipient.

Anyways, it is not your business which mails somebody accepts and which
not. As you said on another topic, local policies overrule RFCs. This
was pointed out to you in this thread by other people, but your "I'm
always right - assimilate my opinion, resistance is futile" filter seems
to work very well, as usual.

> never allow transactions with a null return-path to be presented to
> ACLs.

Bad idea. It would e.g. restrict the usefulness of blacklist.

> The null return path MUST be treated specially since its unique

uh? a few lines above, you wrote
> recipients, then bounce messages MUST NOT be treated specially.

different context, I know. But it shows nicely how you use words in
RFC-like way to give them a factual appearance.

> status is, and always has been, a primary requirement for error
> handling in the SMTP protocol specification and the Internet Host
> Requirements STANDARD.

It IS treated specially, but inband signalling is always prone to
exploitation.
What's your point in insisting on this "error handling" blabla? If
people want to break it, there's nothing you can do about it.
Seems you want to zero the responsibility for undeliverable bounces.
There is no technical solution, this is a non-technical problem.

> messages have a null return path, is broken by design (or at least

Yeah, Exim is bad. You should unsubscribe from this list, it might be
contagious.

> 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.

There are plenty of ways to work around such stupid constraints. You
don't need an expert admin for that, the requirements for using google,
usenet or mailing lists are quite low.

> Either way the clueless admin would be prevented from rejecting valid
> messages which happen to have a null return path.

There is no technical way to reliably determine the validity of a message.