Keith Moore wrote:
Part of my argument is that they were designed that way *partially*
because the current envelope-exchange environment requires it.
I don't really think so.
I consider the Relayed action an admission that the infrastructure refuses
to play along. It is certainly a useful message but one that is required
partially because there is an infrastructure requirement at all.
If the first-hop submission server is always generating Relayed messages
because the firewall doesn't understand the envelope extensions, how
useful is NOTIFY=SUCCESS really.
SMTP is a lot like IP. It even has a miniature ICMP (in the form of
delivery failures messages). Except in the case of envelope extensions,
where the analogy would be that every router has to upgraded for every new
IP option.
You don't think UTF-8 in Received header fields would benefit admins
who have to deal with email from International sources?
let's put it this way - I get a lot of spam from international sources,
and the domain names in the received headers aren't very useful as it
is. how much more useful will they be in utf-8?
How much more useful would they be for network admins who don't speak
english as a primary or secondary language? ACE gobbledygook doesn't help
those administrators one iota.
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>
that's just great. you've more than doubled the amount of space that
this one header would require
As opposed to the complexity that the existing spec mandates, which the
majority (not the plurality, the majority) cannot seem to implement
you haven't added a shred of functionality
Group addresses working for all fields at no additional development cost
isn't an improvement?
and you've made headers considerably more difficult to read than at
present.
I would suggest that the encoding above is much simpler and cleaner than a
group address with multiple ACE sequences.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/