Frage zu Email, speziell Bcc-Mails

[chrisg]

Hallo,

im Forum wurde ein ähnliches Problem 2009 schon einmal diskutiert. Damals kam es aber zu keinem Ergebnis.
Vielleicht ist es ja diesmal anders

Ich umreiße mal kurz mein Problem:

Ich habe einen Mailserver mit Debian, Getmail, Procmail usw. installiert und als Produktionssystem erfolgreich
in Betrieb genommen. Also eigentlich nichts tolles.

Mein Kunde bekommt von seinem Provider ein sog. "CatchAll"-Postfach zur Verfügung gestellt.
Ich nenne es Pop3-Multidrop. Der Provider nennt es halt "CatchAll". Sei's drum. Getmail kann ja Pop3-Multidrop verarbeiten wenn es im
Mailheader den sog. X-Envelope-To: oder X-Original-To: Eintrag findet. So weit so gut.

Der tolle Provider meines Kunden fügt diesen Eintrag aber nicht hinzu.
Dieses begründet er mit:
"CatchAll reicht die Mails weiter, verteilen auf Postfächer macht der Server beim Kunden, basta.
Der Kunde hat so halt den Vorteil beliebige Adressen verwalten zu können ohne das der Provider darauf Einfluß nehmen muß."

Mit Hilfe von procmail kann ich den Maildatenstrom filtern und die Mails in die Maildir-Verzeichnisse einsortieren. So weit so gut.
Nun gibt es aber das Problem, dass Mails via Bcc versandt eigentlich nicht mehr zu gestellt werden können, da der Bcc-Empfänger
ja aus dem Header gelöscht wird. Ich konnte diese Hürde umschiffen in dem ich eine Received-Zeile filtere.

Die String-Filterei finde ich persönlich aber nicht so sonderlich toll, da sie erstens den Verwaltungsaufwand erhöht und zweitens auch
etwas Fehleranfällig ist. Sobald irgendwer meint die Received-Zeile mal zu ändern, greift ja mein Filter nicht mehr.

Ist es nicht Aufgabe des Providers auch bei Pop3-Multidrop oder CatchAll die Mails in eine geordnete Form zu bringen?
Sprich X-Envelope-To: oder X-Original-To: einzufügen.

Welcher Server entfernt eigentlich das Bcc aus der Mail?
Ich das der erste Server der die Mail entgegen nimmt oder macht das der Zielmailserver?

Vielleicht könnt ihr mir ja weiterhelfen. Vielen Dank schon mal für die Mühe.

Gruß Christian

[MSfree]

Welcher Server entfernt eigentlich das Bcc aus der Mail?

Bcc steht für Blind carbon copy, eine Kopie also, von der andere nichts wissen sollen. Das Gegenstück dazu nennt sich CC, also carbon copy (Carbon copy steht für Durchschlag mit Kohlepapier, wie man es früher auf Schreibmaschinen produziert hat).

Der Mailclient ist dafür zuständig, eine Mail, die an a@b.c als Mail und an b@c.d als Bcc geht, als zwei gesonderte Mails rauszuschicken, damit keine der beiden Empfänger mitbekommt, daß sie die Mail bekommen haben.

[chrisg]

Danke für deine Antwort. Wenn man sich den Header einer gesendeten Mail anschaut taucht der bcc-Empfänger ja noch
auf. Muß ja auch, sonst weiß der entgegennehmende Server ja nicht wohin mit der Mail:
z.B.:

BCC: krl@------.de
To: stil@------.de
From: cg <ch.g-----@------.de>
Subject: to stil, bcc krl
Message-ID: <57221FDF.105@------.de>
Date: Thu, 28 Apr 2016 16:36:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Nachdem die Mail herum gereist ist und im, mit Pop3Multidrop angeschlossenen, Postfach landet sieht der Mailheader dann in etwa so aus:
(Die Email wurde an christian.g@domain1.de, cc an christian.g@domain4.de und bcc an kts@domain3.de gesendet.)

Return-Path: <christian.g@domain1.de>
Received: by intexxx.net (CommuniGate Pro PIPE 4.1.
with PIPE id 10047931; Thu, 28 Apr 2016 14:35:19 +0200
X-TFF-CGPSA-Version: 1.7
X-TFF-CGPSA-Filter: Scanned
Return-Path: <christian.g@domain1.de>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on cgklon.provider2.net
X-Spam-Status: No, score=-2.1 required=10.0 tests=AWL,BAYES_00,
BODY_SINGLE_WORD,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,TVD_SPACE_RATIO
autolearn=ham version=3.3.1
X-Spam-Level:
Received: from mailout08.domain1.de ([194.25.000.000] verified)
by intexxxs.net (CommuniGate Pro SMTP 4.1.
with ESMTP id 10047925 for kts@domain3.de; Thu, 28 Apr 2016 14:35:01 +0200
Received: from fwd15.aul.domain1.de (fwd15.aul.domain1.de [172.20.00.00])
by mailout08.domain1.de (Postfix) with SMTP id C4BF9334E2C;
Thu, 28 Apr 2016 14:35:00 +0200 (CEST)
Received: from [192.168.0.000] (XdMQk8ZJYhV78Q1y9AnKBLIXWL_____________@[80.153.00.00]) by fwd15.domain1.de
with (TLSv1.2:EC-------AES256-SHA encrypted)
esmtp id 1avl9f-uzuuz0; Thu, 28 Apr 2016 14:34:51 +0200
To: "christian.g@domain1.de" <christian.g@domain1.de>
Cc: christian.g@domain4.de
From: cg <christian.g@domain1.de>
Subject: bcc kts@kts@domain3.de
Message-ID: <58220369.90878500@domain1.de>
Date: Thu, 28 Apr 2016 14:34:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ID: XdMQk8ZJYhV78Q1y9A
X-TOI-MSGID: f6425127-1720

Die beiden aufgeführten Mailheader stammen nicht von der selben Mail. Problem ist halt wie erwähnt das "X-Envelope-To: oder X-Original-To:" fehlen und
somit getmail nur als "normaler" Pop3-Abholer fungieren kann. Mit procmail kann ich den Bcc-Empfänger heraus fischen in dem ich die Zeile
"with ESMTP id 10047925 for kts@domain3.de; Thu, 28 Apr 2016 14:35:01 +0200" als Filterkriterium einsetze.

Ich befürchte halt, dass die Suche nach Strings nicht wirklich das gelbe vom Ei ist und Serviceeinsätze anfallen, die der Kunde ja auch bezahlen muss.
Kann man dem Betreiber von "domain3", also derjenige der das Pop3Multidrop-Postfach zur Verfügung stellt, verpflichten ein rfc-konformes Pop3Multidrop
anzubieten oder kann hier jeder Provider machen was er will?

[Meillo]

Es gibt keine klare Regel wie BCC-Mails genau zu behandeln sind. Klar ist nur, was der Sinn von BCC ist, aber welche Header-Zeilen wie oder ob ueberhaupt dafuer verwendet werden, kann je nach Implementierung unterschiedlich sind.

Zudem: Mail-Header haben nichts mit der Mail-Zustellung zu tun. Mail-Header sind Teil des Inhalts (RFC 822), die Mail-Zustellung wird nur vom Envelope kontrolliert (RFC 821) ... das ist nicht anders als bei der Schneckenpost. Es ist nur eine Nettigkeit des letzten Mailservers, dass der die Envelope-Information am Ende des Transportwegs, wenn sie nicht mehr gebraucht wird und deshalb verfallen wuerde, im X-Envelope-To Header konserviert. (Das ist eine Transferinformation, wie auch die Received-Header, die in den Mail-Inhalt uebernommen wird, also ein Transfer aus der RFC 821-Domaene in die RFC 822-Domaene.)

All diese Anmerkungen helfen dir zwar nicht mit deinem technischen Problem, aber sie erklaeren vielleicht warum die Situation so ist wie sie ist. Helfen tun nur andere Implementierung.

[chrisg]

Ok danke dir für deine Mühe. Hilft mir auf jeden Fall weiter. Ich werde beim Betreiber des Mailservers noch mal anfragen warum und wieso er die Envelope-Infos verwirft.
Mein Kunde ist schließlich auch nett zu seinem Provider in dem er für seine Dienstleistung bezahlt also kann er auch erwarten, dass dieser nett zu ihm ist und
diesen Eintrag hinzufügt.

[Meillo]

[...] beim Betreiber des Mailservers noch mal anfragen warum und wieso er die Envelope-Infos verwirft.

Ob der die absichtlich verwirft? Kann man das bei MTAs bzw. MRAs ueblicherweise konfigurieren?

Hab aus Eigeninteresse nochmal im Code von Masqmail (einem zugegeben nicht allzu populaeren MTA, den ich aber zufaellig recht gut kenne) nachgesehen. In der Funktion deliver_local() findet sich dort:

Code: Alles auswählen

retpath_hdr = create_header(HEAD_ENVELOPE_TO,
                                "Envelope-to: %s\n", addr_string(env_addr));
envto_hdr = create_header(HEAD_RETURN_PATH,
                                "Return-path: %s\n", addr_string(ret_path));
hdr_list = g_list_prepend(hdr_list, envto_hdr);
hdr_list = g_list_prepend(hdr_list, retpath_hdr);

Die Fetchmail-Mainpage bietet eine *Menge* Information zu genau diesem Thema. Die solltest du unbedingt lesen. (Wenn man nach ``envelope'' sucht findet man die relevanten Stellen.)

[GregorS]

... Mein Kunde ist schließlich auch nett zu seinem Provider in dem er für seine Dienstleistung bezahlt also kann er auch erwarten, dass dieser nett zu ihm ist und
diesen Eintrag hinzufügt.

„Nett“ ist beliebig interpretierbar. Du bzw. Dein Kunde bekommt, was vertraglich vereinbart ist. Alles, was darüber hinaus läuft, ist „extra“. Ich hatte einige Kunden mit Catchall-Adresse und habe das mit der Sortiererei immer hinbekommen. Es kann allerdings sein, dass ich damals nie mit bcc-Mails zu tun hatte, is lange her.

Gruß

Gregor