On 2004-07-24 at 15:22 +0900, Derek Martin wrote:
> Your contention is a fantasy.
Not the world's greatest method for gaining the cooperation of others.
> Yes, it is. So what? That doesn't preclude the idea that the MTA or
> some other agent can do the right thing and weed out recipients who
> don't need that information.
The problem is that when people start trying to use vague heuristics to
figure out "the right thing", some scenario will get it wrong, often
disastrously so. Just reading the RISKS Digest is enough to make that
clear.
Having software second-guess intentions is a recipe for trouble. The
software which can best determine intent/necessity should do so. If the
MUA knows that somebody is not supposed to see a line, the MUA is in the
best place to enforce it.
> 1. it is known that some mailers expect (something like) this behavior.
In my experience, only mutt, and that can be worked around by adding
"unset write_bcc" in the global Muttrc for a system.
> Since it can do so, it should, whether or not there exists an RFC
> which says it should. It is not an obligation dictated by standards,
> but by common sense and decency.
Actually, I object to software running on my systems being suborned to
the service of someone else, to my detriment. That's not cooperation,
it's taking. If someone's setup means that I get their Bcc headers,
after I've paid for the bandwidth to receive them, then I might as well
get to see what was so important that it got Bcc'd. Mandating support
for the lowest common denominator, to the detriment of the other levels
of competency, is a recipe for decline.
Also, I live in a country where legal interception of email requires a
warrant and the cooperation of the ISP (introduces a nice system of
checks and balances to avoid overly broad intercepts, since the ISP is
still subject to privacy laws, so has strong incentive to reject overly
broad warrants). If I have a warrant for interception against a
customer of the systems which I maintain at work, then I'm legally
obliged to ensure that the tapping mechanism passes along all
information received. If I allow the systems to discard information,
particularly information potentially highly relevant to a pending
criminal case (eg, information about other recipients of email being
sent to someone who is subject to an interception warrant) then I get in
legal trouble. Further, my employer gets into legal trouble, which
endangers my continued employment.
> > And what if the Bcc recipient turns out to be an alias of a mailing
> > list? (For example).
>
> So what if it does? The MTA will deliver it to the mailing list host,
> and the MDA will deliver it to the subscribers of the mailing list.
> The message will contain a Bcc line showing the mailing list address,
> and all the recipients will receive a copy that shows it. What's the
> problem here? The Bcc line still shows the desired information, which
> is how the user came to receive a copy of the e-mail. This is one of
> the concerns raised by Sec. 5 of RFC 2822. Presumably, the user knows
> what mailing lists they've subscribed to... ;-)
Actually, the recipient _won't_ receive a copy showing that. Because
after the mailing-list expansion, the address in the Bcc: header is no
longer the address of the recipient, so some intervening mail-system
(the mailing-list exploder host and/or the customer's own system, at the
very least) will then strip the Bcc: header away, leaving the recipient
without this information.
Unintended consequences can suck.
This is why MTAs need to be very careful about arbitrarily removing
information. Removing information from data in transit can always go
badly wrong; the safest way around this is to have the submitting
software not submit information that it doesn't want to be sent.
--
Phil Pennock, Senior Systems Administrator, Demon Netherlands
NL Sales: +31 20 422 20 00 Thus Plc NL Support: 0800 33 6666 8
