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

Greg A. Woods wrote:

>>>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.
> No, sorry, but you are _VERY_ wrong -- in complete contradiction with
> the IETF _standards_ for hosts and SMTP.

I wrote "it is no good", not about any standard. Standards should not
suppress to ability to use one's brain.
And as I wrote (and you before), local policies overrule standards. You
consecutively ignoring this won't change it.
This is not always good or convenient (sometimes a real PITA), but the
nice thing about it is that it's more or less a self-regulating system.

> Like I said before there are many other reasons for messages to be sent
> using a null return path other than just being notifications returned
> about mail with cannot be delivered.

You wrote that, but I saw no examples (I might have miss them).

Empty return path means the message is generated by some machine, not a
human, right? So if the recipient address is never used for outgoing
mail, why in the world should any machine send mail to this address?
(I'm not talking about receive-only addresses used e.g. for network
management warnings, this is a controlled environment.)

> If enough idiots break the error handling mechanisms of SMTP then
> Internet e-mail as we know it today will grind to a halt. I see the

IBTD. Most end users today are clueless, they don't know how to handle
bounces and simply delete them. With all the collateral spam around it
got even worse. Sad but true, email today is already an unreliable
service. This is of course no reason to approve further degrading and I
strongly agree with you in condemning the blind rejection of empty
sender addresses. But to came back to the topic: It's not the gun that
kills.

> themselves when necessary, and then how they hold the wrong parties
> accountable for the resulting real-world failures they suffer.

Yes. People already do that, whether you are responsible or not. You
have to check and explain to them anyways. In the end, it's no
difference to them if a bounce message could not be delivered or simply
got delivered to /dev/null on the target system.

> Maybe the demise of e-mail will be a good thing in the long run, but in

I don't think that will happen so soon. For technicians like us it's not
really satisfying to work with imperfect systems, but the systems are
mainly used by non-technicians and they learn how to handle the
deficiencies. After all, it works most of the time, which is "good
enough" for the most.

> notifications. My point to raising this issue here is that it would be
> ever so much easier to do so if the tools they are using were not so
> blatantly accomodating of their abuses.

Come on, if there is _any_ way to break a system, people will find it.
There is no need to blame and insult a tool that is commonly accepted as
a proper and decent piece of software.
Most people break things because a tool is _hard_ to configure, you
complain about Exim's ease of configuration and the consequential ease
of misuse.

>>There is no technical solution, this is a non-technical problem.
> Well as I've pointed out there are technical solutions to the core issue
> of how in-band error handling can be implemented in such a way that
> ignorant admins cannot abuse it;

All I read was commonplaces, nothing concrete.