ietf-smtp
[Top] [All Lists]

Re: I-D ACTION:draft-arun-ncc-smtp-01.txt

2004-04-12 10:52:56

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.

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.

The other alternative would be to make this an SMTP extension.

Furthermore, since alias expansion or forwarding can be done at any point
in the signal path, I don't see any way of implementing this functionality
that doesn't present a risk that an excluded recipient can learn that he's
being excluded.   (I note that there's no security analysis in this document.)

If you do it as an envelope extension you could always require bouncing when
the extension isn't present. But this has the effect of making deployment very
nontrivial.

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.

If, on the other hand, the intent is to provide an advisory mechanism to
attempt to block unnecessary message copies in some cases, where it is
understood that the block isn't going to be 100% reliable and where it is
understood that the blocked individual may be aware of the blocking, then a
simple header could be defined. The question then is whether or not such a
mechanism is useful enough to bother. (I have no religion about this personally
- extra copies of messages don't bother me although I realize they bother other
people a lot.)

                                Ned