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

Hector Santos <hsantos@isdg.net> Mon, 31 March 2014 17:46 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2FF1A6F29 for <ietf@ietfa.amsl.com>; Mon, 31 Mar 2014 10:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.002
X-Spam-Level:
X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV87n7eE7EQO for <ietf@ietfa.amsl.com>; Mon, 31 Mar 2014 10:46:52 -0700 (PDT)
Received: from winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7954F1A6F05 for <ietf@ietf.org>; Mon, 31 Mar 2014 10:46:52 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4594; t=1396288004; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=U5853sv4so5OqQPTHjQ5GAXc5OY=; b=Z/VmEdjR1NAyDcVhSCfg QDqXYy9hlmhH9fm0lhZkzrtyBmVuTYreJDiWb583bbk4VOxS7ld67q0X5vmsbs7/ e0BrGZt3OmR1Rpmz4Q2ukyAcW00xN7lbmrO5q5k9w77rkvkCi+MfTP2vXS4Y+ivX vLI2kYEUAE7to7K9efet+BI=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Mon, 31 Mar 2014 12:46:44 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1275463185.12698.1568; Mon, 31 Mar 2014 12:46:42 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4594; t=1396287960; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=j7PrlD1 XC5MRrC4miYCqsQS5g8hkY6FTUmwT//r44HU=; b=vioDa2wOvNHhkfGBeycd2Zl cAPLLrzCFr/6lhhlOP9Q+MJJPdK25PLutwqjBFoNe8Rz9TU9TCmar99YPxk+ummi ULFCgecoMxTmk0ekV2P0SVgthBDWpHVo04ebHkrY0P15tTVBjSjNyg+eJz7qWCjo pERS69JXC9ENp9L622O0=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Mon, 31 Mar 2014 13:46:00 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 721715444.9.17396; Mon, 31 Mar 2014 13:45:58 -0400
Message-ID: <5339A9FD.6030403@isdg.net>
Date: Mon, 31 Mar 2014 13:46:37 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, Christian Huitema <huitema@microsoft.com>, Scott Brim <scott.brim@gmail.com>, IETF discussion list <ietf@ietf.org>
Subject: Mail System Reliability [was: Re: SMTP RFC: "MUST NOT" change or delete Received header]
References: <mailman.1570.1395964793.2468.ietf@ietf.org> <53366F34.8050501@ageispolis.net> <5336979B.6000102@cisco.com> <0AF4D5B8-C99C-4944-87FA-A458D6CE67D9@nominum.com> <5336F1EF.1020203@dcrocker.net> <CAPv4CP9nFmYfondSrqA7ETkhvCMe4YrqRjOdGZuPiLz2kZzXrw@mail.gmail.com> <5336F9A8.5050305@isdg.net> <775a8b23bb97437992aa191457a1225b@BLUPR03MB424.namprd03.prod.outlook.com> <53395831.6060801@isdg.net> <6359FB036ECCAFC049098D59@JcK-HP8200.jck.com>
In-Reply-To: <6359FB036ECCAFC049098D59@JcK-HP8200.jck.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/zcXAEQb_aIuDjFH54BS7PXGic0U
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Mar 2014 17:46:55 -0000

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