Re: [ietf-smtp] Characteristics of Isolated (or mostly-isolated) industrial IP Networks

Hector Santos <hsantos@isdg.net> Mon, 06 January 2020 14:13 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49429120816 for <ietf-smtp@ietfa.amsl.com>; Mon, 6 Jan 2020 06:13:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=P7HQJE3A; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=XL0jA5Ma
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 GeJy2fLwJsAk for <ietf-smtp@ietfa.amsl.com>; Mon, 6 Jan 2020 06:13:39 -0800 (PST)
Received: from mail.winserver.com (secure.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A159120842 for <ietf-smtp@ietf.org>; Mon, 6 Jan 2020 06:13:39 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2099; t=1578320011; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=kfwGa1ArcWdm/31sgvF8URZ7Ppk=; b=P7HQJE3AWRNDZlTfwbBtLRAE8UDulM9Q7PEgs5DpKfsRWm78ouokbMIjWbihel 2gIR0Rc1R5PXQ5ok7gz0M+7LAkCNEHlHIRWJjKiyTFm8w2cU22i1DetjfigeJh0A o8DpWo+FiL4KCEDcWv320w8SXyNhjuBMq0IRgq9+BsI1Y=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for ietf-smtp@ietf.org; Mon, 06 Jan 2020 09:13:31 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1932374673.7956.4284; Mon, 06 Jan 2020 09:13:30 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2099; t=1578319827; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=kQt1uoY j3rMJ2tsute5M93tg7Y8nJhibwSgV7tMuYg8=; b=XL0jA5MaEM0FPfC7/ZkkrRS rzwRzxTQAkgDtDSqftxMQZ9Ll80xBNhNt9cTuAr2MofjlXHEMJnzAok+aZ5Ge/I3 IcfeC3NiPiKz8RjiJBPlT03IYa2FvqHEjrn3Itp9kSZ8o0hJ2RjiI4xhspjqVBIZ 9tt+bV3iW/FWUnhy+xME=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for ietf-smtp@ietf.org; Mon, 06 Jan 2020 09:10:27 -0500
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 2495006859.1.7708; Mon, 06 Jan 2020 09:10:26 -0500
Message-ID: <5E134087.80005@isdg.net>
Date: Mon, 06 Jan 2020 09:13:27 -0500
From: Hector Santos <hsantos@isdg.net>
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: ietf-smtp@ietf.org
References: <20200105021840.51DEA11FA155@ary.qy> <e222998e-374f-07aa-024e-2b6fb9d39003@network-heretics.com> <3c50a793-dd26-3254-f9e3-b642793918b7@dcrocker.net> <edcc7d1a-447c-0d49-81d2-84e2b249abdc@network-heretics.com>
In-Reply-To: <edcc7d1a-447c-0d49-81d2-84e2b249abdc@network-heretics.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/bce4f5hCyFSPHDyUI3xuJVJ8Q7U>
Subject: Re: [ietf-smtp] Characteristics of Isolated (or mostly-isolated) industrial IP Networks
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2020 14:13:41 -0000

On 1/5/2020 2:38 AM, Keith Moore wrote:
> On 1/5/20 12:58 AM, Dave Crocker wrote:
>
>>> I suspect ietf-smtp would do better to define the behavior of a
>>> submission service that is designed to accept inbound email from
>>> devices in such an environment
>>
>> The clients in such an environment appear to simply be MUAs.  The
>> submission server appears simply to be an MSA.
>
> The clients might have MTA-like functions like queuing and retry, but
> aren't likely to bounce mail.   From the outside they look a lot like
> MUAs.
>

Hi Keith,

You certainly touched base and highlighted the fact there are both 
legacy and current forms of small footprint and specialized SMTP 
transport clients.

I have a number of these.  One is a proprietary server/client that 
works over a virtual dialup/socket system. Its for our GUI frontend 
"wcNavigator" app that includes a Mail Reader/Writer component (MUA). 
  The connection and thus, its MTA is always authenticated so the 
backend hosting SMTP would be an MSA per se.  The backend is a GUI 
server that contains a smtp server for the gui smtp clients that can 
be a mail client or a game client sending notifications.

The mail client can send reply, forwarded, new messages via an API or 
the backend hosting SMTP server.  When the SMTP method is enabled, one 
mail client uses HELO with no field data and the game client uses HELO 
with the user's name (No verification necessary).  They also use other 
proprietary SMTP commands and attributes that the server recognizes 
such as:

HELO <host.user.info.name>
MAIL CONF:<conf number> [FORWARD:<conf number>;<message id>]
RCPT CC:<receiver-path>
ATCH NAME:<filename> SIZE:<filesize>

But this is within a closed proprietary boundary environment.  The GUI 
MUA/MTA is not going to connect to a general SMTP server.

In my opinion, RFC5321bis should be about the public service port 
where we have unsolicited, anonymous senders and we are basically 
trying to clarify what can be commonly done to strengthen SMTP 
compliancy or maybe perhaps relax it.

Thanks

-- 
HLS