ietf-smtp
[Top] [All Lists]

Re: "proper" handling of BCC

2012-04-17 17:16:06



--On Tuesday, April 17, 2012 15:35 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:

For example, with the many discussions regarding what an
offline MUA may display in RFC5322 headers, it was not an
issue with the Online MUA where the UI display rendering is
100% controlled by the backend. We may even defined with a new
acronym MAS - "Mail Access Server."

The real distinction is based on how much intelligence the MUA
had with the capability and advancement of how much can be
offloaded to the user's device. And FYI, the concept of
offloading data was patented by IBM long ago, long expired of
course, which allowed for rapid growth of offline/offloading
software to be developed.

Hector,

I'm not completely certain I agree.  In the beginning, MUAs were
entirely on host machines and we communicated with them via
terminals or equivalent.  IIR, tools like the original U**x mail
command, its predecessors, and better tools like MH were
developed in/for that kind of environment.  Certainly they were
online, but the concept was a little different from the way we
use the term today.  You, Dave, or others might have different
data, but I first remember the term "split-UA" used for
arrangements in which the work of getting mail to the user was
divided between something happening on the mail store machine
(usually the delivery MTA, but not always) using protocols like
POP, PCMAIL, IMAP, and some arrangements that have passed into
obscurity.  Each of those three originally supported a different
model: "download everything to the client side of the split and
work offline" for POP, "synchronize to the client side of the
split but mostly work offline" for PCMAIL, and "client is online
to the server, often in what we call kiosk mode today" for IMAP.
The issue is less about "how much can be offloaded" than about
styles of working with different situations involving different
mixes of advantages and disadvantages.  (IMAP4 moved beyond that
early split to support all three models -- how well differs by
implementation, but the "split-UA" part of the concept remains.

On the submission side, we had both MTAs that expected to get at
least nearly-adequate SMTP and, among other options,
intermediate MUAs and MTAs that effectively accepted an 822-ish
message body along with an envelope via some API as well as MTAs
that accepted a non-envelope 822-ish message body and tried to
construct an envelope from it.  The latter, IMO, led to lots of
woes, but it was certainly common.     I remember hearing and
talking about those (both originating MUAs/MTAs and gateways)
more in "fix the message before it is injected into the Internet
environment" than in "split-UA" terms although the latter is
certainly a reasonable model for the situation.  Remember that
most "smart" mailing list exploders perform some MUA functions
too.

From that perspective, our explicitly describing submission
servers and giving them equally explicit permission to do
MUA-ish things simply symmetrically recreates the split-UA
situation we have on the receiving side with POP and IMAP: some
MUA-ish work gets done on the client machine, some gets done on
the server machine, and the server machine also has interfaces
to the network and/or mail store.  In both sets of cases, if the
server side of the UA function starts doing things that the
client side doesn't anticipate, seriously bad things can happen.

    john



<Prev in Thread] Current Thread [Next in Thread>