Ungewollte Adress Umschreibung Fetchmail/Postfix

Hallo Zusammen,

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

Hat jemand eine Idee, wie ich dies beheben kann?

Danke Theo

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'

auch nichts.

Noch jemand eine Idee.

Viele Grüße Theo

Moin,

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?

Moin, moin Herr Bunkus und danke für Ihre Nachfrage.

postconf -n

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
broken_sasl_auth_clients = yes
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
disable_vrfy_command = no
inet_interfaces = all
inet_protocols = ipv4
local_header_rewrite_clients =
masquerade_domains = $mydomain
masquerade_exceptions = root
message_size_limit = 10240000
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = intranet.doimain.de
mynetworks = 127.0.0.0/8
myorigin = intranet.doimain.de
relayhost = smtp.gmail.com
relocated_maps = hash:/etc/postfix/relocated
smtp_helo_name = intranet.domain.de
smtp_tls_exclude_ciphers = RC4, aNULL
smtp_tls_loglevel = 0
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3
smtp_tls_security_level = may
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unlisted_recipient
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_starttls_timeout = 300s
smtpd_timeout = 300s
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/univention/ssl/intranet.domain.de/cert.pem
smtpd_tls_dh1024_param_file = /etc/postfix/dh_2048.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
smtpd_tls_eecdh_grade = strong
smtpd_tls_exclude_ciphers = RC4, aNULL
smtpd_tls_key_file = /etc/univention/ssl/intranet.rogerkrebs.de/private.key
smtpd_tls_loglevel = 0
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols =
smtpd_tls_received_header = no
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
virtual_alias_domains =
virtual_alias_maps = hash:/etc/postfix/virtual, ldap:/etc/postfix/ldap.groups, ldap:/etc/postfix/ldap.distlist, ldap:/etc/postfix/ldap.sharedfolderremote, ldap:/etc/postfix/ldap.sharedfolderlocal, ldap:/etc/postfix/ldap.virtual
virtual_mailbox_domains = ldap:/etc/postfix/ldap.virtualdomains
virtual_mailbox_maps = hash:/etc/postfix/virtual, ldap:/etc/postfix/ldap.groups, ldap:/etc/postfix/ldap.distlist, ldap:/etc/postfix/ldap.sharedfolderremote, ldap:/etc/postfix/ldap.sharedfolderlocal, ldap:/etc/postfix/ldap.virtual
virtual_transport = lmtp:127.0.0.1:2003

und die canonical ist leer.

Viele Grüße Theo

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?

Lieber Her Buntkus,

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.

Viele Grüße und danke im Voraus Theo

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.

Danke Ihnen noch mal Herr Bunkus,

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.

All the best Theo

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.

Gerne

master.cf

# Warning: This file is auto-generated and might be overwritten by
#          univention-config-registry.
#          Please edit the following file(s) instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
#          univention-config-registry überschrieben werden.
#          Bitte bearbeiten Sie an Stelle dessen die folgende(n) Datei(en):
# 
# 	/etc/univention/templates/files/etc/postfix/master.cf.d/10_services
# 	/etc/univention/templates/files/etc/postfix/master.cf.d/30_antivir
# 	/etc/univention/templates/files/etc/postfix/master.cf.d/70_policy
# 

# ==========================================================================
# service type	private	unpriv	chroot	wakeup	maxproc	command + args
# 		(yes)	(yes)	(yes)	(never)	(50)
# ==========================================================================
25      inet  n       -       n       -       -       smtpd 
465       inet  n       -       n       -       -       smtpd  -o smtpd_sasl_auth_enable=yes -o smtpd_tls_wrappermode=yes
587       inet  n       -       n       -       -       smtpd  -o smtpd_sasl_auth_enable=yes -o smtpd_enforce_tls=yes

#628      inet  n       -       n       -       -       qmqpd
pickup    fifo  n       -       n       60      1       pickup
cleanup   unix  n       -       n       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr
#qmgr     fifo  n       -       n       300     1       nqmgr
rewrite   unix  -       -       n       -       -       trivial-rewrite
bounce    unix  -       -       n       -       0       bounce
defer     unix  -       -       n       -       0       bounce
verify    unix  -       -       n       -       1       verify
flush     unix  n       -       n       1000?   0       flush
smtp      unix  -       -       n       -       -       smtp
showq     unix  n       -       n       -       -       showq
error     unix  -       -       n       -       -       error
local     unix  -       n       n       -       -       local
#virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       n       -       -       lmtp
#587      inet  n       -       n       -       -       smtpd -v -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
relay    unix  -       -       n       -       -       smtp
trace    unix  -       -       n       -       0       bounce
proxymap  unix -       -       n       -       -       proxymap
anvil    unix  -       -       n       -       1       anvil
scache   unix  -       -       -       -       1       scache
discard          unix  -       -       n       -       -       discard
tlsmgr    unix  -       -       n       1000?   1       tlsmgr


smtp-amavis unix -      -       n     -       2  smtp
	-o smtp_data_done_timeout=1200
	-o smtp_send_xforward_command=yes
	-o disable_dns_lookups=yes

127.0.0.1:10025 inet n	-		n	  -		  -	 smtpd
	-o content_filter=
	-o local_recipient_maps=
	-o relay_recipient_maps=
	-o smtpd_restriction_classes=
	-o smtpd_client_restrictions=
	-o smtpd_helo_restrictions=
	-o smtpd_sender_restrictions=
	-o smtpd_recipient_restrictions=permit_mynetworks,reject
	-o mynetworks=127.0.0.0/8
	-o smtpd_authorized_xforward_hosts=127.0.0.0/8
	-o strict_rfc821_envelopes=yes
	-o smtpd_error_sleep_time=0
	-o smtpd_soft_error_limit=1001
	-o smtpd_hard_error_limit=1000

und der Auszug eines Mailprozesses aus dagent.log

Tue Nov 24 19:25:01 2015: [ 5469] Accepted connection from 127.0.0.1
Tue Nov 24 19:25:01 2015: [ 8030] Starting worker for LMTP request pid 8030
Tue Nov 24 19:25:01 2015: [ 8030] Resolved recipient tm@gmail.com as user user1
Tue Nov 24 19:25:01 2015: [ 8030] * Loading plugins started
Tue Nov 24 19:25:01 2015: [ 8030] ** Checking plugins in /var/lib/zarafa/dagent/plugins
Tue Nov 24 19:25:01 2015: [ 8030] * Loading plugins done
Tue Nov 24 19:25:01 2015: [ 8030] Mail will be delivered in Inbox
Tue Nov 24 19:25:01 2015: [ 8030] * PostConverting processing started
Tue Nov 24 19:25:01 2015: [ 8030] * PostConverting processing done
Tue Nov 24 19:25:01 2015: [ 8030] * PreDelivery processing started
Tue Nov 24 19:25:01 2015: [ 8030] * PreDelivery processing done
Tue Nov 24 19:25:01 2015: [ 8030] * PreRuleProcess processing started
Tue Nov 24 19:25:01 2015: [ 8030] * PreRuleProcess processing done
Tue Nov 24 19:25:01 2015: [ 8030] * PostDelivery processing started
Tue Nov 24 19:25:01 2015: [ 8030] * PostDelivery processing done
Tue Nov 24 19:25:01 2015: [ 8030] * SendNewMailNotify processing started
Tue Nov 24 19:25:01 2015: [ 8030] * SendNewMailNotify processing done
Tue Nov 24 19:25:01 2015: [ 8030] Delivered message to 'user1', Subject: "Neue Anmeldung in Firefox auf "Linux"", Message-Id: <wTzob-2jqPlOImFJq1qTgQ@notifications.google.com>
Tue Nov 24 19:25:01 2015: [ 8030] Finished processing message
Tue Nov 24 19:25:01 2015: [ 8030] LMTP thread exiting

Einen schönen abend oder Tag Theodor

OK, danke, leider hilft das auch nicht weiter.

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.

Danke Ihnen.

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.

Viele Grüße und danke für die Geduld Theo

Moin,

danke, das hilft.

Die Header zeigen sehr deutlich, was passiert:

[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.

Schöne Grüße

Hans

@DahanS und Moritz

herzlichen Dank für eure Tipps und Hinweise, da lichtet sich da Sache doch etwas.

Ich hab mal die Stellvertreter Geschichte ausprobiert, leider kommen die Mails dann nicht mehr an.

Es wäre toll Hans, wenn Du beschreiben könntest, wie Du dies gemacht hast (lasse auch ein Bier springen :wink:

Danke im voraus und viele Grüße Theo

Hallo Theo,

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?

Schöne Grüße
Hans

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.

Noch zwei, drei generelle Tipps zu Zarafa:

[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…

Viele Grüße und eine schöne Woche Theo

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«).

Mastodon