Subject: [Emailcore] Gatewaying references

From: Julien ÉLIE <[email-masked]>
Date: Sat, 26 Dec 2020 10:55:55 +0100

Hi all,

About gatewaying, couldn't explicit references to other RFCs be added?

I would especially see RFC 5537 (Netnews Architecture and Protocols) 
that could be worth referencing.  Notably its Section 3.10 "Duties of a 
Gateway".
It contains useful information about outgoing and incoming Netnews 
gateways, that can be read in conjunction with Section 3.7 "Mail 
Gatewaying" of RFC 5321.

Possible places where to mention Netnews gatewaying in RFC 5321:

* Section 2.1.  Basic Structure

    An SMTP server may be either the ultimate destination or an
    intermediate "relay" (that is, it may assume the role of an SMTP
    client after receiving the message) or "gateway" (that is, it may
    transport the message further using some protocol other than SMTP).

* Section 2.3.10.  Originator, Delivery, Relay, and Gateway Systems

    [[CREF7: [5321bis] [[Note in draft/Placeholder: There has been a
    request to expand this section, possibly into a more extensive model
    of Internet mail.  Comments from others solicited.  In particular,
    does RFC 5598 make that suggestion OBE?]] ]]

Naturally, references to other protocols gatewaying mails could be added 
too.

-- 
Julien ÉLIE

« Je suis né trop tard dans un monde trop antique. » (Astérix)

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Dec 2020 08:34:23 -0500

Julien,

(speaking as an individual)
I am very hesitant about starting to reference other protocols
in 5321bis, especially at a time when we are talking about
changing or removing discussion of other transports (see G.13).
Even if one went down the path of using mail systems as
examples, Netnews might be a particularly difficult example.

It might be interesting to have an an annotated bibliography of
documentation of email conventions or protocols but I don't
think that belongs in 5321bis either.  Perhaps in the A/S, but
my guess is that it really should be a separate piece of work
(if only because of the time it is likely to take).  Have you
considered writing one?

But others may disagree.

    john

--On Saturday, December 26, 2020 10:55 +0100 Julien ÉLIE
<[email-masked]> wrote:

> I would especially see RFC 5537 (Netnews Architecture and
> Protocols) that could be worth referencing.  Notably its
> Section 3.10 "Duties of a Gateway".
> It contains useful information about outgoing and incoming
> Netnews gateways, that can be read in conjunction with Section
> 3.7 "Mail Gatewaying" of RFC 5321.
> 
> Naturally, references to other protocols gatewaying mails
> could be added too.
> 
> -- 
> Julien ÉLIE
>

---

From: "John Levine" <[email-masked]>
Date: 26 Dec 2020 11:13:35 -0500

>But others may disagree.

Even though I run a netnews gateway, I agree with you. Gateways are a
pretty marginal feature these days, and the details are quite specific
to what's on the other side. If I were going to use an example it
wouldn't be netnews since it's too sasy, since its message format was
deliberately designed to be almost the same as 822.

R's,
John

---

From: Julien ÉLIE <[email-masked]>
Date: Sat, 26 Dec 2020 18:10:58 +0100

Hi John,

> changing or removing discussion of other transports (see G.13).

All right, thanks for your answer.

> (if only because of the time it is likely to take).  Have you

I still have not considered writing one.
What I had in mind with my remark about gatewaying was not that 
extensive but only 5 lines max, just to give more substance to the 
following sentence, giving examples of gateways.

I'm fine with not changing anything.  It's just a detail.

-- 
Julien ÉLIE

« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Dec 2020 12:48:45 -0500

--On Saturday, December 26, 2020 18:10 +0100 Julien ÉLIE
<[email-masked]> wrote:

>> It might be interesting to have an an annotated bibliography
>> of documentation of email conventions or protocols but I don't
> What I had in mind with my remark about gatewaying was not
> that extensive but only 5 lines max, just to give more
> substance to the following sentence, giving examples of
> gateways.
> 

Understood.  Let me borrow from John Levine's comment to further
explain why I'm reluctant to start down that path.  If one were
to pick a single example, the Netnews gateway would probably not
be it because it was designed to use 822-like headers.   If one
did this, one might prefer to use a come complex  In addition,
it is essentially a redistribution service not user to user
email on both directions: discussing it would possibly drag us
into issues with rewriting backward-pointing addresses.
Because it is really interpersonal mail rather than distro lsit
to person or person to distro list and while it is little used
today, one might want to cite RFC 2156 and some of the
supplemental specifications instead or in addition to Netnews.

The reason for going into the above is not to push back on your
specific suggestion, just to point out how complicated simple
and seemingly-obvious suggestions such as yours can get very
complex (and expand well beyond five lines) very quickly.
 
> I'm fine with not changing anything.  It's just a detail.

Thanks.
    john

---

From: Ned Freed <[email-masked]>
Date: Sat, 26 Dec 2020 11:31:43 -0800 (PST)

> pretty marginal feature these days,

Actually it's just the opposite - far from vanishing, email gatwways have gone
mainstream. The obvious example is gateways to and from various notification
services, but application gateways are also fairly commmon.

What has gotten marginalized are gateways to things the IETF has taken
to be within its purview, including other email systems and netnews.

> and the details are quite specific
> to what's on the other side.

In some senses yes, others not so much. You have to think pretty generally when
you gateway to something that in turn connects to all sorts of other stuff.

> If I were going to use an example it

Gateways are interesting architecturally because of the different ways they can
interact with submission and final delivery. But since we can't even get
agreement on how to deal with these things within the homogeneous email world,
I think this is a potential rathole we'd best steer clear of.

And aside from noting they exist, I don't really see them as being in scope
for the core email specifications.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Dec 2020 12:08:00 -0800

> for the core email specifications.

Exactly.

SMTP provides a basic relaying capability, within a homegenous service.

The SMTP specification is not the place for broader discussion of all 
things email.

Let's get clarity about the scope of this document -- hopefully a narrow 
scope -- and remove portions that are outside of that.  Gatewaying (and 
mailing lists, and...) are obvious examples.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 26 Dec 2020 15:25:36 -0500

> to be within its purview, including other email systems and netnews.

You are certainly correct.  On my tiny system I have at least a dozen 
service gateways to things that do stuff with the message contents, but 
only the mailing lists pass them along as something like a message.

> for the core email specifications.

Yup.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ned Freed <[email-masked]>
Date: Mon, 28 Dec 2020 06:14:50 -0800 (PST)

> mailing lists, and...) are obvious examples.

I'm afraid I have to disagree. Getting rid of any specific discussions about
gateways is fine because that can, and should, be left to the specifications
for those gateways, e.g., RFC 2156 and RFC 5536.

But this doesn't work with mailing lists. You might, and I emphasize might, be
able to get rid of discussion of mailing lists if there was a separate
standards-track document specifying how they operate them that could be
referenced. But AFAIK there isn't, and like it or not, mailing list are deeply
ingrained in the fabric of the current email service.

This is a practical concern, not a theoretical one, and no amount of
architectural maneuvering can eliminate it.

The only approach I can think of given the current state of the standards that
could possibly make it acceptable to eliminate the discussion of mailing lists
would be to reference the descriptions of mailing lists in both RFC 5321 and
the NOTARY specifications. But I have to say I find the idea of doing this
extremely distasteful.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Dec 2020 09:49:54 -0500

--On Monday, December 28, 2020 06:14 -0800 Ned Freed
<[email-masked]> wrote:

>...
> The only approach I can think of given the current state of
> the standards that could possibly make it acceptable to
> eliminate the discussion of mailing lists would be to
> reference the descriptions of mailing lists in both RFC 5321
> and the NOTARY specifications. But I have to say I find the
> idea of doing this extremely distasteful.

Specifically, removing the text from 5321bis but referencing
5321 would imply that 5321bis could not properly obsolete 5321
_and_ would make it harder for people to answer the questions
"what are the core email specs" and "to what is conformance
specified".  To me, that would cancel out most of the purpose of
this exercise.  Put differently, instead of doing 5321bis, we
could create a new document specifying only changes to 5321 and
then move them to Internet Standard as a pair, still creating
more complexity for the reader, but at least not confusing as to
status.

And, btw, I agree with everything else Ned wrote.

   john

I agree with everything else

---

From: Hector Santos <[email-masked]>
Date: Mon, 28 Dec 2020 13:33:21 -0500

On 12/26/2020 2:31 PM, Ned Freed wrote:
> services, but application gateways are also fairly common.

+1, email gateways continues be used in all sorts of ways, besides 
just email to nntp (NetNews).  We still allow for non-SMTP transports 
using UUCP-style Inbound (X/D) / Outbound (XQT/CMD/DAT) queuing system.

In terms of Mail Gateways, we will always have a need for 
transformation support for heterogeneous mail/file/data networks.  Not 
everything is 822/2822/5322 format and in growing instances and needs, 
you don't need the the massive growing overhead in RFC5322 headers, 
and its not even necessary overhead anymore but junk and bunch of 
tracers that when things are normal, its redundant overhead.

IMO, what has been #1 requirement or need to make a gateway work is 
the make sure there is a two-way network reply protocol in place, 
regardless of the transformation which may contribute to impurities.

So identification and outlining the key mail identities for the 
transformation would be a useful exercise for this work. Imo, these 
are essential mail identities for the basic mail I/O conversation:

   Date:
   From:
   To/cc:
   Subject:
   [Network-Reply-Address]
   [Network-To-Address]

The network addresses could be hidden if not shown in Display.  We did 
this for Fidonet, QWK, UTI and other networks like the RFC822 format. 
  We now have RFC5322 becoming the essential format to use, to display 
and also transport data and we have pressures to use JSON or XML 
formats too. What about this JMAP?  I haven't been involved but it 
seems there is a push there.  Before that can prosper, it will need to 
deal with backward compatibility and gateways as well.

Overall, I welcome this exercise in discussing "Gateways."  What are 
the new identities legacy systems may have to deal with?

PS: I had this public email to nntp (NetNews) gateway for a long time 
(more than 10 years) for the IETF Drafts.  This is how I see this and 
browse the drafts.

news://publicnews.winserver.com/ietf-drafts

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos