Hallo,
wenn ich mit dem Mutt eine Nachricht versende, und dort BCC mit drin habe, ist alles Ok, die zusätzlichen Empfänger tauchen in keinem der Header auf, so daß diese wirklich BCC sind. Wenn ich aber diese Nachricht (im Mutt) mit ``gpg'' verschlüssle, dann sehe ich der verschlüsselten Nachricht an (mit ``gpg'', für welche Empfänger (eben für den eigentlichen und die BCCs) verschlüsselt wurde.
Kennt jemand diese Feature? Ist es ein Bug? Oder gibt's eine Option, die hier hilft (habe im manual.txt des Mutt nichts gefunden).
Heiko
Hallo Heiko,
On Mon, May 25, 2009 at 10:25:14AM +0200, Heiko Schlittermann wrote:
wenn ich mit dem Mutt eine Nachricht versende, und dort BCC mit drin habe, ist alles Ok, die zusätzlichen Empfänger tauchen in keinem der Header auf, so daß diese wirklich BCC sind. Wenn ich aber diese Nachricht (im Mutt) mit ``gpg'' verschlüssle, dann sehe ich der verschlüsselten Nachricht an (mit ``gpg'', für welche Empfänger (eben für den eigentlichen und die BCCs) verschlüsselt wurde.
Kennt jemand diese Feature? Ist es ein Bug? Oder gibt's eine Option, die hier hilft (habe im manual.txt des Mutt nichts gefunden).
Das liegt nicht an mutt, vielmehr speichert gpg die Key-IDs _jedes_ Empfängers in der verschlüsselten Nachricht. Schau mal nach den gpg-Optionen --hidden-recipient bzw. --hidden-encrypt-to .
Christian
Hallo Christian,
danke für die schnelle Antwort.
Christian Kuenstner lug-dd@its-seffner.de (Mo 25 Mai 2009 11:42:00 CEST):
Hallo Heiko,
On Mon, May 25, 2009 at 10:25:14AM +0200, Heiko Schlittermann wrote:
wenn ich mit dem Mutt eine Nachricht versende, und dort BCC mit drin habe, ist alles Ok, die zusätzlichen Empfänger tauchen in keinem der Header auf, so daß diese wirklich BCC sind. Wenn ich aber diese Nachricht (im Mutt) mit ``gpg'' verschlüssle, dann sehe ich der verschlüsselten Nachricht an (mit ``gpg'', für welche Empfänger (eben für den eigentlichen und die BCCs) verschlüsselt wurde.
Kennt jemand diese Feature? Ist es ein Bug? Oder gibt's eine Option, die hier hilft (habe im manual.txt des Mutt nichts gefunden).
Das liegt nicht an mutt, vielmehr speichert gpg die Key-IDs _jedes_ Empfängers in der verschlüsselten Nachricht. Schau mal nach den gpg-Optionen --hidden-recipient bzw. --hidden-encrypt-to .
Jo, mutt *könnte* aber die Nachrichten für die Leute in der BCC-Zeile einzeln generieren, oder? (Oder wie ist das mit der Signatur? Müsste ich dann auch für jeden meine Passphrase noch mal einwerfen?)
Nach den erwähnten Optionen guck' ich mal. Eigentlich wäre es Mutt's Aufgabe, dann bei den BCCs diese Option --hidden-encrypt-to zu verwenden, oder? Oder eben generell "--hidden-recipient". Letzteres kann man wohl im Mutt einstellen, beim zu verwendenden PGP-Kommando.
Hallo Heiko,
On Mon, May 25, 2009 at 12:42:05PM +0200, Heiko Schlittermann wrote:
Jo, mutt *könnte* aber die Nachrichten für die Leute in der BCC-Zeile einzeln generieren, oder?
Das würde bedeuten, mutt generiert eine Mail an alle Adressaten im TO-Header, sowie jeweils eine Mail für jeden Adressaten im BCC-Header. Diese dürften dann aber keinen TO-Header mehr haben, da die Mail zum primären Empfänger sonst mehrfach geschickt würde. BCC-Empfänger würden dann aber nicht mehr die primären Empfänger erfahren, was die Verwendung von BCC ad absurdum führt (d.h. man könnte BCC-Empfänger gleich zu TO-Empfängern machen). Kurzum: Ich glaube nicht, daß mutt sowas kann, da die Aufsplittung der Mail imho Aufgabe der beteiligten MTAs ist. Oder habe ich hier einen Denkfehler?
(Oder wie ist das mit der Signatur? Müsste ich dann auch für jeden meine Passphrase noch mal einwerfen?)
Das müsstest Du nicht. Mutt kann Passphrasen über einen bestimmten Zeitraum cachen (pgp_timeout).
Nach den erwähnten Optionen guck' ich mal. Eigentlich wäre es Mutt's Aufgabe, dann bei den BCCs diese Option --hidden-encrypt-to zu verwenden, oder? Oder eben generell "--hidden-recipient". Letzteres kann man wohl im Mutt einstellen, beim zu verwendenden PGP-Kommando.
--throw-keyids wäre hier auch noch zu nennen. Trotz alldem läßt sich aber noch die Anzahl der verwendeten Schlüssel herausfinden (das könnte evtl. problematisch sein, wenn der Empfänger nicht wissen soll, daß es BCC-Empfänger gibt).
Christian
Hallo Christian, Christian Kuenstner lug-dd@its-seffner.de (Mo 25 Mai 2009 23:07:11 CEST):
Hallo Heiko,
On Mon, May 25, 2009 at 12:42:05PM +0200, Heiko Schlittermann wrote:
Jo, mutt *könnte* aber die Nachrichten für die Leute in der BCC-Zeile einzeln generieren, oder?
Das würde bedeuten, mutt generiert eine Mail an alle Adressaten im TO-Header, sowie jeweils eine Mail für jeden Adressaten im BCC-Header. Diese dürften dann aber keinen TO-Header mehr haben, da die Mail zum primären Empfänger sonst mehrfach geschickt würde. BCC-Empfänger würden dann aber nicht mehr die primären Empfänger erfahren, was die Verwendung von BCC ad absurdum führt (d.h. man könnte BCC-Empfänger gleich zu TO-Empfängern machen). Kurzum: Ich glaube nicht, daß mutt sowas kann, da die Aufsplittung der Mail imho Aufgabe der beteiligten MTAs ist. Oder habe ich hier einen Denkfehler?
Ja. Die Header entscheiden rein gar nichs. Es ist ist der Aufruf von Sendmüll bzw. dessen Äquivalent (halt irgendeine /usr/*/sendmail), und ich bin mir ziemlich sicher, daß er das nicht mit der Option "-t" tut. Und es ist die Aufgabe des MUA, die BCC-Zeile(n) zu entfernen.
,----- |sendmail -f <env-from> rcpt1 ... rcptN bcc1 ... bccN <<_EOF |To: rcpt1 ... rcptN |Subject: ... | |message-signed-and-crypted-for-rcpt1...rcptN-bcc1...bccN |_EOF `------
müsste dann werden zu
,----- |sendmail -f <env-from> rcpt1 ... rcptN <<_EOF |To: rcpt1 ... rcptN |Subject: ... | |message-signed-and-crypted-for-rcpt1...rcptN |_EOF `------
,------- |sendmail -f <env-from> bcc1 <<_EOF |To: rcpt1 ... rcptN |Subject: ... | |message-signed-and-crypted-for-bcc1 |_EOF `------
... usw für jeden BCC
(Oder wie ist das mit der Signatur? Müsste ich dann auch für jeden meine Passphrase noch mal einwerfen?)
Das müsstest Du nicht. Mutt kann Passphrasen über einen bestimmten Zeitraum cachen (pgp_timeout).
Stimmt.
Nach den erwähnten Optionen guck' ich mal. Eigentlich wäre es Mutt's Aufgabe, dann bei den BCCs diese Option --hidden-encrypt-to zu verwenden, oder? Oder eben generell "--hidden-recipient". Letzteres kann man wohl im Mutt einstellen, beim zu verwendenden PGP-Kommando.
--throw-keyids wäre hier auch noch zu nennen. Trotz alldem läßt sich aber
lt. Manpage zu ``gpg'' über --throw-keyids:
.. This option is essentially the same as using --hidden- recipient for all recipients.
Was macht den Unterschied aus? (Probieren kann ich es selbst, nur, falls Du es zufällig aus dem Stand weißt.)
noch die Anzahl der verwendeten Schlüssel herausfinden (das könnte evtl. problematisch sein, wenn der Empfänger nicht wissen soll, daß es BCC-Empfänger gibt).
Ja. Aber ich könnte es ja auch für meine 5 eigenen Keys vercrypted haben...
On Mon, May 25, 2009 at 11:25:27PM +0200, Heiko Schlittermann wrote:
Oder habe ich hier einen Denkfehler?
Ja. Die Header entscheiden rein gar nichs. Es ist ist der Aufruf von Sendmüll bzw. dessen Äquivalent (halt irgendeine /usr/*/sendmail)
Stimmt, da hast Du Recht.
und ich bin mir ziemlich sicher, daß er das nicht mit der Option "-t" tut.
Was macht dich da so sicher?
Und es ist die Aufgabe des MUA, die BCC-Zeile(n) zu entfernen.
Definiere MUA. Ich meine, der Bcc-Header ist bei der Übergabe der Mail an sendmail noch vorhanden.
,----- |sendmail -f <env-from> rcpt1 ... rcptN bcc1 ... bccN <<_EOF |To: rcpt1 ... rcptN |Subject: ... | |message-signed-and-crypted-for-rcpt1...rcptN-bcc1...bccN |_EOF `------
müsste dann werden zu
,----- |sendmail -f <env-from> rcpt1 ... rcptN <<_EOF |To: rcpt1 ... rcptN |Subject: ... | |message-signed-and-crypted-for-rcpt1...rcptN |_EOF `------
,------- |sendmail -f <env-from> bcc1 <<_EOF |To: rcpt1 ... rcptN |Subject: ... | |message-signed-and-crypted-for-bcc1 |_EOF `------
... usw für jeden BCC
ja, auf sowas in der Art wird es wohl hinauslaufen müssen.
lt. Manpage zu ``gpg'' über --throw-keyids:
.. This option is essentially the same as using --hidden- recipient for all recipients.
Was macht den Unterschied aus? (Probieren kann ich es selbst, nur, falls Du es zufällig aus dem Stand weißt.)
imho gibt es keinen, aber probiers lieber aus ;)
Christian
Christian Kuenstner lug-dd@its-seffner.de (Di 26 Mai 2009 22:02:52 CEST):
On Mon, May 25, 2009 at 11:25:27PM +0200, Heiko Schlittermann wrote:
Oder habe ich hier einen Denkfehler?
Ja. Die Header entscheiden rein gar nichs. Es ist ist der Aufruf von Sendmüll bzw. dessen Äquivalent (halt irgendeine /usr/*/sendmail)
Stimmt, da hast Du Recht.
und ich bin mir ziemlich sicher, daß er das nicht mit der Option "-t" tut.
Was macht dich da so sicher?
Weil dann der MTA die Header parsen müsste und auch noch obendrein sich um das Entfernen von BCC-Zeilen kümmern muß. Nicht jeder MTA würde das tun, denke ich.
Und wenn ich im Mutt ":set sendmail" ansehe, steht dort "sendmail="/usr/sbin/sendmail -oem -oi". Und wenn ich das jetzt mal auf ein "/tmp/sendmail" umbiege und mir dort ansehe, wie es aufgerufen wurde, dann sehe ich, daß MUTT an die o.g. Kommandozeile noch "-f hs@schlittermann.de -- heiko@localhost" anhängt.
Und es ist die Aufgabe des MUA, die BCC-Zeile(n) zu entfernen.
Definiere MUA. Ich meine, der Bcc-Header ist bei der Übergabe der Mail an sendmail noch vorhanden.
Rechst hast Du - ich habe mir bei obiger Gelegenheit auch mal angesehen, was MUTT dort an das "sendmail" dann gibt:
U.a. den BCC-Header. Das macht mich jetzt etwas nervös. Warum tut er das? Aha -- "write_bcc" in .muttrc könnte das beeinflussen. Nie würde MUTT das bei SMTP machen. In der Stelle von manual.txt steht auch noch, daß Postfix und Exim4 das dann per default "strippen" auf Debian-Systemen. In der Dokumentation von Exim finde ich dagegen nur einen Hinweis, daß er, wenn gestartet mit "-t", die BCC-Zeile entfernt.
Komisch.
Mal gucken, diese Message geht gleichzeitig als BCC noch raus, mal gucken, was mein Exim dann ans UUCP übergibt, ob da auch noch BCC drin ist.
U.a. den BCC-Header. Das macht mich jetzt etwas nervös. Warum tut er das? Aha -- "write_bcc" in .muttrc könnte das beeinflussen. Nie würde MUTT das bei SMTP machen. In der Stelle von manual.txt steht auch noch, daß Postfix und Exim4 das dann per default "strippen" auf Debian-Systemen. In der Dokumentation von Exim finde ich dagegen nur einen Hinweis, daß er, wenn gestartet mit "-t", die BCC-Zeile entfernt.
So - in der Message, die mein lokaler Exim erzeugt hat und an UUCP übergeben hat, steht noch der BCC-Header drin! Ist ja 'ne dicke Wurst...
Heiko Schlittermann hs@schlittermann.de (Di 26 Mai 2009 22:41:58 CEST):
U.a. den BCC-Header. Das macht mich jetzt etwas nervös. Warum tut er das? Aha -- "write_bcc" in .muttrc könnte das beeinflussen. Nie würde MUTT das bei SMTP machen. In der Stelle von manual.txt steht auch noch, daß Postfix und Exim4 das dann per default "strippen" auf Debian-Systemen. In der Dokumentation von Exim finde ich dagegen nur einen Hinweis, daß er, wenn gestartet mit "-t", die BCC-Zeile entfernt.
So - in der Message, die mein lokaler Exim erzeugt hat und an UUCP übergeben hat, steht noch der BCC-Header drin! Ist ja 'ne dicke Wurst...
Die Wurst ist noch dicker: im Header der Mail - wenn sie in der Liste ankommt - ist immer noch das BCC. (Aber eigentlich auch logisch - der MUA hätte es nicht übergeben dürfen, der erste MTA hätte es vielleicht entfernen müssen, alle weiteren geht das nichts mehr an.)
Hallo Heiko,
Am Dienstag, 26. Mai 2009 schrieb Heiko Schlittermann:
So - in der Message, die mein lokaler Exim erzeugt hat und an UUCP übergeben hat, steht noch der BCC-Header drin! Ist ja 'ne dicke Wurst...
Die Wurst ist noch dicker: im Header der Mail - wenn sie in der Liste ankommt - ist immer noch das BCC.
Also, ich kann hier keinen BCC-Header entdecken, oder meintest du den Umschlag (Envelope)?
(Aber eigentlich auch logisch - der MUA hätte es nicht übergeben dürfen, der erste MTA hätte es vielleicht entfernen müssen, alle weiteren geht das nichts mehr an.)
Aber vielleicht hat ja auch mein Postfix diesen Header entfernt. Ich hole die Mails mit fetchmail und lass Postfix ausliefern.
Ein interessantes Problem ;-)
Ist es nicht so, dass der MTA sich nur um die Angaben im Envelope kümmert und normalerweise nur zusätzliche Angaben in den Header schreibt? Zitat aus dem Postfix-Buch von Peer Heinlein: "Der Mailheader hat damit keine Auswirkungen auf den Transport der Mail."
Ich müsste jetzt nochmal in der RFC nachschauen, aber meines Wissens funktioniert der normale Mailversand so: 1. MUA nimmt To, CC und BCC vom Nutzer entgegen 2. MUA schreibt To und CC in den Header 3. MUA ruft MTA (/usr/sbin/sendmail oder smtp) und übergibt To, CC und BCC als Empfänger für diese Mail 4. MTA stellt die Mail zu
Für verschlüsselte Mails müsste das ganze so aussehen (Achtung: Nicht überprüft!): 1. MUA nimmt To, CC und BCC vom Nutzer entgegen 2. MUA schreibt To und CC in den Header 3. für jeden Empfänger aus To, CC und BCC: 1. MUA verschlüsselt Mail für den Empfänger 2. MUA übergibt an den MTA eine verschlüsselte Mail für genau diesen Emfpänger
Warum Mutt überhaupt eine Einstellung wie "write_bcc" kennt, kann ich nur wild rumraten. Naheliegend wäre, dass er sich die Mailerstellung einfach macht und eine Mail erstellt, die nur aus Header und Body besteht. Die Erzeugung des Envelope delegiert er (es?) dann an einen freundlichen MTA, der diese komplizierten Dinge wie Generierung der Envelopes für ihn erledigt.
Die Anleitung für Mutt sagt übrigens ganz deutlich zum Gebrauch von write_bcc: Exim users may wish to unset this. Wahrscheinlich ist Exim keiner von den netten MTAs, der Mutt das Leben erleichtern will ;-)
Noch ein interessantes Zitat aus dem Postfix-Buch zum BCC-Header: Im Idealfall wird das Feld vollständig entfernt, sobald es in das Postfach einsortiert wird. Eine hundertprozentige Garantie gibt es dafür aber nicht.
Eine gute Nacht Uwe
lug-dd@mailman.schlittermann.de
-
Christian Kuenstner -
Heiko Schlittermann -
Uwe Koloska