Am 01.11.06 14:32 schrieb(en) Peter Bloomfield:
I noticed that the RFC frowns on setting Bcc: from a mailto: URL, but Balsa allows that (also Cc:). Why setting an address field like Bcc: is bad, but setting To: is OK, isn't clear to me--but should we disable Bcc:-handling?
See section "7. Security Considerations" - there is not much insight available, though. Thinking a little more about a possible scenario in which a message should be generated automatically (e.g. from a web page link), only To:, Subject: and the initial body make sense. An attachment might be critical as you already pointed out.
As some MUA's do a bad job displaying selected headers and/or attachments, this is probably the main reason why the RFC doesn't define it or discourages it's use. Even in balsa it is possible to hide the Bcc: entry. In such a case, information my be leaked to the bcc destination without the user even recognising that fact. OTOH, I guess no one will ever hide the To: and Cc: entries.
Therefore, IMHO if we are looking at the real life use cases, using Bcc: doesn't make a lot of sense. And I think your idea of showing a dialogue for attaching a file instead of blindly adding it to the message is a good idea. Maybe we should also show a warning if either a file not below the user's $HOME (e.g. /etc/passwd) or if a config file (e.g. ~/.gnupg/secring.gpg - extremely bad!!) would be attached.
Cheers, Albrecht.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Albrecht Dreß - Johanna-Kirchner-Straße 13 - D-53123 Bonn (Germany)
Phone (+49) 228 6199571 - mailto:albrecht dress arcor de
GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc
_________________________________________________________________________
Attachment:
pgpNDwPVmRkhe.pgp
Description: PGP signature