Verteilregel anhand "An = Alias-Mail" funktioniert nicht

Apps & App Center
,
#1

Hallo zusammen,

ich habe schon seit Anfang an ein Problem mit der Kombination UCS/Kopano die sich auch nicht gelöst bekomme.

Ich habe (wie wohl die meisten) eine geschäftliche und eine private Mail-Adresse:

beide Domains sind auf dem eigenen Webserver gehostet und als Mail-Domains im UCS auch konfiguriert.

Da ich im UCS (Benutzer) nur eine Box fetchen kann habe ich die Mailbox sven@privat.de bereits auf dem Webserver auf sven@geschäft.de weitergeleitet.

Nun möchte ich in Kopano WebApp eine Regel erstellen:

Eingehende Mail an sven@privat.de verschieben in Ordner Eingang-Privat

Sollte doch ganz einfach sein. Zumindest kenne ich das von allen bisherigen Systemen. Die Regel erstellt -> nichts passiert.

Man schreibt mir:

Hallo Herr Gehr
d.h. Sie wollen eine Regel für die Alias-Adresse erstellen? Das geht nur wenn Sie eine Gruppe mit der Emailadresse anelgen und mit Ihnen als Mitglied.

Also konfiguriere ich folgendes:

Gruppe “privatmail” angelegt mit

  • sven als Mitglied
  • Als Kopano Gruppe
  • Stellvertreter: sven
  • Mail-Adresse: sven@privat.de

Benutzer sven im UCS

Primäre E-Mail-Adresse; sven@geschäft.de
Erw. Einstellungen / Mail / Alternative E-Mail-Adresse: sven@privat.de

Wenn ich nun in WebApp eine Regel erstelle steht diese Empfänger-Adresse auch im globalen Adressbuch zur Auswahl, ich kann meine Regel erstellen.

Aber es passiert nichts. Sie landen bei mir im Posteingang.

Hat jemand eine Idee, ich komme da nicht weiter.

Viele Grüße
Sven

#2

Hi

I had the same thing some time ago i think it was solved by enabling X-Kopano-Rule-Action headers in dagent.cfg file see screen shot

Auswahl_003

rg
Christian

#3

Ich möchte wetten, dass dies der Grund für das beschriebene Verhalten ist. Durch die Weiterleitung fehlt am Ende die ursprüngliche Adresse.

Ps: ich bin mir darüber hinaus nicht sicher ob private und geschäftliche Daten gemischt werden sollten.

#4

also der eigentliche Empfänger ist noch da

Return-Path: <ich@gmail.com>
Received: from saturn.intern.lann ([::ffff:127.0.0.1]:46534)
	by saturn (kopano-dagent) with LMTP;
	Fri, 18 Jan 2019 17:12:50 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by saturn.intern.lann (Postfix) with ESMTP id 2FD8C8C0083
	for <sven@geschäft.de>; Fri, 18 Jan 2019 17:12:50 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.10.1 (20141025) (Debian) at gehr.lan
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-1000 required=5
	tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
	DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,
	RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001]
	autolearn=disabled
Received: from saturn.intern.lann ([127.0.0.1])
	by localhost (saturn.intern.lann [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 1XjrQcVzGRTT for <sven@geschäft.de>;
	Fri, 18 Jan 2019 17:12:49 +0100 (CET)
Received: from saturn.intern.lann (localhost [127.0.0.1])
	by saturn.intern.lann (Postfix) with ESMTP id AE1678C0081
	for <sven@geschäft.de>; Fri, 18 Jan 2019 17:12:49 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	toronto123.server4you.de
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,TVD_SPACE_RATIO
	autolearn=unavailable version=3.3.1
X-Original-To: sven@geschäft.de
Delivered-To: sven@geschäft.de
Received: from mail.dreampixel.de [62.75.220.38]
	by saturn.intern.lann with POP3 (fetchmail-6.3.26)
	for <sven@geschäft.de> (single-drop); Fri, 18 Jan 2019 17:12:49 +0100 (CET)
Received: by mail.gehr-edv.de (Postfix, from userid 110)
	id 1C8C7CD0083; Fri, 18 Jan 2019 17:12:39 +0100 (CET)
X-Original-To: sven@privat.de
Delivered-To: sven@privat.de
Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170])
	by mail.gehr-edv.de (Postfix) with ESMTPS id 5A877CD006D
	for <sven@privat.de>; Fri, 18 Jan 2019 17:12:38 +0100 (CET)
Received: by mail-pf1-f170.google.com with SMTP id y126so6822329pfb.4
        for <sven@privat.de>; Fri, 18 Jan 2019 08:12:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:from:date:message-id:subject:to;
        bh=ewqfiU9Wy481QrZU9W+18qgrLepkBeARmPjpuHIK1As=;
        b=oOweMxs5kxf6EG2rsSxnmUuMT5vSyMUwPt9GVt1lSFNLUDGZt+ruuzghcrBhArNAAB
         QfO40DZDBenPhltG991kvZ8u+9pySR7eg1A+ebqEh/TGbVknY40tXVbGRgiESqFKkrpX
         Mdy3NgNyez4iPIpDtWQ8y8fbXcCimnZVKOfNDDkkyDv80kjcULsD6EUxH7PfbY+mm/oo
         YA13daIshOH+nmXQtcrEkCy0vUYl6XyWZzP+EvMx9SYxooD5OFYHWObXafARVrjxYhmx
         nzo9j2dHFSBo4U+oTwwuA+0KS/PYmjy7R9vJQ5phNjMhiXVwXJOtWRi0tMlq1tOsOjad
         FNfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=ewqfiU9Wy481QrZU9W+18qgrLepkBeARmPjpuHIK1As=;
        b=rmciOx4pM7+evcoL+zjdCzUpFVVX4XlepJ9IGP6IS4YSzzHC+DTBR8xK1V0FsFO1hd
         eVG5wUGUvyrTcuHP5oIkNFNsH0TkhvsNy9ILsrLJGVLQ9BhdRbgVYAYNRSJsoUiNc0IG
         dZIDwVe5uzvE9Ge+8xpTt8rzvBHNWZmFfslRJTli0RhFOESydShuJNcYmjL6mY39lp9m
         nboBaCp1M1SkdD089eLaWvWsjXZyVllfLcQjgaE7xJXYuJH8s38sHwoL30DbhKrXi+qj
         n42OeiPxrKvjLJyV42WmGC0JLFsWil9pBSwIppPGWSJMtMQ0thoKh+yn42xu2iYbaHRz
         Q3VQ==
X-Gm-Message-State: AJcUukcU1wGqBDGX3LT5RlpdBTT/NWAuX9BbovBMfNhL0+3k68mmF/rt
	V3OHLOAyuRhkeY3e/zf49lnVc7kPpkcSU3VIJR73WA==
X-Google-Smtp-Source: ALg8bN4zrSYmgnY8EJlNM3MhG9uZaRX2b3pxDu+b49lJ4hCj9ASsnVVmAMKSDfm5vYdk9KD9kjTrKF8OnpMHFL8TnFY=
X-Received: by 2002:a63:4a0a:: with SMTP id x10mr18284334pga.237.1547827951180;
 Fri, 18 Jan 2019 08:12:31 -0800 (PST)
MIME-Version: 1.0
From: Sven Gehr <ich@gmail.com>
Date: Fri, 18 Jan 2019 17:12:20 +0100
Message-ID: <CAFJA1EqEHO_7KJ526RXkr=+3RNxkUxqncVz383xWSdL-7hX57Q@mail.gmail.com>
Subject: Test07
To: sven@privat.de
Content-Type: multipart/alternative; boundary="000000000000341e9a057fbdc7b9"

--000000000000341e9a057fbdc7b9
Content-Type: text/plain; charset="UTF-8"



--000000000000341e9a057fbdc7b9
Content-Type: text/html; charset="UTF-8"

<div dir="ltr"><br></div>

--000000000000341e9a057fbdc7b9--
#5

Das mag sein, zugestellt wird aber dennoch an die geschäftliche Adresse:

#6

AFAIR i did not get this to work with fetchmail - it works for me after setting an forward rule on my private mailbox at the provider (in this case GMX) to my business account (kopano local server) - then the rules are applied correctly in kopano

rg
Christian

#7

Ok, lassen mir mal meine Konstellation mit geschäft und privat außer acht. Das war ohnehin nur um die Problematik auf einem Produktivsystem zu testen.

Dort passiert aber genau das gleiche.

Die Benutzerin in der Buchhaltung hat die Mail-Adresse vorname.nachname@domain.de. Bereits auf dem Webserver ist für Ihre Box der Alias rechnung@domain.de eingerichtet. Es ist also keine Weiterleitung!

Hier nochmal alle Einstellungen relevanten Einstellungen:

** UMC / Benutzer vorname.nachname **

  • Allgemein *

Primäre E-Mail-Adresse: vorname.nachname@domain.de

  • Erweiterte Einstellungen / Mail *

Alternative E-Mail-Adresse: rechnung@domain.de

–> Gehört die Mail-Adresse eventuell und/oder in UMC / Benutzer / Kontakt / Feld “Geschäftliche Mai-Adresse” ?

Die Gruppe (Kopano / Mail - Alias) habe ich wieder wie folgt angelegt:

** UMC / Gruppen / Gruppe “rechnungsmail” **

  • Allgemein *

Name: rechnungsmail
Mitgrieder: vorname.nachname (also der besagte User)

  • Kopano *

Kopano Gruppe: [X]
Stellvertreter: vorname.nachname (also der besagte User)

  • Erweiterte Einstellungen *

Mail-Adresse: rechnung@domain.de

Regel habe ich angelegt, da kann man ja auch nicht viel falsch machen.

Regelname: RE-Eingang
Falls die Nachricht…: gesendet an … -> rechnungsmail mit rechnung@domain.de im glob. Adressbuch gewählt.

Folgende Aktion ausführen: In Ordner verschieben

Ich sende von extern eine Mail an rechnung@domain.de -> Ordner rechnungsengang in Public gewählt.

Mail von extern an rechnung@domain.de -> Nichts. Sie langdet bei der Mitarbeiterin im Posteingang.

Ich vertehe nach vielen Stunden das Problem einfach nicht :frowning:

#8

Naja, der “Trick” mit der E-Mail Adresse an der Gruppe funktioniert nicht, wenn die E-Mail nach wie vor beim Benutzer zugestellt wird. (eventuell hat das Alias beim Nutzer auch einen nachteiligen Effekt).

Was getan werden muss:

  • Gruppe erstellen und der Gruppe eine E-Mail Adresse zuweisen (und den Benutzer als Mitglied der Gruppe hinzufügen)
  • Weiterleitung auf dem externen Server deaktivieren
  • Stattdessen in Fetchmail einen Job einrichten, der die E-Mail Adresse vom externen Server abruft und direkt an die Gruppe übergibt (wenn das nicht über die UCS UI geht, dann halt einen eigenen Job dafür einrichten)
1 Like
#9

da ich mir gestern mal kopano installed habe stand ich vor einem ähnlichen problem.
Ich habe innerhalb einer Domain zig Aliase, unter anderem für technik/postmaster/info etc etc etc.
Je nach Wichtigkeit unterscheide ich gerne wann ich die ansehe und wollte mir die gerne direkt nach Empfang in Unterordner mit einer regel sortieren lassen.

Ich habe sowas gerne direkt aus meinem Posteingang raus , der Übersicht wegen.

Wenn ich das richtig sehe kann ich unterhalb eines Accounts jede Menge aliases einrichten, die werden dann zugesellt haben aber als Empfänger immer die primäre Adresse bekommen, statt die alte zu belassen.

Auch wenn ich eine Gruppe anlege kann ich der Gruppe keine Aliase sondern nur accounts zuweisen.

Der Workaround den ich sehe wäre 3/4/5 Accounts anlegen, denen nach Wichtigkeit die Aliase zuweisen
dann nach den Gruppen zu filtern im regelwerk und dann in Ordern einsortieren zu lassen.

Oder hat jemand da eine andere idee?

#10

Dies Aussage verstehe ich nicht.

#11

Nun, in einem normalen Benutzer habe ich eine primäre email adresse und kann unter erweiterete Einstellungen dem Benutzer noch weitere emailadressen zuordnen, das sind dann für mich “Aliase”

Hier ist das “Problem” das ich bei erhalt einer Email an die “aliase” nicht mit regeln filtern kann. Das Problem ist ja bekannt.

In einer Gruppe habe ich nur die Emailadresse der Gruppe, der Gruppe kann ich keine Aliase also weitere Emailadressen zuordnen, jedenfalls finde ich das nicht, ich kann der Gruppe nur weitere gruppen oder andere benutzer zuordnen.

#12

Ja, aber warum willst du der Gruppe weitere Aliase zuordnen?

Damit bist du dann doch wieder bei deinem ersten Problem: Alle an eine der Gruppe zugeordneten Aliase gesendeten Mails werden gegen die primären Adresse aufgelöst und dann siehst du diese wieder nicht.

#13

ok, machen wir es anders:

meine primäre email ist frank@example.com

meine bei Facebook hinterlegt ist facebook@example.com
meine bei Instagram ist instagram@… usw usw usw,
dazu habe ich noch diverse domains wo ich postmaster, einkäufer etc pp bin,
dazu noch die technik, wo mir diverse Daemons die tagesberichte nachts schicken…

Auch gibt es ein Monitoring wo “wichtige” (schicken meistens sowieso per sms alarm)
aber auch semiwichtige Mails generiert werden.
Wie du siehst kriege ich an 300 emails pro tag die je nach Wichtigkeit abgearbeitet gehören, manche mit ne groben Blick manche doch genauer, um der Flut Herr zu werden will ich die Mails vorsortieren, und zwar in Ordnern so das ich den normalen Posteingang mit normalen Mails an meine prmäre email im Auge behalte und beim händischen Verschieben oder löschen nicht versehentlich was wichtiges mit verschiebe, wie schon manchmal passiert.

Der normale Weg, nämlich mehrere Accounts anzulegen dafür ist nicht das Mittel der Wahl

Wie würdest du denn das hier erledigen

#14

Das klingt ein wenig so, als wäre deine Frage nicht “wie erstelle ich 300 Aliase”, sondern “wie richte ich eine Catch-All E-Mail Adresse ein”.

Am Rande:

Wir reden hier nicht von mehreren Accounts, sondern von mehreren Gruppen die dann ein einen oder mehrere Accounts (dein eigentliches Postfach) zustellen.

#15

Guten Morgen,

nein, eine Catch All Adresse ist definitiv nicht erwünscht. Weil auch das würde mich ja nicht weiterbringen.
Das Ursrprungsproblem war ja ich habe zig verschiedene “aliases” oder nennen wir es wie es Kopano auf deutsch nennt “alternative Email Adressen” die einem benutzer zugeordnet wurden.

Anhand dieser wollte ich eine regel bauen und diese direkt bei empfang der Mail diese in Ordner einsortieren.

Nochmals Beispiel:
Ich habe einige Server am Laufen, diese generieren Server Reports. diese werden an root@example. com
versendet, ich mache einen Unterordner Server, alles was an root@example .com gesendet wird soll direkt in den Unterordner Server gesendet werden. Aus historischen Gründen habe ich da aber nicht nur root@example .org, sonder auch hostmaster@example .com oder technik@example. com.

Derzeit sind server/hostmaster/technik@example. com ja im Kopano unter meinem Benutzer “alternative” emailadressen. Das heisst im Standard erscheinen die Mails in meinem Postfach so als als wenn Sie an meine primäre Emailadresse geschrieben wären. Kopano handelt die Mails so als wenn alle Mails an die primäre Emailadresse geschrieben wären. Ich brauche jetzt einen Work Around wie ich es hinbekomme die Mail nach meinen Bedürfnissen direkt beim Empfang in passende Unterordner einzusortieren (dies war beim Vorgänger Zarafa ohne Probleme möglich)

bitte keine Ideen nach dem Motto, geh doch auf den Betreff oder sonstiges beim Regelbau, ich möchte einen Workaround finden der auf den Empfänger der Mail geht.

#16

Die Technik ist hier nach wie vor 1:1 die gleiche.

Ok, wenn es sich hier um unterschiedliche Domains handelt (und solche Mails dann eventuell auch an mehr als eine Person zugestellt werden sollen), dann ist ein simples Catch-all Postfach vielleicht in der Tat nicht das richtige.

Sofern du nicht für jedes deiner Aliase eine Gruppe zur Namensauflösung anlegen willst, dann bleibt natürlich noch “Plan B”, Kopano das Wissen über das Alias zu entziehen und damit einer interne Auflösung zu verhindern. Da es sich dann hier mutmaßlich eher für den Empfang genutzte Aliase handelt (und nicht darüber gesendet werden soll) sollte das auch kein Problem darstellen.

ucr set kopano/cfg/ldap/ldap_emailaliases_attribute=invalid

#17

Also ich habe das nochmal getestet. Wenn ich die alternative Mail-Adresse im Benutzer entferne (also der Alisa raus ist), ich eine Gruppe mit dem Mitglied (ich) und in der Gruppe die Mail-Adresse die vorher bei mir als “Alternativ” angegeben war greift die Verteil-Regel anhand dieses Empfängers.

Allerdings kann ich dann mit dieser Adresse nicht mehr senden.

#18

Crosspost: https://forum.kopano.io/topic/3135/distribute-mails-using-alias-address

#19

Hallo,

ich bin gerade von Zimbra auf UCS Kopano umgestiegen und habe hier nun das gleiche Problem.

Ich habe verschiedene Mailadressen auf verschiedenen Domains. z.B.

info @domain1.de
mail @domain1.de

mail @domain2.de
spam @domain2.de

Ich nutze diese Adressen sowohl zum Empfangen als auch zum Senden.

Weiterhin möchte ich, genau wie meine Vorredner, die eingehenden E-Mails gerne je nach Empfängeradresse automatisch in verschiedene Unterordner einsortieren lassen. Dies ist allerdings nicht möglich, da die Empfänger-Email (Alias) mit der Haupt-Email des Benutzerkontos überschrieben wird. Auf meinem alten Zimbra Mailserver war die gewünschte Konstellation problemlos möglich.

Die DAGENT RULE wie oben vorgeschlagen, habe ich schon ausprobiert, doch dies hat leider keine Verbesserung gebracht.

Hat schon jemand eine Lösung?

Liebe Grüße
Christoph

#20

Hallo @arny80hexa,

Ich habe in Verteilregel anhand "An = Alias-Mail" funktioniert nicht beschrieben wie dies in meinen Augen funktionieren kann.

Mastodon