At 10:43 04/05/2002 -0500, Eric A. Hall wrote:
Keith Moore wrote:
DSNs with NOTIFY=SUCCESS are an obvious example. The only thing I care
about is that delivery succeeds, meaning that this is a negotation between
the originator and the delivery server. The submission server and any
relays in between are completely irrelevant, yet due to the current
envelope-exchange design, they dictate the success of that feature.
Well, the OBVIOUS answer to that, is to take the DSN information out of the
envelope and put it into the header. This won't break any existing MTAs,
and the header gets passed through and ignored any MTA which doesn't
understand it.
There is probably a good reason why this isn't done, but it'd work with the
existing infrastructure, so maybe that should be investigated as an option..
A worry I'd have about having an 'envelope blob' is that people might start
using that as an alternative to the header for other things (after all,
there's really NOTHING in the message header that you couldn't put into the
'envelope' if you wanted to, and if it was capable of handling it...). Non-SMTP
We need a new message format if we want to allow UTF-8 directly in the
message headers. You will probably argue that a UI facade will work just
as well for this, but you will be wrong.
Do we want UTF-8 directly in the message headers ENOUGH to break everything
else?
We need a new message format if we want to be able to encrypt the full
message (message headers and body, rather than just the body), since the
commingling of transfer and message headers prevents that now.
Hmm - what 'headers' are we talking about here. The only one which would be
worth encryting would be the subject - the recipients have to be stored in
plain text in the envelope anyway, the date is approximately deducable, and
other header fields may be needed to be used by the MTA/MUA automatically
anyway (eg priority). Surely encrypted subject lines could be handled some
other way rather than breaking everything else.
As single items, none of those warrant a new message format. Collectively
(especially with other benefits that become viable with a new format, as
with the envelope modifications above), they do warrant it.
> > On the other hand, what is it that is not feasible about a new
> > message and transfer service?
>
> 1. getting users to buy into it when it is disruptive and it doesn't
> provide them with any immediate benefit.
If the features were desirable and it simplified implementation, people
would use it. It wouldn't happen overnight, we can agree on that.
But when WOULD it happen? Because it wouldn't happen overnight, all the
MTAs/MUAs would have to be able to fall back to the existing mode (with
possible message reformatting being done by MTAs (thus possibly breaking
things)).
The example of DSN shows what a problem it will be. DSN has been around for
more than 6 years, but lots of MTAs don't support it. I suspect that in
another 5 or 10 years time there will still be MTAs which don't support it,
and can you guarantee that in 20 years time there STILL won't be MTAs which
don't support it?
So, does this mean that all MUAs/MTAs would have to support BOTH message
format structures (or just the existing format..) for the forseeable
future? Not only that, but MTAs which support the proposed format would
have to have the ability to convert the proposed format into the existing
format reliably, so they'd be made even more complex than ever.
Paul VPOP3 - Internet Email Server/Gateway
paul(_at_)pscs(_dot_)co(_dot_)uk http://www.pscs.co.uk/