Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc5322bis-03

[John C Klensin <[e-mail]>]

Todd,

--On Friday, May 6, 2022 13:29 -0400 Todd Herr
<todd.herr=[e-mail]> wrote:

> On Fri, May 6, 2022 at 12:30 PM Alexey Melnikov
> <[e-mail]> wrote:
> 
>> On 06/05/2022 15:32, Todd Herr wrote:
>> 
>> 
>>    - Section 3.4, second paragraph - "A mailbox receives
>>    mail. It is a conceptual entity that does not necessarily
>>    pertain to file storage. For example, some sites may
>>    choose to print mail on a printer and deliver the output
>>    to the addressee's desk." Do we still think this is true?
>>    Perhaps a more timely example would be better, or just
>>    strike the last sentence entirely?
>> 
>> I think the example demonstrates what is meant by "not a file
>> storage", which I like. I think such systems still exist.
>> 
>> Can you suggest a better example?
>> 
> I just believe that with the widespread proliferation of
> remote workers, the idea of printing a message and having it
> delivered to someone's desk is antiquated.
> 
> Here's my proposal for a better example:
> 
> A mailbox receives mail. It is a conceptual entity that does
> not necessarily pertain to file storage. For example, a
> mailbox may be nothing more than a gateway to a
> customer-support ticketing system, where a mail message
> triggers one or more actions for customer-support staff to
> take.

Well... The existing example may be a bit archaic, but it is
certainly clear.  The problem with the alternate example is that
there have been many systems over the years in which the mail
infrastructure is used to trigger some command-like action at
the receiving end but have done that directly out of the "final
delivery" SMTP server function rather than involving conceptual
mailboxes at all.  Indeed, as you probably know, while the
practice as controversial, before MIME was introduced there was
no established requirement that the "mail data" carried by SMTP
have 822 / 2822/ 5322-conforming header fields at all.

While I think we could work the proposed example out so that it
would not raise any issues but, if the principle of minimal
change applies to 5322bis as well as 5321bis, I think this
should be left alone. 

> [snip]

>>    - Section 5, Security Considerations. The thoughts here
>>    are certainly valid, but the text makes lots of references
>>    to risks to terminals and terminal emulators, and even I
>>    at my advanced age have but a foggy recollection of using
>>    such things. Can/should the language be updated to
>>    reference equipment that is much more likely to be used by
>>    current and future readers of this document?
>> 
>> I have noticed this text, but decided that it is not worth
>> changing, because it is still correct. And there are
>> certainly implementations like "pine" that would care about
>> terminal emulators. So personally I would not delete this
>> text.

See above about minimal change, particularly wrt text that is
correct even if somewhat outdated.  There is a separate argument
for changing this (see below), but I'm not sure it is persuasive.

>....

> The current text reads:
>
> Care needs to be taken when displaying messages on a terminal
> or terminal emulator. Powerful terminals may act on escape
> sequences and other combinations of US-ASCII control
> characters with a variety of consequences. They can remap the
> keyboard or permit other modifications to the terminal that
> could lead to denial of service or even damaged data. They can
> trigger (sometimes programmable) answerback messages that can
> allow a message to cause commands to be issued on the
> recipient's behalf. They can also affect the operation of
> terminal attached devices such as printers. Message viewers
> may wish to strip potentially dangerous terminal escape
> sequences from the message prior to display. However, other
> escape sequences appear in messages for useful purposes (cf.
> [ISO.2022.1994
> <https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322b
> is-03.html#ISO.2022.1994> ], [RFC2045
> <https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322b
> is-03.html#RFC2045> ], [RFC2046
> <https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322b
> is-03.html#RFC2046> ], [RFC2047
> <https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322b
> is-03.html#RFC2047> ], [RFC2049
> <https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322b
> is-03.html#RFC2049> ], [BCP13
> <https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322b
> is-03.html#BCP13>]) and therefore should not be stripped
> indiscriminately.

FWIW, it seems to me that, at the level that 5322bis is talking
about, its function wrt non-header content is to be sure that
whatever such a system receives gets into the mailbox.  MIME
goes a bit further, but only a bit.   A discussion here --even
as a Security Consideration-- of what "Message viewers", other
message display functions, or other MUA functions, might do
seems out of place and problematic.  

Less philosophically, the introduction of 8BITMIME, text/plain
content types with charset="UTF-8", and the SMTPUTF8 (EAI) work,
especially RFC 6532, into the mix, the above seems rather
seriously dated and to say either too little or far too much.

> I wonder if perhaps something like the following would work
> better?
> 
> Care needs to be taken when storing and displaying messages.
> Many messages intentionally contain content that is designed
> to inflict harm on the recipient, the device being used to
> read the message, the network to which the device is
> connected, or some combination of these. This harm could
> involve, but not be limited to, remapping of the keyboard used
> with the device, credential and/or PII theft, denial of
> service, or even damaged data. Message handlers and message
> viewers may wish to strip potentially harmful content from the
> message prior to storage or display.

It seems to me that substitution would replace some rather
specific (if outdated and maybe incorrect) text with handwaving.
Stripping "potentially harmful" content ("potentially" implies
some plausible chance of false positives), especially before
storage, is not necessarily an improvement.  In particular, if
gotten wrong, it risks destroying information the user was
expecting.  Even if gotten right, if applied at the 5322bis
level (e.g., without knowledge of MIME and specific contents
types), it could even interfere with attack reporting mechanisms
and hence pose a risk to mechanisms that are intended to improve
security.

I have no recollection of why this text went into 2822 (5322 is,
at least superficially, just a copy).  Pete might know and be
able to tell us, but my guess is that we decided during DRUMS
that it was important to say something and that this was the
only plausible place to put it.  That is no longer the case.

Suggestions:

Alternative 1: Apply the principle of minimal change, decide
that, even if this is wrong, it isn't seriously wrong, hold our
noses and leave it alone or make absolutely minimal changes to
correct actual errors or changes since 2822.

Alternative 2: Pull this whole discussion out, put a section
into the A/S about things about which MUAs, display functions,
and the like need to be aware, and then discuss the topic there
in enough detail to actually be useful rather than merely
letting us feel good about having warned people.

best,
   john