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@xxxxxxxx> 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