On 4/16/2012 8:38 AM, John Levine wrote:
Of course, if one had a submission server that was smart about these
things, the MUA could hand the message, including the Bcc field, to it and
let it sort out envelopes (which it needs to do anyway) and the warning
message.
That strikes me as a really unfortunate idea. Submission servers know all
about envelopes and message headers. In most cases, they don't know anything
about the body of the message beyond what they can intuit from the MIME
headers.
As noted, this is a scenario that has been supported by some posting MSAs, like
sendmail and mmdf, going back a very long time. My own view is that this is,
nonetheless, an MUA function. That is, for this feature, sendmail and mmdf
were/are acting as MUAs to prepare the message for formal posting, and then they
turn into MSAs.
Note that the function is really the same as most/all MUA's do, when processing
a message themselves for regular SMTP/Submission postings: parse a number of
header-fields as sources for addresses to be used in the RCPT-TO list.
This is a nice demonstration of the difference between network architecture and
software architecture, in which different software implementation choices can
lead to placement of network architecture functions in different modules.
For the scenario being discussed, the "MSA" is actually part MSA and part MUA.
If your submission server adds text to a body saying something like "you are
a blind copy recipient", in what language is that message expressed?
That's a nice example of the basic reason to keep network architectures as far
from user interface design as we can. (chorus: ) Presentation and interaction
design are specialties that are not well represented in protocol development
groups...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net