At 16.32 +0100 04-08-18, Nick Ing-Simmons wrote:
The summary just posted explained that MTA has no bussiness
removing Bcc headers. It is a MUA function that happens, on
Unix, to be implemented by another instance of sendmail
binary invoked a particular way.
This is obviously the consensus of the discussion.
But it is not unreasonable that a consenting MUA and MTA
may agree to move part of the burden of the MUA to the MTA,
It is not unreasonable for two entities to agree to such a thing. But these
entities are no longer what we call an MUA and MTA.
like for examples is already accepted that the initital MTA
may add a "Date" header for a message lacking such a
header.
Actually, it isn't accepted for an MTA to do this. It can be done by an MSA,
which is a different beast.
Since MTA meddling with Bcc is highly
controversial, this should of course never be done unless
there is explicit agreement between MUA and MTA to do it
this way. "-t" might be a way of indicating such an
agreement, but only works when submission is done by
execution, which is probably not the most common method of
MUA-MTA communication.
-t causes sendmail to in effect assume part of the role of an MUA. It most
moves things way past what an MTA can or should be doing.
If there is to be a method for an MUA to ask an MTA to
meddle with Bcc, then it is important for this
communication between MUA and MTA is standardized, so that
misunderstandings will not occur, since misunderstandings
can result in embarassing situations.
It would be possible to define a means to do this as part of our MSA SUBMISSION
protocol, but as you say it would have to be negotiated and therefore would in
no way make the present behavior of agents that blithely assume the transport
infrastructure will take care of of bcc issues. These agents are simply broken
and need to be fixed.
And since such an extension would be just that: An extension, MUAs for
the forseeable future could not assume the extension's presence. This means
they'll have to have their own bcc code.
This in turn begs the question of whether or not there is any real advantage to
having such an extension. It turns out there is: An MUA that is either memory
or bandwidth limited could push the message splitting activities over to the
MSA server and avoid having to send the same message multiple times. The price
we pay for this is having code to handle bcc in two places - a considerable
increase in complexity.
Do not interpret the above to mean that I feel such a
standard to be very urgent or important, nor that I am
willing to be editor of it.
I for one have a great deal of difficulty accessing the real need for various
extensions that attempt to cater to the needs of memory or bandwidth limited
clients. Sure, some of these are nobrainers: If you want a cell phone to be
able to forward a feature-length film you gonna need a forward-without-download
facility along the lines of what the LEMONADE WG is developing, and I don't see
that need changing in the forseeable future. But the need for many other
possible extensions, including this one, are not nearly as obvious. I'm just
not sure whre the sweet spot really is.
Ned