TomL hat geschrieben:scientific hat geschrieben:Meine Datei sender.multiuser-multiaccount.passwd odnet jeder Absenderadresse genau einen smarthost mit genau einem loginuser auf diesem smarthost und genau dem richtigen passwort zu.
*hmmm*...merkwürdig.... genau das hätte ja meine Anforderungen erfüllt. Ich muss 10, 20 oder 100 local-domain-Email-Adressen d
er gleichen Anzahl ISP-Email-Adressen zuordnen können. Und der MTA ersetzt dann im Sendeprozess die lokal-domain-Froms durch ISP-Froms und wählt den passenden Relay-Hosts plus zugehörigen ISP-Anmelde-Daten aus. Dabei muss das völlig unabhängig von den Linux-User klappen. Das sind eigentlich die von mir geforderten Schritte.
scientific hat geschrieben:Allerdings gibts keine Zuordnung von einem exim-login zu bestimmten emailadressen....
Das ist imho das Problem... 1 oder 100 locale-domain-Adresses müssen die gleiche Anzahl ISP-Adressen 1:1 konfliktfrei abbilden können. Konfliktfrei ist das Problem, weil die voneinander eigentlich "isolierten" ISP-Provider auf einmal in Dovecot zusammengeführt werden.
Exim hat aber auch die exakte zuordnung von einem Unixuser zu einer externen Adresse... Allerdings nur zu einer..
Warum? Wie? Wieso kennt exim den Linux-User? Das konnte ich bei mir doch gar nicht einstellen. Lediglich für dovecot konnte ich auswählen, ob die Authentifizierung über /etc/shadow stattfinden soll oder über eine eigene gehashte dovecot-userdb. Ich habe mich für die userdb entschieden, weil ich gerade damit auch die Abhängigkeiten zu den Linux-Usern ablösen konnte. Aber dovecot hat doch hinsichtlich der user mit exim auch nix zu tun........
Natürlich kann man exim auch die Unix-User wissen und gegen diese authentifizieren lassen. Mit pam, oder mit sasl. Genauso wie man auch dovecot gegen die Linux-User authentifizieren lassen kann.
Aber es geht natürlich auch mit "virtuellen Usern" wie das in dovecot genannt wird. Dann wird das mit der userdb wie von dir beschrieben gemacht.
Man kann die User-Infos auch in eine sql-Datenbank oder einem LDAP-Verzeichnis ablegen und von dort die Credentials holen/abfragen. Exim ist auch hier extrem vielseitig konfigurierbar.
Ich bin durch die Beschäftigung mit deinem Thema auch wieder einmal (lustigerweise exakt ein Jahr nachdem ich mich dem das letzte Mal intensiver gewidmet habt) in die Thematik eingetaucht.
So wie ich die ganze Geschichte verstehe füttert man sowohl exim als auch dovecot irgend eine User-Datenbank (in welcher Form auch immer), wenn man eine Authentifizierung vor dem Abruf per IMAP/POP3 oder dem Versenden via SMTP von Emails haben möchte.
In Dovecot ist dann entweder in der userdb oder in der allgemeinen Config festgelegt, wo die Emails für die User abgelegt werden. Jeder User (ob virtuell oder reale) erhält dabei ein eigenes Verzeichnis wo alle Emails abgelegt werden (oder in einem Unterverzeichnis davon).
Man kann es so konfigurieren, dass man für SMTP und IMAP/POP die gleichen oder verschiedene Passwörter verwendet. Und wenn man die gleichen Passwörter verwendet, dann hat man die Möglichkeiten, die Infos in - für exim und dovecot - getrennten Datenbanken oder sogar der selben speichert. Man kann die /etc/passwd bzw. /etc/shadow nehmen oder eigene Files oder eben auch eine SQL-Datenbank.
Eine Erhöhung der Sicherheit ist natürlich, wenn man für den Login am Mailaccount ein anderes Passwort verwendet, als für den allenfalls vorhanden Unix-User.
Wenn du den raspi als extra Mailserver konfigurierst, dann haben die dortigen Unix-User einmal überhaupt nix mit den Usern zu tun, die du auf anderen Maschinen konfiguriert hast.
Zum ersten Teil
Ich muss 10, 20 oder 100 local-domain-Email-Adressen der gleichen Anzahl ISP-Email-Adressen zuordnen können. Und der MTA ersetzt dann im Sendeprozess die lokal-domain-Froms durch ISP-Froms und wählt den passenden Relay-Hosts plus zugehörigen ISP-Anmelde-Daten aus. Dabei muss das völlig unabhängig von den Linux-User klappen
Das ist ja genau der Punkt, wo wir die ganze Zeit aneinander vorbeigeredet haben...
MEINE Konfiguration schau so aus.
Ich habe bei 7 Providern 10 Email-Accounts. Davon haben 5 Adressen bis zu 4 Alias-Adressen.
Nach deiner Denke bräuchte ich jetzt auf meinem lokalen Mailserver 10 Email-Accounts in Dovecot - damit habe ich 10 lokale Email-Accounts, die ich irgendwie übersetzen muss.
In meinem Konzept habe ich 1 einzigen lokalen Email-Account. In den sammle ich von den 7 Providern die Emails der 10 Email-Accounts ein.
In Thunderbird habe ich genau diesen einen Account konfiguriert "jakob@localhost"
Der Imap-Server ist localhost, der SMPT-Server ist localhost. Der Username sowohl beim IMAP als auch beim SMTP-Server ist jakob, und das Passwort ist geheim.
Bei mir läuft der Mailserver auf localhost am Laptop, wo auch der Thunderbird läuft. Bei dir würde das statt localhost raspi3.local sein, das tut hier einmal wenig zur Sache.
Verfasse ich in Thunderbird ein neues Email, ist der Absender "jakob@localhost". Das würde einmal relativ wenig bewirken.
Also gibt es in Exim eine Rewriteregel, die in /etc/email-addresses festgelegt ist, wo jakob auf
user.xy@isp.tld umgeschrieben wird.
Das heißt, ich lege in /etc/email-addresses fest, welches mein default-Absender ist, wenn nichts näher spezifiziert ist.
Dieser Account in Thunderbird (geht auch in Evolution, geht auch am Androiden in einem Client, dessen Namen ich jetzt vergessen habe) hat nun mehrere Identitäten.
In jeder dieser Identität trage ich die tatsächliche Email-Adresse bei meinem isp ein. Also z.B.
jakob@gmx.at,
blablubb@tollerprovider.net,
bullubullu@nichtsotollerprovider.com ein. Jede dieser Identitäten bekommt eine andere Signatur, eine andere "Organisation-Kennzeichnung", wenn ich diese Identitäten z.b. für berufliche Emails aus verschiedenen Projekten verwende. Ich kann mir jede Identität so herrichten, wie einen eigenen Account - auch mit Reply-To.
Die Datei /etc/exim4/sender.multiuser-multiaccount.passwd enthält dann in der 1. Spalte dann auch jede einzelne Adresse (inclusive aller Alias) meiner externen Mailprovider.
Und in den weiteren Spalten ist dann der zugehörige SMTP-Server und die Login-Daten enthalten. Die letzten 3 Spalten können durchaus öfter vorkommen - z.B. bei den Alias-Adressen...
Ich sende also als jakob@localhost ein Email mit einem From:
blablubb@tollerprovider.net weg. Exim schaut dann in /etc/exim4/sender.multiuser-multiaccount.passwd welcher SMTP-Server für
blablubb@tollerprovider.net zu nehmen ist und meldet sich dort mit den Credentials an und liefert das EMAIL ab.
Im Header des Emails ist dann als erster Hop jakob@localhost, dann der smtp-Server von tollerprvider.net usw. zu sehen. Für den Empfänger sieht es dann so aus, als ob das Email von meinem Account bei tollerprovider.net abgeschickt worden wäre - obwohl der Zwischenschritt über den lokalen Mailserver mit dabei ist.
In die Datei /etc/exim4/sender.multiuser-multiaccount.passwd musst du als Admin jede einzelne Email-Adresse aller deiner User mit den korrekten Credentials und dem passenden SMTP-Server eintragen. Und da Email-Adressen ohnehin uniq sind, kann es keine zwei gleichen Einträge in der ersten Spalte geben.
Ich hab mir mal ein Szenario überlegt, wo ich diese eine Datei nicht ähnlich wie die .fetchmailrc auch im Userverzeichnis auslagern könnte, damit sie von den Usern selbst gepflegt werden können. Aber da die Anzahl der User bei mir daheim sehr überschaubar ist (wir sind 2 Menschen), hab ich den Ansatz noch nicht weiter verfolgt.
Ein Nachteil dieser Lösung ist natürlich, dass neben dem tatsächlichen Account-Inhaber auch der Admin die Logindaten für die verschiedensten Mailadressen kennt... Aber der Admin kann auch in die .fetchmailrc-Files der User schauen...
Um nochmal zu dem Punkt zurückzukommen, wo wir uns nicht einig wurden: Ich brauche keine gespiegelten Accounts am lokalen Mailserver, damit brauche ich auch keine Mailadressen übersetzen/ersetzen. Ich brauche aber eine Datei, wo zu jeder "echten" Email-Adresse und zu jeder Alias-Adresse Logindaten und SMTP-Server verzeichnet sind.
Eine Verknüpfung mit einem Linux/Unix-User aus der /etc/passwd benötige ich nur, wenn ich ohne weitere Angabe einer Absenderadresse vom Rechner auf dem der Mailserver läuft einen Default-Absender festlegen will/muss.
Mein Mailserver (dovecot/exim4) läuft auf localhost am Laptop. Sende ich von der Shell ein Email mit
echo BLA|mail -s "Blubb"
irgend.jemand@irgend.wo, so wird als Absender im From jener eingetragen (und über den entsprechenden Smarthost gesendet), der in /etc/email-addresses für meinen User jakob festgelegt wurde.
Die "isolierte" Ablage der Mails je ISP-Account habe ich nicht so streng, da ich meine Emails mit Sieve mehr nach Absender und Themen sortiere. Das heißt, mir ist eigentlich ziemlich egal, über welche Email-Adresse ein Email reinkommt, aber wenn im Betreff ein Begriff vorkommt, dann kommt dieses Email in den einen Unterordner, wenn es über jenen Account reinkommt und eine bestimmte Adresse als CC gesetzt ist, dann kommt es in einen anderen Ordner, wenn in der Absenderadresse "debian.org" vorkommt und eine list-id debian-user-german enthält, dann kommt es in einen anderen Ordner... usw.
Ich kann natürlich auch Sieve-Filter-Regeln definieren, welche mir nach To-Adressen filtert, und jene Emails von einem ganz bestimmten Account (z.B. TO: vom Büro-Account) in einen ganz bestimmten Ordner schiebt.
Das habe ich auch mit bestimmten Adressen so in Verwendung. Zusätzlich mit der Geschichte, dass ich mit einer Erweiterung in Thunderbird pro Ordner festlegen kann, welche Adresse bei neuen Emails aus diesem Ordner als From, welche als To usw. gesetzt wird, kann ich in einzelnen Ordnern gezielt ohne weitere Aufmerksamkeit auf den Absender Konversationen führen, die immer über den selben Account raus und rein gehen.
Und ich hab sogar mit dieser Konfiguration alle Emails, die ich von der Commandline mit mail versende in den Gesendeten...
Vielleicht ist es jetzt ein wenig klarer, was ich meine...
Btw: Ich habe auch Roundcube auf dem System. Damit ich ALLE meine Emails einsehen kann, muss ich mich nur mit einem einzigen Usernamen anmelden... In deinem Setup bräuchte ich wieder für jede einzelnen externen Mail-Account ein Login für den "internen" Spiegelaccount... das ist doch mühsam!
lg scientific