MFT doesn't solve the duplicates problem,
It would for me. (In the case of discussion lists like this.)
I know you have stated that duplicates should be eliminated at the
receiving end. However, this does not work for people like myself, who,
when somebody like yourself replies both to ietf-882 AND to me, want to
get and keep only the LIST copy of the message, not the personal copy.
The point is that these two messages are *not* duplicates. One goes
direct and the other goes via the list explosion process and thereby
gets extra headers added, etc, etc.
Is that really the "point"? i.e. Is that really why you want only the
LIST copy, so you'll benefit from the extra information in the message
header (or - as this happens also - from the removal of information
from the message header that was done by the list)?
If someone replies to a message you sent to a list and (for whatever
reason) the list blocks that reply, do you still want your personal
copy of the message to be blocked also?
I don't want the personal copy. I only want the list copy. Writing
logic
to implement this at my end is not straightforward, since the messages
may arrive in either order and possibly one will be delayed.
Yes, but hopefully you would not have to write the logic yourself.
I want to be able to encode somewhere in the message the equivalent of
"Please don't send me a personal copy when you reply to the list. It
wastes net bandwidth and my time."
IMHO the thing to do is to try to build better interfaces and
encourage
people to try them out.
I understand that people are already "trying out" MFT...
Indeed. And if I build a better interface for people to "try out" it
will have the option of supporting MFT. though it won't support it
blindly, at least not by default.
I suppose I should point out that I view all of this (both the new MUA
behavior and the duplicate processing) as potentially useful
_research_ rather than things that should be widely implemented at this
time. I view MFT in the same category.
Keith