Keith Moore wrote:
but in most cases this is inherent in the nature of the feature, and
has nothing whatsoever to do with the message format. if you could
add the feature at all, you could do so without changing the message
format and without the disruption that would cause.
This particular discussion is in relation to envelope and protocol
extensions, which has nothing to do with the *current* message format. The
point of this particular discussion is that a message format which
provided envelope data as a separate blob would allow the envelope
extensions to survive blackhole hops.
even supposing that it would be useful to change the format of the
envelope, there's no reason to change the format of the message
that's delivered to the UA.
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.
that may be the only thing *you* care about, but DSNs were designed to
provide a partial response (i.e. the best indication that could
be provided) even if the destination mailer doesn't support them.
what's the point of having such a facility if you don't have a reasonable
assurance of getting a notification when you ask for one?
and in practice destinations sometimes disable NOTIFY=SUCCESS, even
when the MTA supports it, for security reasons.
However, another critical aspect of what I am talking about is that the
transer headers be separated from the message headers and moved into the
envelope blob. That *does* require a new message format.
no it doesn't - you could make this work without any change to UAs
at all. assuming, of course, that there were any benefit to the user
in doing so, which is doubtful.
which user-visible features need this kind of change?
We need a new message format if we want to allow UTF-8 directly in the
message headers.
provides no benefit to users besides minimal bandwidth savings.
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.
a new content-type would solve this problem.
It would also be really nice if we could simply the header rules as part
of this effort. The multitude of header rules currently defined are
obtuse, wildly varied, and prone to significant misinterpretation.
you don't have to change the message format to fix this.
I did a
survey recently of clients that support "Group Names: user1, user2;" and
only 2 out of 10 clients properly handled them.
it's unfortunate that groups often aren't implemented correctly. they
are very useful, and there would be a need for them in a new format also.
Your own client didn't
even generate valid References headers until I pointed it out.
my mail client doesn't generate References fields at all. but it's not
reqiured to do so. if I wanted it to do so, it would be a simple matter
of adding a line to a configuration file.
This
doesn't even take into consideration the multitude of codecs and encoding
forms that people have to deploy.
if the folks doing audio and video can't agree on a small number of codecs
that solve a wide range of problems, I don't see how mail folks can help them.
still, this is just a matter of content-types, it doesn't require a change
to the message format.
Flowing and quoting in body parts would be nice, and would be easier with
a new message format.
first, someone needs to demonstrate that it can be made to work well
by defining a new content-type (or a variant of an existing content-type)
that does this. once that's done, there's no need for a new message format.
Keith