Mail System Reliability [was: Re: SMTP RFC: "MUST NOT" change or delete

My point is that today, the technical advancement is such that is 
there clear cut technical advancement and understanding of what it 
takes to setup a proper and compliant mail system. We know what works. 
We know what doesn't works. We know what to avoid. We know what is 
expected to happen in the mail flow for practically every situation, 
etc. It isn't a guessing game anymore.
If this isn't the case, then we have wasted our time in the past three 
decades. What have we been doing?  What are we producing and selling? 
I don't believe SMTP is a "Cross your Fingers" mail transport protocol.
Of course, when it comes to the specific mail applications, there is 
going to be different mail delivery efficiency levels, e.g.; DMA 
vendors, spammers, etc, will experience a higher rate of undeliverable 
and/or not getting to user's eyeballs.  These are deliberate actions 
must of the time, and in advanced systems, automated.
But we simply don't expect unreliable protocol communications to 
happen in  professional or business networking markets where 
communications is highly expected to be reliable. When there is a 
problem, it is usually addressable.  I would suggest that those 
problems are few and far between.  (Not speaking of spam filters, but 
again, that is intentional).
Of course, we have the rare "hard nose" local system operators that 
will reject and do things differently than most, but generally it is 
not the norm and we don't usually follow them as the norm. Even when 
it may include one or two key IETF contributors with such a different 
"ownership" philosophy, we make note that they exist and also note it 
is possible Mail Delivery is not always guaranteed.  But I would 
suggest that would be the exception, not the rule.
Again, I think if communications was unreliable across the board for 
all markets, I believe many of us would of moved on to other product 
development careers.  It wouldn't be the same.  I have always expected 
a high degree of reliable communications, in the protocol logics that 
make it all work, dynamically or delayed, store and forward, etc.
Its the same idea here with the IETF list; you and I expect the mail 
to be delivered and distributed. I expect a high reliability in the 
procedures and steps that are known to occur.  We can't live in a 
world where crossing fingers is the norm.  When there is a problem, 
there are no gremlins. There is an explanation and its resolvable.
Perhaps a dumb analogy, is like a DEBUG vs RELEASE compiled 
production.  Once you have a certain confidence in your reliable code 
in release form, you don't need all the debugging statements to help 
you solve problems.
--
HLS


On 3/31/2014 8:47 AM, John C Klensin wrote:
> --On Monday, March 31, 2014 07:57 -0400 Hector Santos
> <hsantos(_at_)isdg(_dot_)net> wrote:
>
> > ...
> > The only time any of this is needed is when there is a tech
> > support issue.  In my opinion, communications reliability has
> > improved over the years where the overhead items are less
> > necessary.
> Actually, I disagree.  While one could develop measures based on
> a series of conditions being met, I think that "communications
> reliability" can only be measured and reported in some way that
> reflects the fraction of messages that leave an origin point
> that are fully accounted for (i.e., by being delivered or
> non-delivery being adequately reported).  Messages that simply
> disappear lower that estimate.
>
> Independent of the reasons why quietly discarding messages may
> be entirely justifiable, the decisions of the last several year
> to do that reduce communications reliability relative to the
> time when senders could be assured that messages would either be
> delivered or returned (or rejected if the distinction is
> relevant).   If one comes up with a definition of "legitimate
> message" and defines "communications reliability for legitimate
> messages" the numbers would obviously be better but, absent very
> broad consensus about that definition or 100% accuracy in
> decisions about what to discard --two conditions I believe are
> very unlikely to be satisfied, but YMMD-- the reliability
> estimate is still almost certainly down from the period before
> spam and malicious mail became major issues.
>
> > ...
> > So do we turn it off?  Perhaps not, the software would evolved
> > where it would be recorded -- somewhere, but maybe not further
> > distributed downlink.
> For part of the answer, see earlier comments about message
> submission.
>
>      john
--
HLS