On Mon, 12 Apr 2004 10:36:54 PDT, ned+ietf-smtp(_at_)mrochek(_dot_)com said:
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.
That has possibilities, but....
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.
Remember - all it takes is one bozo with a broken/old MUA to do a 'reply all',
and the game is over (the same information leakage issues as the Bcc: issues
discussed in the second paragraph of RFC2821, section 5 (security
considreations)).
Trying to reliably make sure that person A doesn't find out that person B got a
copy of a mail is, in general, a lost cause.
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.)
Personally, I just filter duplicates based on Message-ID - but that's a total
non-starter for people who don't have essentially free last-hop bandwidth.
If we're trying to provide advisory eliminate-dups, then a better thing to do
might be to dust off Bernstein's Mail-Followup-To: proposal from http://
cr.yp.to/proto/replyto.html - that's already got *some* MUA traction deployed,
and I know of several other MUAs that don't support it mostly because it was
never progressed down the RFC path.
pgp6XrLKoSqUj.pgp
Description: PGP signature