folgende Konstellation macht mich gerade etwas Hilflos.
Die Mails werden per Fetchmail abgeholt.
Internet-Host --> Fetchmail --> UCS Postfix --> User Mailbox/Zarafa
Ich habe fetchmailrc für den User mit einem 2en zu fetchenden E-Mailkonto bestückt und zwar manuel, da es über die Weboberfläche ja nicht geht.
set daemon 60
set syslog
set postmaster "postmaster"
set bouncemail
set no spambounce
set properties ""
poll pop.gmxxx.com with proto POP3 auth password user 'tm' there with password 'xxxxxxx' is 'tm@gmxxx.com' here keep ssl #UID='maxmustermann'
poll pop.gmlxxx.com with proto POP3 auth password user 'kp' there with password 'xxxxxxx' is 'kp@gmxxx.com' here keep ssl #UID='maxmustermann'
Das abholen funktioniert auch ohne Probleme, dass einizg unschöne ist, dass die Mailadresse die den Emfänger angibt dann vonn tm@gmxxx.com umgeschrieben wird, sprich also in die Primäre E-Mail-Adresse des Accounts.
Nachteil davon ist, dass dann nicht mehr ersichtlich ist, über welches Konto die Mail reingekommen ist und es beim Antworten dann Verwechslungen geben kann.
Ich habe auch nicht geändert, bis auf den Eintrag in der fetchmailrc
Der User hat auch als Alternative E-Mail-Adresse die von kp@gmxxx.com eingetragen
Leider bringt ein Hinweis in der fetchmailrc mit dem Hinweis
poll pop.gmlxxx.com with proto POP3 auth password user 'kp' there with password 'xxxxxxx' is 'kp@gmxxx.com' here keep ssl no rewrite #UID='maxmustermann'
fetchmails »rewrite« sorgt eigentlich nur dafür, dass eine unvollständige Adresse (z.B. »From: root«) zu einer vollständigen gemacht wird, indem @hostname angehängt wird, z.B. »From: root@master.domain.ucs«.
Ich denke eher, dass Postfix hier derjenige ist, der umschreibt. Stichwort: »canonical_maps«. Können Sie bitte mal die Ausgabe von »postconf -n« posten und schauen, was so in »/etc/postfix/canonical« steht?
Ich glaube, ich verstehe noch nicht ganz, was Ihrer Meinung nach umgeschrieben wird.
fetchmail muss Postfix gegenüber beim Einliefern sagen, für welchen Empfänger die E-Mail ist. Das ist diejenige, die in der fetchmail-Config mit »is … here« angegeben wird. Diese Adresse wird auch Envelope-To oder ähnlich genannt.
Die hat erst mal nicht viel mit To: und Cc: im E-Mail-Header zu tun.
Wo also genau sehen Sie die falsche Adresse? Outlook? Zarafa Webaccess? Anderer E-Mail-Client?
wenn ich eine E-Mail die für Domain tm@gmxxx.com ist bekomme wir diese in Zarafa unter An: richtig dargestellt da dies auch die E-Mailadresse dieses Users ist, User1
Wie ich im ersten Beitrag gepostet habe, habe ich in die fetchmailrc händisch eine zusätzlichen Account angelegt der abgeholt werden soll, die Adresse lautet kp@gmxxx.com und wir ebenfalls in den Mailaccount von Unser1 eingeliefert.
Nun steht in Zarafa aber nicht mehr tm@gmxxx.com unter An:
Dies möchte ich gerne verhindern und das Ziel ist das dort der richtige Empfänger, sprich kp@gmxxx.com, damit der User User1 weiss, über welchen Kanal die Mail hereingekommen ist und der diese auch mit dem richten Absender wieder Antwortet.
Haben Sie sich die E-Mail mal im Quelltext angesehen? Ich kann mir eigentlich nicht vorstellen, dass der »To:«-Header irgendwo umgeschrieben wird.
Das geht sowohl im Webaccess als auch in einem x-beliebigen IMAP-Client, wobei Sie es zuerst mit einem IMAP-Client probieren sollten, um das Webaccess von den Tests auszuschließen.
ich habe mal den Header von einer Mail angesehen, leider nur per Zarafa Webapp, da ich per Imap nicht auf den Server komme.
Mit thunderbird wird immer gemeldet, dass das Passwort falsch sei, was eigentlich nicht sein kann.
Return-Path: <mail@test-domain.de>
Received: from intranet.domain.de (127.0.0.1)
by intranet (Zarafa-spooler) with LMTP
for <mail@test-domain.de>; Fri, 20 Nov 2015 17:36:30 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by intranet.domain.de (Postfix) with ESMTP id 5DA0CA0066
for <tm@gmail.com>; Fri, 20 Nov 2015 17:36:30 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at domain.de
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level:
X-Spam-Status: No, score=-0.698 tagged_above=-1000 required=5
tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
TVD_SPACE_RATIO=0.001] autolearn=disabled
Received: from intranet.domain.de ([127.0.0.1])
by localhost (intranet.domain.de [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 0r8coYLhb8tq for <tm@gmail.com>;
Fri, 20 Nov 2015 17:36:29 +0100 (CET)
Received: from intranet.domain.de (localhost [127.0.0.1])
by intranet.domain.de (Postfix) with ESMTP id 382B1A0064
for <kp@gmail.com>; Fri, 20 Nov 2015 17:36:29 +0100 (CET)
Delivered-To: kp@gmail.com
Received: from gmail-pop.l.google.com [64.233.184.108]
by intranet.domain.de with POP3 (fetchmail-6.3.21)
for <kp@gmail.com> (single-drop); Fri, 20 Nov 2015 17:36:29 +0100 (CET)
Received: by 10.202.213.83 with SMTP id m80csp714480oig;
Fri, 20 Nov 2015 08:35:24 -0800 (PST)
X-Received: by 10.194.82.170 with SMTP id j10mr18038533wjy.55.1448037324482;
Fri, 20 Nov 2015 08:35:24 -0800 (PST)
Received: from ms.1blu.de (ms.1blu.de. [245.254.4.101])
by mx.google.com with ESMTPS id z133si368988wmc.82.2015.11.20.08.35.24
for <kp@gmail.com>
(version=TLS1 cipher=AES128-SHA bits=128/128);
Fri, 20 Nov 2015 08:35:24 -0800 (PST)
Received-SPF: neutral (google.com: 178.254.4.101 is neither permitted nor denied by best guess record for domain of mail@test-domain.de) client-ip=178.254.4.101;
Authentication-Results: mx.google.com;
spf=neutral (google.com: 254.254.4.101 is neither permitted nor denied by best guess record for domain of mail@test-domain.de) smtp.mailfrom=mail@test-domain.de
Received: from [217.234.167.196] (helo=ubuntu.vm.domain..de)
by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
(Exim 4.76)
(envelope-from <mail@test-domain.de>)
id 1Zzoeh-0005g8-EA; Fri, 20 Nov 2015 17:35:23 +0100
Received: from localhost (localhost [127.0.0.1])
by ubuntu.vm.domain..de (Postfix) with ESMTP id 9AB4A413E7;
Fri, 20 Nov 2015 17:35:30 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at ubuntu.vm.domain..de
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 required=4.11 tests=[ALL_TRUSTED=-1,
HTML_MESSAGE=0.001, TVD_SPACE_RATIO=0.001] autolearn=ham
Received: from ubuntu.vm.domain..de ([127.0.0.1])
by localhost (ubuntu.vm.domain..de [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 9Xb1xzNQdfpW; Fri, 20 Nov 2015 17:35:29 +0100 (CET)
Received: from ubuntu.vm.domain..de (localhost [127.0.0.1])
by ubuntu.vm.domain..de (Postfix) with ESMTP id 68B85413E6;
Fri, 20 Nov 2015 17:35:29 +0100 (CET)
Subject: test
From: =?utf-8?Q?Test_tester?= <mail@test-domain.de>
To: =?utf-8?Q?kp=2Ero=40gmail=2Ecom?=<kp@gmail.com>
Date: Fri, 20 Nov 2015 17:35:29 +0100
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_hLQjnpE-2Drye-C0zetWm9nhqMmlTX1bxEeF7ON1hcuUo4D0"
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.1.10-44973
X-Original-To:
Message-Id: <zarafa.564f4bd1.0b6a.4900c92e055298ec@ubuntu.vm.domain..de>
X-Con-Id: 147535
X-Con-U: 0-mail
X-Originating-IP: 217.234.167.196
Beim betreff To wir eigentlich klar der Empfänger angegeben der in Zarafa dann als tm@gmail.com gelistet wird.
Merkwürdig… das Letzte, was ich gerne noch mal sehen würde, wäre die »master.cf« von Postfix.
Weiterhin können Sie mal den dagent von Zarafa auf ein hohes Loglevel (5) setzen, dann eine solche E-Mail an den sekundären Account erzeugen und abholen und das dagen-Log anschauen. Der dagent kann potenziell ebenfalls etwas umschreiben.
Meiner Meinung nach dürfte weder fetchmail noch Postfix in der von Ihnen beschriebenen Konfiguration den Inhalt der E-Mail umschreiben. Mir fallen in Summe vier Möglichkeiten ein, was hier gerade passieren könnte, aber die kann ich so nicht weiter sinnvoll debuggen, ohne direkt auf das Gerät draufschauen zu können:
[ol][li]Meine Annahme über die fetchmail-Konfiguration ist falsch und fetchmail schreibt doch um.[/li]
[li]Meine Annahme über die postfix-Konfiguration ist falsch und postfix schreibt doch um.[/li]
[li]Der Provider schreibt bereits beim Einliefern in die Mailbox um (eher unwahrscheinlich).[/li]
[li]Zarafas Webaccess zeigt den Empfänger schlicht anders an, z.B. weil der User Zarafa über das LDAP unter beiden Adressen bekannt ist. Das ließe sich etwas via IMAP eingrezen, aber das klappt bei Ihnen ja auch nicht.[/li][/ol]
Daher bin ich hier jetzt erst mal mit meinem Latein am Ende. Sorry.
Mit dem Imap min ich weiter, musste nur in der Zarafa server.cfg den Imap freigeben, da dies über die UCS Regystry wohl nicht geht.
Hier der Header.
Return-Path: <mail@domain-domain.de>
Received: from intranet.domain.de (127.0.0.1)
by intranet (Zarafa-spooler) with LMTP
for <mail@domain-domain.de>; Wed, 25 Nov 2015 09:50:57 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by intranet.domain.de (Postfix) with ESMTP id 981E1A0064
for <tm@gmail.com>; Wed, 25 Nov 2015 09:50:57 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at domain.de
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level:
X-Spam-Status: No, score=-0.698 tagged_above=-1000 required=5
tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
TVD_SPACE_RATIO=0.001] autolearn=disabled
Received: from intranet.domain.de ([127.0.0.1])
by localhost (intranet.domain.de [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id mQkywnBWL2zV for <tm@gmail.com>;
Wed, 25 Nov 2015 09:50:56 +0100 (CET)
Received: from intranet.domain.de (localhost [127.0.0.1])
by intranet.domain.de (Postfix) with ESMTP id CAAA6A0062
for <kp@gmail.com>; Wed, 25 Nov 2015 09:50:56 +0100 (CET)
Delivered-To: kp@gmail.com
Received: from gmail-pop.l.google.com [173.194.67.109]
by intranet.domain.de with POP3 (fetchmail-6.3.21)
for <kp@gmail.com> (single-drop); Wed, 25 Nov 2015 09:50:56 +0100 (CET)
Received: by 10.202.213.83 with SMTP id m80csp2699243oig;
Wed, 25 Nov 2015 00:50:41 -0800 (PST)
X-Received: by 10.194.90.79 with SMTP id bu15mr48845942wjb.36.1448441441674;
Wed, 25 Nov 2015 00:50:41 -0800 (PST)
Received: from ms-10.1blu.de (ms-10.1blu.de. [178.254.4.101])
by mx.google.com with ESMTPS id dc7si33104538wjc.14.2015.11.25.00.50.41
for <kp@gmail.com>
(version=TLS1 cipher=AES128-SHA bits=128/128);
Wed, 25 Nov 2015 00:50:41 -0800 (PST)
Received-SPF: neutral (google.com: 178.254.4.101 is neither permitted nor denied by best guess record for domain of mail@domain-domain.de) client-ip=278.254.4.101;
Authentication-Results: mx.google.com;
spf=neutral (google.com: 278.254.4.101 is neither permitted nor denied by best guess record for domain of mail@domain-domain.de) smtp.mailfrom=mail@domain-domain.de
Received: from [64.133.33.320] (helo=ubuntu.vm.domain.de)
by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
(Exim 4.76)
(envelope-from <mail@domain-domain.de>)
id 1a1Vmi-0000N7-73
for kp@gmail.com; Wed, 25 Nov 2015 09:50:40 +0100
Received: from localhost (localhost [127.0.0.1])
by ubuntu.vm.domain.de (Postfix) with ESMTP id 33A1641401
for <kp@gmail.com>; Wed, 25 Nov 2015 09:50:48 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at ubuntu.vm.domain.de
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 required=4.11 tests=[ALL_TRUSTED=-1,
HTML_MESSAGE=0.001, TVD_SPACE_RATIO=0.001] autolearn=ham
Received: from ubuntu.vm.domain.de ([127.0.0.1])
by localhost (ubuntu.vm.domain.de [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 77-0RRNW2d0e for <kp@gmail.com>;
Wed, 25 Nov 2015 09:50:48 +0100 (CET)
Received: from ubuntu.vm.domain.de (localhost [127.0.0.1])
by ubuntu.vm.domain.de (Postfix) with ESMTP id 077A7413FB
for <kp@gmail.com>; Wed, 25 Nov 2015 09:50:48 +0100 (CET)
Subject: test
From: =?utf-8?Q?User_User?= <mail@domain.de>
To: =?utf-8?Q?kp=2Ero=40gmail=2Ecom?= <kp@gmail.com>
Date: Wed, 25 Nov 2015 09:50:48 +0100
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_EpnlNg6QTPsoyMSRKM2+208Ked0TynfnKxI43Ta9SQZ2Xg0W"
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.1.10-44973
X-Original-To:
Message-Id: <zarafa.56557668.684e.12fdee6a55451210@ubuntu.vm.domain.de>
X-Con-Id: 147535
X-Con-U: 0-mail
X-Originating-IP: 84.133.33.220
This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_EpnlNg6QTPsoyMSRKM2+208Ked0TynfnKxI43Ta9SQZ2Xg0W
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
77u/dGVzdA0KDQo=
--=_EpnlNg6QTPsoyMSRKM2+208Ked0TynfnKxI43Ta9SQZ2Xg0W
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A <meta name=3D"Generator"=
content=3D"Zarafa WebApp v7.1.10-44973">=0A <meta http-equiv=3D"Content=
-Type" content=3D"text/html; charset=3Dutf-8">=0A <title>test</title>=0A=
</head>=0A<body>=0A<p style=3D"padding: 0; margin: 0;" constructor=3D"fun=
ction Object() {=0A [native code]=0A}" tostring=3D"function toString()=
{=0A [native code]=0A}" tolocalestring=3D"function toLocaleString() {=
=0A [native code]=0A}" propertyisenumerable=3D"function propertyIsEnum=
erable() {=0A [native code]=0A}" isprototypeof=3D"function isPrototype=
Of() {=0A [native code]=0A}" valueof=3D"function valueOf() {=0A [na=
tive code]=0A}" hasownproperty=3D"function hasOwnProperty() {=0A [nati=
ve code]=0A}"><span data-mce-bogus=3D"true" id=3D"_mce_caret"><span data-=
mce-style=3D"font-size: 10pt; font-family: arial;" style=3D"font-size: 10=
pt; font-family: arial;">=EF=BB=BFtest<br></span></span></p>=0A</body>=0A=
</html>
--=_EpnlNg6QTPsoyMSRKM2+208Ked0TynfnKxI43Ta9SQZ2Xg0W--
Ich hab noch eine älter Zarafa installation die, produktiv läuft und dort wird es richtig angezeigt.
[ul][li]fetchmail holt die E-Mail für den sekundären Account (kp@…) ab und übergibt diese an Postfix mit Envelope-To kp@…. Das ist so OK, so steht’s ja auch in der fetchmail-Konfiguration: »…user ‘kp’ … is ‘kp@…’ here«.[/li]
[li]postfix schreibt aufgrund seiner virtual_alias_maps dann den Envelope-To von kp@… auf tm@… um. Auch das ist so OK, damit die E-Mail dann im richtigen Postfach landet.[/li]
[li]Weiterhin ist im Header-To zu sehen, dass der Header-To weiterhin den originalen kp@… enthält. Auch OK, sprich weder Provider, noch fetchmail, noch postfix schreiben um.[/li][/ul]
Damit ist auch klar, was Sie sehen: einen Effekt von Zarafas Webaccess. Das kennt den Benutzer unter beiden Adressen und zeigt im Header-To daher »hilfsbereit« die primäre E-Mail-Adresse des Nutzers an und nicht diejenige, an die die E-Mail tatsächlich ging…
Ob man das bei Zarafa abschalten kann? Das weiß ich ehrlich gesagt nicht.
Hallo, ich habe das so gelöst das ich für die alternativen Mailadressen Zarafa non active user angelegt habe, den Primären User als “Stellvertreter” eingetragen habe und dann eben die Mail
über fetchmail&co an die Mailadresse des primären Users liefern lasse. So zeigt das Webaccess auch die “richtige” Mailadresse als Empfänger an.
Die Mails werden über fetchmail aber schon an den primären User zugestellt und nicht an den non-active user?
Hier könntest du mal den non-active temporär auf aktiv setzen und ein passwort verpassen, per webaccess mal
einloggen ob nachsehen ob die Mails vielleicht dort zu finden sind.
Weiters, was sagt denn das /var/log/mail.log dazu? Bzw. das /var/log/mail.err?
Ich würde auch im Zarafa-Forum ein Anfrage stellen: forums.zarafa.com/
Evtl. ist das Problem bekannt, und es gibt eine andere Lösung, oder man könnte ihnen vorschlagen das Verhalten konfigurierbar zu machen. Diese Sorte von Feature ist sicher bereits mehreren Leuten in die Quere gekommen.
[ul][li]Falls Sie noch den WebAccess nutzen, wechseln Sie auf die WebApp. WebAccess wird nicht mehr weiterentwickelt und mittelfristig komplett durch die WebApp ersetzt.[/li]
[li]Aktualisieren Sie auf die neueste WebApp-Version. Man kann die WebApp auch getrennt vom Rest von Zarafa aktualisieren. Die aktuelle gibt es hier: download.zarafa.com/community/f … App/2.1.1/[/li]
[li]Schauen Sie in der Konfigurationsdatei der WebApp nach, ob man dort diesbezüglich irgend etwas einstellen und konfigurieren kann.[/li][/ul]
Hi zusammen und danke an Euch @DahanS, Moritz und troeder
Im Forum von zarafa habe ich folgendes gefunden was auf die Problematik passt.
Ein anderes Tool gibt es leider wohl nicht, ich finde es etwas merkwürdig, dass da nicht offener gedacht wird.
eigentlich ist das zarafa Webmail eigentlich nur ein Client wie thunderbird.
Anyway
[code]
Similar questions have been answered in the past, but since I cannot find them as well, here is the solution you’re looking for.
The reason for this lies in the way these additional emails addresses have been defined. From the described behaviour I am assuming that the additional addresses have been defined as aliases for the user. Whenever an email is delivered by zarafa-dagent, the dagent will lookup all the recipients in the email and map these recipients to their counterpart in the gab. In this process zarafa-dagent will also resolve aliases if they have been defined (as an alias is an alias and therefore has the same weight as the actual email).
This leads to the effect that when looking at the message the primary email of the user is displayed (when changing the primary address of the user the displayed email will change as well, since as mentioned its only a link).
If you do not want your email alias to be resolved to your primary email you have to assign the email address to a group (zarafa-dagent will then resolve to the group) and make yourself the only member of this group (this way the email will be forwarded to your store). The benefit of this is that the group can also be used for send-as privileges.[/code]
Ganz verstehe ich aber noch nicht, vielleicht könnt Ihr dies auch wegen der Gruppen Geschichte mal so aufschreiben, damit es jemand wie ich, der nicht täglich damit zu tun hat versteht.
@Hans
Ich hab mich jetzt mal in den Test Account eingelogt, sprich aktiviert, dass ich via zarafa drauf zugreifen kann und die Mails lagen dort drin.
Wie diese in den “Stelvertreter Account” kommen habe ich nicht verstand…Sorry…denke ich brauch da noch etwas Hilfe…
Du legst eine Gruppe an, Name beliebig. Dieser Gruppe weist du dich als einzigen User zu. Außerdem gibst du der Gruppe die E-Mail-Adresse, die du bisher deinem User als zweiten Account gegeben hast (kp@…).
Dann entfernst du bei deinem User diese zweite E-Mail-Adresse wieder (kp@…).
Fertig. Das ist keine Lösung sondern ein typischer Workaround (»nein, du kannst das System nicht ändern, das ist halt so, aber hier ist, wie du es überlisten kannst«).
