I condsider it completely unacceptable to expect a message header
field to modify envelope information, with or without an SMTP
extension.
I agree, except I wouldn't phrase it this way. What's unacceptable is
for active envelope information to appear in the header. As a
practical matter, header information is used to create or modify
envelope information all the time: This is precisely what an MUA does
when composing a reply.
When an MUA composes a reply, it's creating a new envelope rather
than modifying an existing one of a message in transit. That and the
sender of that reply gets to decide whether or not each of those
addresses actually belong in the envelope of that reply.
This makes me wonder if a modified version of this proposal would be
acceptable. Suppose the applicability of ncc was limited to list
processors. We've long argued that list procesors operate at the MUA
level and not at the MTA level. A mechanism that provides information
to a list processor(specifically, it tells it to exclude certain
addresses from the expansion) could legtimately be done with a header.
Yes, it could be done that way without a layer violation, and there's
certainly nothing to stop a list from recognizing an Ncc field and
interpreting it however it wishes. However it still doesn't strike
me as something that is generally desirable.
More generally, I'm not sure that this is desirable in general. If
a particular list wants to provide people with an option to mail to
the list while still excluding some people (and I have occasionally
seen a need to do this) then perhaps the list could provide a web
interface for that rare purpose. I don't think it's worth defining
an SMTP extension.
The real question here is what this mechanism is intended to be used
for. (The draft really doesn't say.) If the intent is to provide a
security mechanism where specific people are reliably prevented from
receiving mail as well as being prevented from seeing that they were
excluded, then an SMTP extension is the only way to do it and the
chances of deployment are negligable.
I don't even think you can do that with an SMTP extension. At each
hop that the message traverses there is an opportunity for one of the
addresses to be aliased to a forbidden address, so you need to propogate
the NCC information as far as possible. But if you do that, you run
the risk of propagating NCC all the way to an SMTP server that is
controlled by the forbidden recipient, who can then make note of the
NCC request.
If, on the other hand, the intent is to provide an advisory mechanism
to attempt to block unnecessary message copies in some cases
Duplicate message suppression is a complex problem. If we're going to
try to addresss it, we need a lot more thought before choosing a mechanism.
--
Regime change 2004 - better late than never.