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

[John Levine <[e-mail]>]

It appears that John C Klensin  <[e-mail]> said:
>> 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. ...

That's a distinction without a difference. I have a mail to nntp
gateway that take mail with addresses like alt.flame@news, drops each
message into a a file in a directory, and then a daemon checks the
directory every few minutes and feeds the messages into the matching
newsgroup in the news server. Is that directory one mailbox, many
mailboxes, no mailboxes? I have no idea and I don't think anyone else
does either.

Nevertheless, ...

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

There is probably still someone, somewhere, that uses a mailbox as a
printer gateway, so I agree.

>> The current text reads:
>>
>> Care needs to be taken when displaying messages on a terminal
>> or terminal emulator. ...

Well, yes, if you're still using a model 35 Teletype, and the message
contains ^L^L^L^L^L^L^L^L^L^L^L^L that could be pretty exciting.

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

>> Care needs to be taken when storing and displaying messages.
>> Many messages intentionally contain content that is designed
>> to inflict harm on the recipient, ...

To me the obvious example is HTML full of malicious javascript. It
seems to me that the display issues for mail are no different than
they are for web pages or downloaded PDFs, so the whole section can be
shrunk to a sentence noting that mail can contain the same kinds of
active content that you get from other places and applications that
display mail should take the same precautions they take when they
display anything else.

R's,
John