ietf-822
[Top] [All Lists]

Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]

2004-09-06 15:12:06

Keith Moore wrote:

In at least some situations, using a "work" address in messages
sent from "home" or vice versa or similar dichotomies would
likely be looked upon with a jaundiced eye; far worse in some
cases.


Yes, that's true - but I don't think it's up to the mail system
to enforce such rules, any more than I think it's up to the 
snail-mail postal service to check whether a residental customer
is sending out mail on company letterhead.

I'm not suggesting that the mail system as such should implement
such forms of enforcement; merely that some configurations do
so.

The reason we're having these problems is because of overloading
of various fields - reply-to, from, sender, mail from - to the
point that they've become ambiguous.  I suspect we're not going to solve
the problems without discouraging some of the overloading.  And that
in turn probably means we'll have to define some new ways of doing 
some of the things we used to overload these fields for.

Not merely header fields are overloaded, as discussed on mail-ng,
the message header itself is overloaded.  From a start (RFC 56)
where it consisted of author-specified front matter, it has had
various other functions -- transport trace information (Mail-From,
Received, Return-Path), recipient MUA directives
(Disposition-Notification-Options, Disposition-Notification-To),
sender front matter (List-*), body metadata (most of the MIME
fields), magic tokens for gateways (most of the MIXER fields),
and more than a little cruft (primarily marketing fluff such as
Posting-Version, User-Agent, etc.).  To the point that it's
nigh impossible to separate them (see the recent list message
regarding Resent-Message-ID and message/partial for a hint). I
don't think it's possible to provide a clean solution short of
a new design that takes into account the lessons learned in the
past three decades.


<Prev in Thread] Current Thread [Next in Thread>