Keith Moore wrote:
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.
Part of my argument is that they were designed that way *partially*
because the current envelope-exchange environment requires it. I fully
appreciate the fact that a relay will tell me that the message has made it
as far as X because Y refuses to play along.
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?
I agree that this is a valid concern and a hard problem. I do not think it
is unsolvable, nor do I think it is so much of a concern that it overrides
all of the other potential benefits.
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.
You don't think UTF-8 in Received header fields would benefit admins who
have to deal with email from International sources?
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.
Using something like the XML structured approach, it is simple enough to
define all recipients as groups:
<PrimaryRecipient>
<DisplayName>Local Admins</DisplayName>
<Mailbox>fred(_at_)local</Mailbox>
<Mailbox>joe(_at_)remote</Mailbox>
</PrimaryRecipient>
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
I'm talking about header field codecs. 2047, 2231, etc.
Flowing and quoting in body parts would be nice, and would be easier
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.
Whether or not it needs (or benefits from) a new message depends on the
necessary support services. You can do both of those today with HTML if
you are willing to live in the current framework.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/