[SOLVED] exim4 und acl

[scientific]

Hi Leute!

Bedingt durch die Diskussion mit TomL unlängst über exim, mehrere Account und wie man das am besten lösen könnte, hab ich mich wieder einmal über meine Konfiguration hergemacht.
Ich habe nämlich eine (bei mir momentan bedingt durch die Userzahl = 1 verschwindend wichtige) Sicherheitslücke entdeckt.

Meine Konfiguration stellt folgende in Exim bislang nicht zur Verfügung stehende Funktion her:
Ein Login-User (authentifiziertes SMTP) kann mehrere Absender-Adressen bei verschiedenen Mailprovidern haben.
Exim sucht zur Absenderadrese in einem File dann sowohl den Smarthost, als auch Username und Passwort, damit bei diesem Smarthost das Email abgeliefert werden kann.

Der Hintergrund dazu ist, dass ich - scientific - bei Google, bei GMX, bei meinem Arbeitgeber, bei meinem Provider meines Webservers und noch bei div. anderen Mailprovidern je einen oder mehrere Mailaccounts mit manchmal auch mehreren sendeberechtigten Alias-Adressen habe. Da es mühsam ist, für jeden Provider die Webmail-Oberflächen immer wieder zu öffnen, und da mein Standardclient Thunderbird ist, und da ich nicht immer alle dieser Kanäle gleichwertig und intensiv in der Vergangenheit genutzt habe, trudeln z.T. ähnliche Informationen über verschiedene Email-Adresse bei mir ein.

Ich habe mir zu diesem Zweck einen lokalen Email-Server mit exim4, dovecot/sieve und roundcube aufgesetzt, wo mir fetchmail regelmässig alle meine Postfächer pollt über exim an dovecot weiterleitet, dieser mit sieve über einen ausgewachsenen Regelsatz dann die Emails Themenmäßig, nach Absendern, nach Empfängeradresse oder anderen Kriterien in die verschiedensten Ordner am Imap-Server gleich einsortiert.

Ich sehe mir dann meine Emails mit Thunderbird (oder von auswärts über eine ssh-Verbindung mit Portforwarding über Roundcube) am IMAP-Server an und versende über exim.

Da ich aber einige dieser Adressen auch als Absender verwenden möchte/muss (auch Alias), benötigte ich eine Konfiguration, die mir zu jeder Absenderadresse (Thunderbird stellt über die Funktion "Identitäten" die Möglichkeit zur Verfügung, eine andere Absenderadresse als jene des Accounts zu verwenden, und dennoch über den SMTP-Server des Accounts zu senden) eben den zugehörigen Smarthost (SMTP-Server des Email-Providers) mit den entsprechenden Credentials auszuwählen und über diesen dann das Mail zu versenden.

Ich habe probehalber einen zweiten lokalen Mailuser angelegt (Username: scientificsfreundin).
Dieser zweite User hat eine eigene Mailbox in dovecot, muss sich extra authentifizieren und bekommt in Thunderbird ein eigenes Mailkonto auf localhost.

Wenn ich scientificsfreundin eine Identität verpasse, welche eine absendermailadresse hat, die schon scientific hat, kann scientificsfreundin das Email mit der absenderadresse scientific@mailprovider.example senden.

Das ist prinzipiell bei mir egal, da scientificsfreundin vorerst dieses Setup gar nicht nutzt und ich der einzige User bin, der überhaupt über diesen SMTP-Server Mails versendet.

Ich hab mir in dem File jetzt ein zusätzliches Feld mit dem Usernamen ($authenticated_id) eingebaut und versuche eine ACL zu bauen, welche mir beim Abliefern des Emails an den SMTP-Server (also exim4 in der Funktion als Server) prüft, ob $authenticated_id mit der zweiten Spalte in der Zeile mit der ABsenderadresse übereinstimmt. Dann nimmt exim das Email an, sonst lehnt er das Senden mit der Fehlermeldung ab, dass der Loginuser diese Absenderadresse nicht verwenden darf.

Das funktioniert gut - bis auf die Tatsache, dass die erste Spalte eindeutig sein muss. Ich kann dort nicht zweimal die selbe Email-Adresse mit je einem anderen loginuser anführen.

Das eigentliche Problem ist, dass diese ACL sowohl beim Senden von Thunderbird aus abgearbeitet wird (das ist gewollt), als auch wenn ich von der Commandozeile mit mail ein Email sende (so will ich das auch haben). Aber es wird auch abgearbeitet, wenn ein Daemon ein Email sendet (soll so nicht sein) und wenn fetchmail die Emails abliefert (soll auch nicht sein).

Ich hab die ACL in acl_check_mail eingebaut... diese wird nach dem einliefert der Absendeadresse geprüft.

Wie kann ich die ACL mit Conditions so gestalten, dass sie nur für smtp-Sitzungen gültig ist, wenn ein authentifizierter User ein Email abliefert, jedoch nicht wenn das Email rausgesendet wird oder von fetchmail (und anderen Daemonen) ankommt?

lg scientific

[TomL]

Hi scientific

Bedingt durch die Diskussion mit TomL unlängst über exim, mehrere Account und wie man das am besten lösen könnte,

Ich muss gestehen, dass ich in dem Thread Deinen Prozess vermutlich nicht in Gänze kapiert habe.

Weil mich das Thema allerdings auch ziemlich interessiert, habe ich mir heute mittag den Text hier zweimal durchgelesen. Und weil ich das alles irgendwie nicht nachvollziehen konnte, dachte ich mir "Les' es abends noch mal in Ruhe". Und jetzt bin ich genauso weit... ich kapier das immer noch nicht.

Ich verstehe einfach nicht, warum Du immer von exim4 im Zusammenhang mit Fetchmail sprichst und wieso exim Mails zuerst an Dovecot weiterleitet (wohin dort?), um sie dann von einem weiteren Prozess "einsortieren" zu lassen.

....wo mir fetchmail regelmässig alle meine Postfächer pollt über exim an dovecot weiterleitet, dieser mit sieve über einen ausgewachsenen Regelsatz dann die Emails Themenmäßig, nach Absendern, nach Empfängeradresse oder anderen Kriterien in die verschiedensten Ordner am Imap-Server gleich einsortiert.

Bei mir läuft ja postfix als Alternative zu exim4. Und bei mir hat postfix mit dem Prozess "Mail holen" überhaupt nix zu tun. Ist das bei Dir mit exim4 anders gelöst? Wie geht das...?... wie hast Du exim in den fetchmail-Prozess eingebunden...?... wo doch exim4 auf seiner Wiki-Page selber sagt:
"Exim provides MTA functionality - that is, it delivers mail. POP and IMAP are two of several ways of reading previously-delivered mail. Exim does not provide that functionality."

Weil das so eine dicke Baustelle war und ich mir sicher bin, dass ich die Zusammenhänge meiner eigenen Lösung in einem Jahr oder später kaum noch auf die Reihe bekommen werde, habe ich mir eine recht umfassende Dokumentation erstellt.... so, wie ich die Zusammenhänge verstanden habe und mit derer ich das später alles mal besser nachvollziehen können will. Gibt es da Ählichkeiten zu Deinem Prozess...?... ähnlicher Ablauf, nur andere Programme....?... wo driftet das vielleicht völlig auseinander?

[scientific]

Hi Tom!

Fetchmail holt die Emails bei den Mailkonten ab, die ich ihm angebe und liefert sie auf dem Rechner localhost auf Port 25 ab.
Damit landen die Emails bei mir in exim, der auf Port 25 lauscht.
Da in der fetchmailrc die Option "is scientific" vorhanden ist, ist die Empfängeradresse in diesem SMTP-Prozess "scientific@$HOSTNAME"

Damit laufen die Emails die fetchmail abholt über allfälige Bogofilter, Spamassassin und AV-Prozesse, welche in Exim konfiguriert werden können (bei mir derzeit nur bogofilter) und werden dann über einen speziellen transport lokal zugestellt.

Damit fetchmail DIREKT in den Mailspool ablegt (über den Local-Delivery-Agent konkret dovecot-lda) muss in .fetchmailrc eine zusätzliche Option angegeben werden:

Code: Alles auswählen

mda "HOME=/home/%T /usr/bin/sudo -u %T /usr/lib/dovecot/deliver"

Das hab ich aber bei mir nicht gemacht - siehe Erklärung weiter unten.

Wenn fetchmail also die geholten Emails auf Port 25 abkippt, verarbeitet diese exim weiter wie oben genannt.
exim kann diese Emails direkt in ein Maildir oder Mailspool ablegen, muss das aber nicht tun.
Man kann in Exim für "local delivery" auch einen eigenen Transport definieren.
Exim kann per lmtp, smtp oder auch über dovecot-lda das Email in den dovecot einliefern. Ich habe dovecot-lda gewählt.

Der Transport schaut konkret so aus:

Code: Alles auswählen

dovecot_delivery:
  driver = pipe

  # Use /usr/lib/dovecot/dovecot-lda  if using Debian's package.
  # You may or may not want to add -d $local_part@$domain depending on if you need a userdb lookup done.
  #command = /usr/local/libexec/dovecot/dovecot-lda -f $sender_address
  command = /usr/lib/dovecot/dovecot-lda -f $sender_address

  message_prefix =
  message_suffix =
  log_output
  delivery_date_add
  envelope_to_add
  return_path_add
  #group = mail
  #mode = 0660
  temp_errors = 64 : 69 : 70: 71 : 72 : 73 : 74 : 75 : 78

Damit übergibt exim die geprüften und markierten Emails (z.B. X-Bogosity: ... als Header zusätzlich eingefügt) an dovecot.

Dovecot hat als IMAP-Server eine Erweiterungsmöglichkeit die sich "Sieve-Filter" nennt. Das ist eine serverseitige Vorsortierung von Emails in verschiedenste Unterordner in der Inbox.
Würde fetchmail oder exim die Emails in den Mailspool ablegen, kommen diese direkt in die INBOX und würden genau dort bleiben. (Ich hab zumindest noch keine Möglichkeit gesehen, wie fetchmail oder auch exim sinnvollerweise die Emails in Unterordner einsortieren könnte).

Wie ich schon erwähnte, habe ich viele Emailadressen mit auch Aliases bei den Unterschiedlichsten Mailprovidern die ich alle für verschiedenste Bereiche in Verwendung habe.
Arbeit, Hobby, Diskussionen auf Mailinglisten, Nebenjob, politische Aktivitäten, Vereine wo ich Mitglied bin und eine Mailadresse habe... usw.
Und da ich nicht immer ganz scharf Abgrenzungen machen kann, oder gemacht habe, welche Adresse für welchen Themenbereich "zuständig" ist, kommen Emails die zusammengehören aber über verschiedene Email-Adressen rein. Diese sind ansich relativ leicht filterbar und somit in einen Ordner zusammenführbar.
Z.B. hat ein Studienkollege, der dann auf der Uni weitergearbeitet hat, ebenfalls bei der selben Organisation wie ich politisch aktiv war auch gleich einen ganzen Bulk an Email-Adressen die er bunt durcheinander mischt.
Das bedeutet, ich setze einen Filter der alle seine mir bekannten Emailadressen anspricht und verschiebe alle seine Emails in einen einzigen Ordner am IMAP-Server der seinen Namen trägt.
Da er aber auch auf 3 verschiednen Mailinglisten schreibt und die Emails dieser Mailinglisten aber in den Ordnern die ich für diese Mailinglisten erstellt habe bleiben sollen (egal ob sie von meinen Studienkollegen sind oder nicht) kommen diese Emails eben in die Ordner der Mailingliste und nicht in den mit dem Namen meines Kollegen.

Da eine händische Sortierung aus der Inbox in Thunderbird in über 100 verschiedene Unterordner wirklich mühsam ist, lasse ich diese von Sieve in Dovecot vorsortieren.

Um beim Beispiel meines Studienkollegen zu bleiben (das ist in der Tat ein reales Beispiel):
Egal auf welche Email-Adresse ich von ihm ein Email bekomme, und egal von welcher seiner zahlreichen Adressen das Email weggeschickt wurde, ich finde seine Emails in genau einem Ordner der seinen Namen trägt.
Emails meines Kollegen an bestimmte Mailinglisten kommen nicht in den Namensordner sondern in den der Mailingliste.
Kommt SPAM von ihm (oder mit seiner Absenderadresse), so erkennt diesen Bogofilter und schiebt ihn in den Junkordner.

Das erledigt Dovecot mit Sieve beim Einliefern für mich vollautomatisch.

Und dazu benötige ich fetchmail, welches an exim liefert, und exim das die Spam-Erkennung macht und dovecot, der die Emails sortiert.

Vielleicht verstehst du jetzt besser, warum ich für alle meine verschiedenen Emailaccounts bei den ISPs nur einen einzigen IMAP-Account am lokalen Mailserver eingerichtet habe.
Ich würde nämlich die Emails von meinem Kollegen dann in Thunderbird in 8 verschiedenen Accounts zusammensuchen müssen.
Denn so wie ich dein Setup verstanden habe, hast du auf deinem IMAP-Server für jeden Account bei jedem ISP einen gespiegelten Account angelegt. Und du hast in Thunderbird jeden dieser Accounts angelegt. Also je eine Inbox, einen Gesendet-Ordner, einen Junk-Ordner div. Unterordner JE Emailadresse? Hab ich das richtig verstanden?

Oder um es anders zu formulieren.
Ich habe die Emailadresse
scientific@ISP1.example
scientific@ISP2.example
blubb@ISP2.example
Bla@ISP3.example

Dann hätte mich mit deiner Konfiguration am eigenen IMAP-Server
scientific@localhost
scientific@localhost (ginge das dann bei dir überhaupt?)
blubb@localhost
bla@localhost

oder heißen die
scientific-isp1@localhost
scientific-isp2@localhost
blubb-isp2@localhost
bla-isp3@localhost

Dann hast du in Thunderbird ebenfalls diese 4 Konten angelegt.

Und verwendest du keine Unterordner (IMAP-Folder) in deinen Accounts bzw. sortierst du manuell die Emails?

lg scientific

[scientific]

Wenn ich dann aber mehrere solcher lokalen Email-Accounts habe, so kann von jedem Account JEDE konfigurierte externe Emailadresse als Absender gesetzt werden.
Und um das zu verhindern, benötige ich eine ACL, die mir die Annahme eines Emails verweigert, wenn der per SMTP-AUTH authentfizierte User einen anderen als für ihn erlaubten From-Header gesetzt hat.

Per ACL bekommt der dann im Client auch eine Fehlermeldung.

Aber fetchmail und andere Daemons sollen trotzdem emails an localhost senden können. Ohne Authentifizierung und prüfung, ob sie das dürfen.

Und DA steh ich auf dem Schlauch.

Lg scientific

[TomL]

Wenn fetchmail also die geholten Emails auf Port 25 abkippt, verarbeitet diese exim weiter wie oben genannt.
exim kann diese Emails direkt in ein Maildir oder Mailspool ablegen, muss das aber nicht tun.
Man kann in Exim für "local delivery" auch einen eigenen Transport definieren.
Exim kann per lmtp, smtp oder auch über dovecot-lda das Email in den dovecot einliefern. Ich habe dovecot-lda gewählt.
::::::
Das erledigt Dovecot mit Sieve beim Einliefern für mich vollautomatisch.
Und dazu benötige ich fetchmail, welches an exim liefert, und exim das die Spam-Erkennung macht und dovecot, der die Emails sortiert.
::::
Denn so wie ich dein Setup verstanden habe, hast du auf deinem IMAP-Server für jeden Account bei jedem ISP einen gespiegelten Account angelegt. Und du hast in Thunderbird jeden dieser Accounts angelegt. Also je eine Inbox, einen Gesendet-Ordner, einen Junk-Ordner div. Unterordner JE Emailadresse? Hab ich das richtig verstanden?
:::::
Dann hast du in Thunderbird ebenfalls diese 4 Konten angelegt.
::::::
Und verwendest du keine Unterordner (IMAP-Folder) in deinen Accounts bzw. sortierst du manuell die Emails?

Also ich habe jetzt verstanden, dass Dein Prozess ziemlich anders aussieht, als meiner. Im wesentlichen bedingt durch die Einbindung von Exim ins Polling, um gewisse weitere Filter zu haben und dann durch Sieve.

Ich habe anscheinend dazu aber völlig andere Anforderungen. Das wichtigste ist, ich will keinen Filter. Ich will nicht, dass ein Filter mir Mails löscht, abweist oder vorenthält. Es ist jetzt schon so, dass wirklich >85% Spam einer doch eher erträglichen Gesamtmenge vollautomatisch im lokalen Thunderbird-Spam-Ordner landet, der "älter 7 Tage" automatisch geleert wird. Darüber hinaus kommt das meiste an Spam sowieso nur über die Fake-Accounts, die ich gar nicht in meinen Mailprozess eingebunden habe. Die werden alle direkt via IMAP beim ISP abefragt, von TB wird nur der Header (ohne Body runtergeladen) und der Header verschwindet fast immer sofort im TB-Spam-Ordner. Das bereiten also die ISP eigentlich schon perfekt für mich vor. Spam-Mail kommen fast gar nicht bei mir an... also brauch ich dafür auch keinen weiteren lokalen Filter auf dem Mailserver.

Meine Anforderungen sind: Unsere regulären (!) personifizierten Mailaccounts sollen beim User-Event "Login" vollständig per POP3 runtergeladen werden und in die entsprechenden Order/Postfächer des User eingestellt werden. Das war ja früher mit dem Direkt-ISP-Account durch Thunderbird genauso, deswegen will ich das heute auch beibehalten.... weils einfach unserer Gewohnheit entspricht und alles verwechselungsfrei ordentlich getrennt ist. Also... der Anwender startet Thunderbird uns sieht ein paar Sekunden später (wg. Polling) in welchem seiner Postfächer Emails angekommen sind.

Das heisst, ich will
- ein userbezogenes Polling
- es muss ein Login-Event-Gesteuertes Polling sein (wg. außerhalb der Thunderbird-Zeiten und der Mobiles)
- keine Filter
- reine Mail-in-Postfach-Verteilregeln

Die Dovecot-Postfächer aller User liegen zusammen und nebeneinander in einer flachen Verzeichnishierarchie vor. Welcher User sich in welchen Postfächern anmelden darf, regelt allein der Dovecot-Accountname und das dazugehörige Password. Über die Verteilregeln kann ich die eingehenden Mails eines Users auf beliebige Postfächer dieses Users oder auf Unterordner eines seiner Postfächer weiterleiten. Wenn z.B. wie bei den Werbe-Rundschreiben von GMX kein sauberer Empfänger eingetragen ist, geht das gleich ab in den Ordner "Spam" und fällt gar nicht erst unangenehm auf.

Ich habe die Dokumentation meiner Mail-Prozesse für mich noch mal aktualisiert. Je mehr ich drüber nachdenke, um so unsicherer werde ich, ob ich das alles beim Upgrade des Servers auf Stretch gedanklich noch ordentlich reproduzieren kann. So sieht meine Lösung (skizziiert nach meinem Verständnis des Zusammenspiels der Komponenten) aus... das müsste auch Deine Frage beantworten.

Wenn ich dann aber mehrere solcher lokalen Email-Accounts habe, so kann von jedem Account JEDE konfigurierte externe Emailadresse als Absender gesetzt werden.
Und um das zu verhindern, benötige ich eine ACL, die mir die Annahme eines Emails verweigert, wenn der per SMTP-AUTH authentfizierte User einen anderen als für ihn erlaubten From-Header gesetzt hat.

Ja, das habe ich heute auch mal getestet. Ich war verblüfft. Wenn ich die lokale Mailadresse (meiner Mail-Domain) eines User kenne (na klar kenne ich die), kann ich als "Benutzerdefinierter Absender" über Thunderbird einen anderen Absender eintragen. Meine Postfix-Filter können das nicht erkennen, sie suchen sich einfach den korrekten Relay-SMTP raus und senden die Mail. Aber ich bin ziemlich sicher, dass hier keiner auf diese Lücke kommt.... und auch keiner hier eine Notwendigkeit dafür hätte, sowas überhaupt zu suchen und zu probieren.... ich werde das deshalb erst mal ignorieren.

[TomL]

Nachtrag:

Gerade hat es wohl endlich bei mir "Klick" im Kopp gemacht.... und ich habe kapiert, was an Deinem Prozess anders ist. Der Unterschied ist, mein MTA (Postfix) stellt nur in einer Richtung zu, und zwar nur beim Senden, bei Dir aber Exim4 in beiden Richtungen. Beim Senden bei mir:
Thunderbird -> Dovecot -> Postfix -> SMTP-Relay

Dieser Teil ist vermutlich bei uns beiden prinzipiell gleich, bei Dir allerdings mit Exim4:
Thunderbird -> Dovecot -> Exmi4 -> SMTP-Relay

Aber der Empfang sieht anders aus, bei mir
Getmail -> Procmail -> Dovecot

Und in Deinem Modell, so wie ich das jetzt verstanden habe, sendet Fetchmail an Exim4 zum Zwecke der Zustellung im LAN
Fetchmail -> Exim4 -> Dovecot mit Plugin Sieve

Exim4 wird bei Dir also einfach als Mail-Tansporter in beiden Richtungen verwendet, sowohl beim Send als auch beim Receive. Exim4 bekommt die Mails also einmal von Thunderbird/Dovecot und einmal von Fetchmail. Beim Senden transportiert Exim zum Relayhost, beim Empfang transportiert Exim sie an den Pseudo-Empfänger "sieve" in Dovecot weiter, der sie auf Spam filtert und in die Postfächer einsortiert.... also den Teil des Jobs, der bei mir von procmail erledigt wird.

Exim4 und sieve machen beim Empfang prinzipiell also etwas ähnliches wie mein procmail..... nur habe ich eben keinen Filter, den ich auch nicht will, weil ISP und Thunderbird das imho schon perfekt abhandeln. sieve ist in Dovecot integriert, procmail ein eigener Prozess. Der Vorteil bei sieve soll sein, das es etwas moderner ist, mehr kann und im Vergleich weniger CPU-Last als procmail erzeugt, weil procmail eben einer weiterer, zusätzlicher und eigenständiger Job ist.... tja, das ist mir aber egal, wir haben ja keine 1000e Mails am Tag zu bewältigen.

Boar, ist das alles kompliziert.....

[scientific]

Ich lasse auch nix löschen. Nur markieren.
Und sieve sortiert ausschließlich. Jedes email, das in Dovecot ankommt, wird anhand der Filterregeln in bestimmte Unterordner des Imap-Kontos geschoben.

Es gibt für Thunderbird ein Sieve-Plugin, auch für Roundcube. Damit kann jeder User für sich seine Sieve-Regeln anpassen.
Durch die Serverseitige Filterung, sind die Mails auf jedem Client vorsortiert.

Die Kategorisierung als Spam durch Exims Bogofilter und spamassasin (erzeugt zusätzliche Header) kann dann der User nutzen, um mittels Sievefilter diese Mails in den Junkordner am Server schieben zu lassen, oder eben nicht.

Sieve hat auch eine Redirect-Funktion und kann Emails wieder beim Smtp-Server abkippen (so wie Thunderbird auch), um emails weiterzuleiten.

Vielleicht hast du auch wesentlich weniger Themengebiete als ich... Aber ich schätze die Sortierung durch Sieve sehr.

Jede Mailingliste hat einen eigenen Ordner bzw. Unterordner.
Z.b.die debianlisten.
Da gibts einen Ordner "debian.org"
Darin sind da dann unterordner für users-german, backports usw.
Ich seh auf einen Blick, auf welcher Liste was gekommen ist.
Mails vom Listmaster oder von z. B. Neuen Listen, die ich noch nicht sortieren lasse, kommen in den debian.org-Ordner.

[scientific]

Thunderbird sendet Emails an Port 25 oder 587. Dahinter lauscht exim. Beim Senden kommt Dovecot gar nicht ins Spiel.

Thunderbird -> exim -> smarthost

Fetchmail liefert auf Port 25 ab. Damit ebenfalls bei Exim.
Und Exim erkennt anhand des Empfängers, ob das Email lokal zugestellt werden muss oder bei einem Smarthost.

Fetchmail -> exim -> dovecot (mit oder ohne sieve)

Thunderbird hat als Imapkonto das bei Dovecot angelegt und sieht so die dort abgelegten Emails. Zum senden hab ich den lokalen exim als SMTP-Server eingestellt.
Ich kann in Thunderbird zu jeder Identität auch direkt den passenden Smarthost jedes ISP einstellen.
Aber das wollte ich nicht, da ich dann wieder die Passwörter ALLE in JEDEM Client zu JEDER Identität speichern und auch im Falle ändern muss. So muss ich das Passwort bei einer änderung nur an einer einzigen Stelle ändern. Die Clients bekommen genau ein Passwort für den Mailserver den sie als IMAP und SMTP-Server eingetragen haben. Egal ob Thunderbird, Evolution oder Android oder Roundcube.

Ich kann mit einem einzigen Passwort von allen Emailadressen meine Mails von jedem Client versenden.. Und das ist mir wichtig.

Ich hab jetzt übrigens eine ACL geschafft, die mir Emails mit nicht erlaubter Imap-User <-> Absenderadressen-Zuordnung die Annahme verweigert und Daemons dennoch Mails versenden können.

Lg scientific

[TomL]

Nur markieren.

Das hat sich bei mir seit Einsatz des Mailservers gravierend verändert.... ohne, dass ich mit Fakten konkret erklären kann, warum. Früher wurden allenfalls 10% der Mails automatisch als Spam markiert, heute werden fast alle Spams als Spam erkannt. Ich vermute, dass das mit meinem Procmail-Filter zusammenhängt, der mit sehr wenigen Regeln auskommt, die nur explizit namentlich an uns gerichtete Mails in unsere Postfächer weiterleiten. Das ist für mich bei rückwirkender Betrachtung der größtmögliche positive Effekt mit dem effektiv geringstmöglichen Aufwand. Daran will ich nix mehr ändern.

Und sieve sortiert ausschließlich. Jedes email, das in Dovecot ankommt, wird anhand der Filterregeln in bestimmte Unterordner des Imap-Kontos geschoben.

Ja, das ist anscheinend bei Procmail das gleiche... ich kann auch Mails nach vielen Kriterien erkennen und sie in beliebige Unterordner eines Imap-Kontos verschieben.

Die Kategorisierung als Spam durch Exims Bogofilter und spamassasin (erzeugt zusätzliche Header) kann dann der User nutzen, um mittels Sievefilter diese Mails in den Junkordner am Server schieben zu lassen, oder eben nicht.

Gut, dass Du darauf hinweist.... wenn dieses Tool den Header verändert, schließe ich das für mich aus.

Vielleicht hast du auch wesentlich weniger Themengebiete als ich... Aber ich schätze die Sortierung durch Sieve sehr.

Privat ist das ganz sicher so... nämlich so gut wie nix. Aber "dienstlich", "geschäftlich", "verwaltungstechnisch" ist das sehr viel. Allerdings wäre damit sowieso jeder Filter überfordert.

Jede Mailingliste hat einen eigenen Ordner bzw. Unterordner.

Ja, klar... wäre mit Procmail wohl auch kein Problem

Thunderbird sendet Emails an Port 25 oder 587. Dahinter lauscht exim. Beim Senden kommt Dovecot gar nicht ins Spiel.

Nee, das ist nicht ganz richtig.... zumindest fehlt da noch was. Schau mal auf meine obige Grafik. Der Sendevorgang beinhaltet bei mir auch das anschließende Speichern im Ordner "Sent". Wobei es richtig ist, für den reine Sendevorgang brauchts kein Dovecot.

Fetchmail liefert auf Port 25 ab. Damit ebenfalls bei Exim.
Und Exim erkennt anhand des Empfängers, ob das Email lokal zugestellt werden muss oder bei einem Smarthost.

Ich habe gestern noch lange recherchiert, ob ich vielleicht procmail ersetzen kann.... insofern, dass Getmail direkt an einen MDA in Dovecot sendet, meinetwegen auch über das vorhandene postfix. Für Dovecot gibts wohl ein Plugin "maildrop", aber ich finde irgendwie nix verständliches, wie ich da eine Verbindung herstellen kann. Procmail funktioniert bisher perfekt, aber der letzte Stand ist von 2001. Natürlich kann man jetzt sagen "das Programm ist einfach fertig und es gibt nix zu verbessern, solange sich das Mailing nicht grundsätzlich verändert".... und klar, es funktioniert ja auch wirklich perfekt.... *hmmm*... aber trotzdem. Könnte ich das auch mit Getmail <> Postfix <> Dovecot lösen, wüde ich auf procmail verzichten.

Ich kann in Thunderbird zu jeder Identität auch direkt den passenden Smarthost jedes ISP einstellen.

Ist doch bei mir nicht anders.

Ich kann mit einem einzigen Passwort von allen Emailadressen meine Mails von jedem Client versenden.

Ist bei mir auch nicht anders, da alle Dovecot-Konten eines Users auf unserem Server das gleiche Password haben. Außerdem muss das sowieso nicht eingegeben werden, TB merkt sich die ja. Bei mir sind die Möglichkeiten insofern exakt identisch, mit der Ausnahme, dass durch das ausgewählte Konto quasi die Absenderadresse per default die richtige ist. Wobei ich aber einfach eine andere wählen könnte. Aber der richtige Default-Absender war mir wichtig.

Ich hab jetzt übrigens eine ACL geschafft, die mir Emails mit nicht erlaubter Imap-User <-> Absenderadressen-Zuordnung die Annahme verweigert und Daemons dennoch Mails versenden können.

Hier widersprichst Du Dir aber selber.... "Thunderbird sendet Emails an Port 25 oder 587. Dahinter lauscht exim. Beim Senden kommt Dovecot gar nicht ins Spiel.".
Wenn Dovecot beim Senden gar nicht ins Spiel kommt, kann Exim den Absender auch nicht mit dem Imap-User abgleichen.... wie hast Du das realisiert? Bei mir hat nämlich Postfix auch nix mit dem Imap-User zu tun.... bzw. kennt den derzeit im Thunderbird angemeldeten Dovecot-Client gar nicht. Wie hast Du das umgesetzt?

[scientific]

Zum letzten Absatz:

Ich kann sowohl exim als auch dovecot so konfigurieren, dass er auf dem Mailserver vorhandene Unix-User oder sogenannte virtuelle User (aus einer Datenbank, aus einem Userdb-File...) heranzieht um die Authentifizierung sowohl als IMAP als auch als SMTP-AUTH-User zu vollziehen.

Damit kann ich für smtp und IMAP unterschiedliche User mit unterschiedlichen Passwörtern konfigurieren.


Ich hab das hier so gelöst, dass die Authentifizierung von exim einen Connector zur Dovecot-Authentifizierung verwendet. Die Authentifizierung erfolgt dann in der Tat über dovcot (auch in exim). Stimmt. Da hab ich mir widersprochen.
Aber ich kann auch in Exim eine eigene Userverwaltung zur SMTP-Authentifizierung machen. Dann bin ich beim Sendevorgang in der Tat vollkommen unabhängig von dovecot.

Bei "richtigen" Mailservern wird wohl auch eine Trennung auf eigene Maschinen erfolgen, wo exim und dovecot nicht mehr auf der selben Maschine laufen. Und die Userdatenbank kann mit ldap, mysql oder sonst irgendwie ebenfalls auf einem extra Rechner ausgelagert sein. Ist hier aber nicht der Fall.

Was mir zu procmail einfällt:
Ich habs mal gelesen, dass eine funktionierende procmail-Config quasi das "Meisterstück" der Linux-Administration darstellt... Es funktioniert prächtig, aber bis man es soweit hat, dass es funktioniert, ist es ein großer Aufwand... und ändern sollte man die Konfig dann auch nicht mehr... weil die Filter nicht "menschenlesbar" sind, obwohl in ASCII... so wie perl eben auch. Funktioniert super, nur Debuggen ist die Hölle.

Daher hab ich mich erst gar nicht mit procmail konfrontiert und gleich etwas anderes gesucht und bin da bei exim gelandet.

Die zusätzlichen Header fügt Bogofilter bzw. Spamassassin ein. Sonst ist ja eine Klassifizierung unnötig...
Exim kann man so konfigurieren, dass es Header einfügt oder nicht.
Auch ein Rewrite der Header macht exim, um die lokale Domain durch die fqdn zu ersetzen. Sonst würdest du ja emails von mir mit mit scientific@localhost als Absender bekommen...
lg scientific

[scientific]

Was die Spamerkennung anbelangt...

Die Filter von gmail und gmx sind wirklich gut. Ich lasse trotzdem alle durch, da immer wieder mal false positives dabei sind.
Die Filter der anderen Provider sind nicht ganz so gut.
Und die Spammer werden auch besser.

Daher hab ich für mich erkannt, dass eine zusätzliche selbstlernende Spamerkennung die beste Methode ist (bei mir. Spam ist ja durchaus individuell...)

Sollten False positives im Junkordner landen oder False negatives in der Inbox, kann ich diese mit einem einfachen Klick in Thunderbird umklassifizieren.
TB schiebt sie dann auch wieder in die Inbox bzw. Den Junkordner.

Einmal wöchentlich lasse ich dann den Bogofilter auf die Mails der letzten Woche los um Spam bzw. HAM zu lernen. Das macht ein cronjob für mich.
Meine Aufgabe ist lediglich die allenfalls notwendige Richtigstellung.

Lg scientific

[TomL]

Ich hab das hier so gelöst, dass die Authentifizierung von exim einen Connector zur Dovecot-Authentifizierung verwendet. Die Authentifizierung erfolgt dann in der Tat über dovcot (auch in exim).

Das macht absolut Sinn und würde ich auch sofort umsetzen. Danach werde ich mal suchen, ob das auch mit postfix möglich ist.

Aber ich kann auch in Exim eine eigene Userverwaltung zur SMTP-Authentifizierung machen. Dann bin ich beim Sendevorgang in der Tat vollkommen unabhängig von dovecot.

So ist es derzeit bei mir.... eben mit dem Resultat, dass ein Dovecot-User durchaus als Absender die Adresse eines anderen Dovecot-Users nutzen könnte. Der andere kriegt da nix von mit... es wird nur dessen Relay-SMTP genutzt, aber das bleibt unsichtbar.

Was mir zu procmail einfällt:
Ich habs mal gelesen, dass eine funktionierende procmail-Config quasi das "Meisterstück" der Linux-Administration darstellt... Es funktioniert prächtig, aber bis man es soweit hat, dass es funktioniert, ist es ein großer Aufwand... und ändern sollte man die Konfig dann auch nicht mehr... weil die Filter nicht "menschenlesbar" sind, obwohl in ASCII... so wie perl eben auch. Funktioniert super, nur Debuggen ist die Hölle.

Es hat einfach von Anfang an perfekt funktioniert. Mir ist die Syntax auch nicht sonderlich schwer gefallen. Hat man ein Beispiel am Laufen, kopiert man es einfach für die anderen Namen.

Daher hab ich mich erst gar nicht mit procmail konfrontiert und gleich etwas anderes gesucht und bin da bei exim gelandet.

Ich bin halt als erstes, nach meinem Fehlversuch mit exim, auf dieses Quartett (Dovecot, Postfix, Getmail, Procmail) gestoßen... und das war eben auch sofort erfolgreich. Nur passt das Ergebnis leider nicht 100% zu meinen Prämissen.

Meine Prämissen waren:

• Verfügbarkeit der lokalen (!) Maildaten an mehreren LAN-Clients. Thunderbird kann eben keine Profile sharen
• Geringstmöglicher Verwaltungsaufwand, der nicht den Aufwand an Thunderbird-Clients mit Direkt-ISP-Access übersteigen darf
• EMails müssen/sollen möglichst untouched beim Empfänger ankommen, exakt so, wie beim direkten ISP-Access durch Thunderbird
• EMails müssen vollzählig zugestellt werden, also keine Reject, Drop, Delete oder sonst was in dieser Art
• Die verwendete Software soll noch einer Wartung/Pflege unterliegen (wg. Bugfixes, Exploits, etc.)

Tja, und bis auf Procmail passt es ja anscheinend. Obwohl procmail vordergründig betrachtet tadellos seinen Job leistet, wabert mir immer der Gedanke an "seit 17 Jahren ungewartet" durch den Kopf rum. Ich werde nun auf meiner Testmaschine das alte Setup reanimieren und versuchen, procmail durch maildrop zu ersetzen.

Auch ein Rewrite der Header macht exim, um die lokale Domain durch die fqdn zu ersetzen. Sonst würdest du ja emails von mir mit mit scientific@localhost als Absender bekommen...

Das macht Postfix bei mir genauso.... das war kein Problem... nur halt für mich viel leichter nachvollziehbar .... wenn ich da an meine Probleme mit Exim zurückdenke.

[scientific]

Ich hab das hier so gelöst, dass die Authentifizierung von exim einen Connector zur Dovecot-Authentifizierung verwendet. Die Authentifizierung erfolgt dann in der Tat über dovcot (auch in exim).

Das macht absolut Sinn und würde ich auch sofort umsetzen. Danach werde ich mal suchen, ob das auch mit postfix möglich ist.

Aber ich kann auch in Exim eine eigene Userverwaltung zur SMTP-Authentifizierung machen. Dann bin ich beim Sendevorgang in der Tat vollkommen unabhängig von dovecot.

So ist es derzeit bei mir.... eben mit dem Resultat, dass ein Dovecot-User durchaus als Absender die Adresse eines anderen Dovecot-Users nutzen könnte. Der andere kriegt da nix von mit... es wird nur dessen Relay-SMTP genutzt, aber das bleibt unsichtbar.

Ich glaub, das hat mit dovecot relativ wenig zu tun. Das hängt nur mit den Prüfungen des SMTP-Servers zusammen.
Bei meinem SMTP-Server kann ich die User Authentifizieren lassen und habe dann einen authentifizierten Usernamen der zum Senden von Emails berechtigt ist. Ich kann aber auch unauthentifiziertes SMTP zulassen, dann kann jeder ein Email mit dem smtp-Protokol abliefern.

In Exim läuft das in zwei Stufen ab.

Erstens nimmt exim in einer SMTP-Sitzung ein Email entgegen und schmeißt es in eine Queue. Dies erfolgt mit dem Authentifizierten User und hier setzt die Prüfung an, ob der User auch das FROM: überhaupt verwenden darf.

Dann arbeitet exim in einem eigenen Prozess diese Queue regelmäßig ab und versendet als User Debian-exim an den Smarthost. Im Regelfall (und Debian-Standard) ein einziger Smarthost mit mehreren möglichen Usern mit Passwörtern. Hier agiert exim nicht als Server, sondern dem Smarthost gegenüber als SMTP-Client. So wie Thunderbird es auch täte. Login und anschließend ein Email abliefern. Oder auch ohne Login, wenn es gestattet ist.

Der User unter dem diese SMTP-Sitzung am Smarthost abgewickelt wird ist hier Debian-exim und kein authentifizierter Mail-User.

Das zu behirnen hab ich auch sehr lange gebraucht. Das ist mir erst gestern klar geworden Dann wusste ich auch, wo und warum ich meine ACL ansetzen muss.

Thunderbird liefert als User scientific authentifiziert bei exim ein Email ab. Dieses Email hat eine From-Adresse. In dieser SMTP-Sitzung muss exim prüfen, ob der User scientific diese From-Adresse überhaupt verwenden darf.
Wenn exim dann dieses angenommene Email beim Smarthost smtp.smarthost.example abliefert weiß er gar nicht mehr, von welchem authentifizierten User (unix-User oder viruteller USer aus einer DB, LDAP, Userdb-File) dieses Email abgeliefert wurde. Findet er zur Absenderadresse im From passende Credentials, so liefert er dieses Email beim Smarthost ab.

Wenn also keine Prüfung beim Einliefern in den SMTP-Server erfolgt, verschickt dieser in seiner Funktion als Client jedes Email, so er passende Credentials hat.

Was mir zu procmail einfällt:
Ich habs mal gelesen, dass eine funktionierende procmail-Config quasi das "Meisterstück" der Linux-Administration darstellt... Es funktioniert prächtig, aber bis man es soweit hat, dass es funktioniert, ist es ein großer Aufwand... und ändern sollte man die Konfig dann auch nicht mehr... weil die Filter nicht "menschenlesbar" sind, obwohl in ASCII... so wie perl eben auch. Funktioniert super, nur Debuggen ist die Hölle.

Es hat einfach von Anfang an perfekt funktioniert. Mir ist die Syntax auch nicht sonderlich schwer gefallen. Hat man ein Beispiel am Laufen, kopiert man es einfach für die anderen Namen.

Wie gesagt, ich hab mich aufgrund der Horrorgeschichten über Postfix und sendmail nie damit befasst.

Daher hab ich mich erst gar nicht mit procmail konfrontiert und gleich etwas anderes gesucht und bin da bei exim gelandet.

Ich bin halt als erstes, nach meinem Fehlversuch mit exim, auf dieses Quartett (Dovecot, Postfix, Getmail, Procmail) gestoßen... und das war eben auch sofort erfolgreich. Nur passt das Ergebnis leider nicht 100% zu meinen Prämissen.

Ich hab mir Getmail ein wenig angesehen. Getmail hat nämlich ggü. fetchmail einen entscheidenden Vorteil. Es kann per POP3 Emails vom Provider abholen und dort aber gespeichert lassen (das kann fetchmail auch. Option "keep".) Aber Getmail kann bereits abgerufene Emails nach einer eingestellten Zeit dann am Server löschen. Fetchmail kann das nicht.

Meine Prämissen waren:

• Verfügbarkeit der lokalen (!) Maildaten an mehreren LAN-Clients. Thunderbird kann eben keine Profile sharen

Dafür ist IMAP da.

[*]Geringstmöglicher Verwaltungsaufwand, der nicht den Aufwand an Thunderbird-Clients mit Direkt-ISP-Access übersteigen darf

Wie schon geschrieben... meine Lösung erfordert genau einmal die Eingabe eines Passwortes für IMAP und für SMTP. Punkt. EINMAL und nicht für jede Adresse extra.

[*]EMails müssen/sollen möglichst untouched beim Empfänger ankommen, exakt so, wie beim direkten ISP-Access durch Thunderbird

Header aufgrund einer Spamprüfung einzufügen ist ein normaler Vorgang... Das verändert zwar die Header... das passiert aber sowieso, da auch Header durch die Zustellung usw. hinzugefügt werden. Dazu sind Header ja da. Da kann man dann den Weg des Emails gut nachvollziehen.

[*]EMails müssen vollzählig zugestellt werden, also keine Reject, Drop, Delete oder sonst was in dieser Art

Das konfiguriert sich jeder User mit Sieve selbst. Ich stelle ALLE EMails zu.

[*]Die verwendete Software soll noch einer Wartung/Pflege unterliegen (wg. Bugfixes, Exploits, etc.)[/list]

Dovecot, exim4 und fetchmail sind gewartet und gepflegt.

Tja, und bis auf Procmail passt es ja anscheinend. Obwohl procmail vordergründig betrachtet tadellos seinen Job leistet, wabert mir immer der Gedanke an "seit 17 Jahren ungewartet" durch den Kopf rum. Ich werde nun auf meiner Testmaschine das alte Setup reanimieren und versuchen, procmail durch maildrop zu ersetzen.

Auch ein Rewrite der Header macht exim, um die lokale Domain durch die fqdn zu ersetzen. Sonst würdest du ja emails von mir mit mit scientific@localhost als Absender bekommen...

Das macht Postfix bei mir genauso.... das war kein Problem... nur halt für mich viel leichter nachvollziehbar .... wenn ich da an meine Probleme mit Exim zurückdenke.

Also ein dpkg-reconfigure exim4-conf gibt mir die Frage, ob der lokale Mailname mit einer anderen Domain ersetzt werden soll oder nicht. Wählt man das aus und setzt den Namen der anderen Domain passiert das von ganz alleine.

lg scientific

[TomL]

Wie gesagt, ich hab mich aufgrund der Horrorgeschichten über Postfix und sendmail nie damit befasst.

Was für Horrorgeschichten...?.... ich habe darüber nix gelesen. Exim war nur zu kompliziert für mich, Sendmail kenne ich nicht und Postfix ist doch gerade auf hohe Sicherheit getrimmt und leichtere Bedienbarkeit.

https://hoststud.com/resources/comparis ... dmail.158/
Aber das ist wohl wie mit dem Geschmack.... man kann nicht drüber streiten....

Erstens nimmt exim in einer SMTP-Sitzung ein Email entgegen und schmeißt es in eine Queue. Dies erfolgt mit dem Authentifizierten User und hier setzt die Prüfung an, ob der User auch das FROM: überhaupt verwenden darf.

Das ist bei mir genauso... und dennoch gibts da eine Klanke, wo ich Dich so verstanden habe, dass Du das gelöst hast, was bei mir aber anscheinend nicht zu lösen ist.

Stell Dir mal folgendes (Horror-)Szenario vor.... dir 5 Simpsons ziehen bei Dir ein... so rein theoretisch.... also Homer, Marge, Bart, Lisa und Maggie. Alle haben bei Dir auf dem Server ein Dovecot-Postfach und eine Exim-Berechtigung. Alle 5 sitzen gleichzeitig -jeder am eigenen- Laptop, alle haben Thunderbird geöffnet und senden eine Mail, die via Exim rausgeht und im 'eigenen' Dovecot-Sent-Ordner gespeichert wird. Alles läuft fehlerfrei ab, weil alle dazu berechtigt sind. Nur Bart ist ein Drecksack, er trägt über "Benutzerdefinierter Absender" Homer als Absender ein, sendet die Mail an Homer's Chef und beschimpft ihn aufs übelste.

Bei Exim kommen also gültige (!) 5 Mails an, von 5 berechtigten (!) Usern, aber nur mit 4 Absendern, die auch alle gültig sind..Nur 4, weil ja zwei Mails (vermeintlich) von Homer kommen, wobei in Wahrheit aber eine von Bart ist. Wie überträgst von Thunderbird oder Dovecot die Info an Exim, dass es der User Bart war, der diese Mailgesendet hat und mit Homer eine Absender-Adresse verwendet hat, die er gar nicht verwenden darf und Exim stellt genau das fest. Die Krux ist, die Personen sind ja alle berechtigt, die Absender sind gültig, alles passt... hier liegt nur der Missbrauch einer nicht-eigenen Absenderadresse vor. Und wenn die Mails bei Exim ankommen, sind ja gleichzeitig alle 5 User in Dovecot angemeldet. Woher weiss Exim, welcher der 5 User welche Mail gesendet hat, denn bezogen auf diese eine Mail gibt das "Sender"-Feld im Header diese Info nicht her.

BTW, ich habe jetzt meinen Testrechner auf maildrop umgestellt. Das funktioniert tatsächlich genauso gut wie procmail. Der Unterschied ist, maildrop ist tatsächlich aktuell, im Vergleich zur letzten 17 Jahre alten procmail-Version. Und es gibt sogar ne neue Version von 2017. Also das lebt wirklich noch. Aber es ist wirklich signifikant größer auf der Platte, als Procmail....*hmmm*....

[scientific]

Exim startet für jeden authentifizierten User einen eigenen Prozess bzw. eine eigene SMTP-Session auf.
Innerhalb dieser Session (als 5. Für jedes Mitglied der Familie je eine) gibt es die Variable $authenticated_id, auf die kann ich prüfen lassen.
In einer Liste mit Credentials zu den Absenderadressen (smtp-server, loginzsername, passwort) hab ich ein zusätzliches Feld mit den dovecot-usern. Wenn $authenticated_id in diesem Feld vorkommt, nimmt Exim das Mail an. Kommts nicht vor, lehnt exim das Mail sofort ab.
Thunderbird spuckt diese Fehlermeldung auch aus.
Damit ist der von dir beschriebene Missbrauch nicht mehr Möglich.
Exim loggt übrigens sowieso den user der das Email gesendet hat mit der Absenderadresse. Barth wäre also schnell der Täterschaft überführt.

Ich lasse exim auch nach journald loggen... Damit kann Barthauch ggfs. auch nicht das Log verändern...

Meine ACL ist aber noch nicht 100%ig. Daemons können zwar senden, aber mailx auch... Ich muss das noch weiterentwickeln.
Aber prinzipiell klappt es genau wie es sein soll.

Exim ist zwar ein Monster, das wirklich intensiver Einarbeitung bedarf. Es ist aber ein 100%-Ersatz für sendmail und echt flexibel in der Konfiguration.

Das Problem einer solchen Flexibilität ist wie überall... Wenn viele Wege nach Rom führen, muss man sich für einen entscheiden. Nur welchen?

Lg scientific

[TomL]

Exim startet für jeden authentifizierten User einen eigenen Prozess bzw. eine eigene SMTP-Session auf.
Innerhalb dieser Session (als 5. Für jedes Mitglied der Familie je eine) gibt es die Variable $authenticated_id, auf die kann ich prüfen lassen.

Ich glaube, wir reden aneinander vorbei. Der am Client-PC angemeldete Linux-User oder Windows-User ist nicht gleichzeitig der am Server (eine andere Maschine) angemeldete Linux-User. Wenn ich mich z.B. auf dem Android anmelde, gibts auch keinen Linux-User. Auf dem Server läuft der MTA-D (exim/postfix) unter root, gestartet von systemd. Auf dem Server kann also gar keine auf den Client-Linux-User bezogene Session geöffnet werden, der entfernte Dovecot-User muss als Linux-User ja noch nicht mal auf dem Linux-Server eingerichtet sein. Wie wird also serverseitig durch Exim die $authenticated_id ermittelt, wenn auf Port 25 von einer anderen Maschine die zu sendende Mail von User Bart reinkommt, der als Absender unerlaubt Homer eingetragen hat? Und wie wird festgestellt, dass das unerlaubt ist, wenn Homer und Bart beide grundsätzlich berechtigt sind?

[scientific]

Exim startet für jeden authentifizierten User einen eigenen Prozess bzw. eine eigene SMTP-Session auf.
Innerhalb dieser Session (als 5. Für jedes Mitglied der Familie je eine) gibt es die Variable $authenticated_id, auf die kann ich prüfen lassen.

Ich glaube, wir reden aneinander vorbei. Der am Client-PC angemeldete Linux-User oder Windows-User ist nicht gleichzeitig der am Server (eine andere Maschine) angemeldete Linux-User. Wenn ich mich z.B. auf dem Android anmelde, gibts auch keinen Linux-User. Auf dem Server läuft der MTA-D (exim/postfix) unter root, gestartet von systemd. Auf dem Server kann also gar keine auf den Client-Linux-User bezogene Session geöffnet werden, der entfernte Dovecot-User muss als Linux-User ja noch nicht mal auf dem Linux-Server eingerichtet sein. Wie wird also serverseitig durch Exim die $authenticated_id ermittelt, wenn auf Port 25 von einer anderen Maschine die zu sendende Mail von User Bart reinkommt, der als Absender unerlaubt Homer eingetragen hat? Und wie wird festgestellt, dass das unerlaubt ist, wenn Homer und Bart beide grundsätzlich berechtigt sind?

Ich glaub in der Tat, dass wir schon länger aneinander vorbeireden..

Die ganze Mailgeschichte kommt ja meines Wissens aus der Unix-Welt. Und das war von Anfang an ein Multiuser-Betriebssystem, wo jeder User an der Maschine einen eigenen Account hatte und sich einloggen musste.

Die Maildir-Konfiguration von dovecot (ich glaub bei cyrus ist es nicht anders) geht auch von einem Maildir im Home des Users aus. Und hier spreche ich von einem User auf der Maschine auf dem der IMAP-Server läuft, nicht von irgendwelchen Clients auf denen Thunderbird, Android oder Windows in Betrieb ist.

Also in der Grundkonfiguration braucht jeder User, der auf dem IMAP-Server ein Postfach hat, einen UNIX-User-Account. Und mit diesem Account ein eigenen HOME, in welches ein Maildir mit den Emails kommt. dieses Maildir kann ganz normale Unix-Filesystem-Unterverzeichnisse haben, die dann auch im IMAP-Client als Unterordner zur INBOX angezeigt werden.

Jetzt kommen wir zum spannenden Teil für dich. IMAP-Server (dovecot) haben auch die Möglichkeit, eigene Datenbanken zu führen, wo virtuelle Useraccounts verwaltet werden. Daher ist in einigen Anleitungen zu Dovecot auch der User "vmail" und mit "mail" oder "dovecot" angeführt. "vmail" bedeutet "Virtuelles Mail". Also ein IMAP-Account ohne UNiX-Useraccount.

Da Mailhoster mit 1000en Kunden und Mailboxen aber nicht 1000e Unix-User auf ihren Maschinen einrichten nutzen diese die Möglichkeit der virtuellen USer. Diese lassen sich einfach mit LDAP, MYSQL oder bei kleinen Mengen auch über einfache Textfiles mit bestimmter Struktur verwalten. Zudem bieten virtuelle User eine Sicherheitsstufe mehr. Denn wenn bei normalen Unix-Usern IMAP-Credentials habe kann ich mich eventuell sogar direkt an der Maschine mit ssh einloggen und dort allerlei Schabernack treiben... Was mir als Mailhoster aber gar nicht recht wäre.

Nun zum Ablauf...

Das SMTP-Protokoll sah ursprünglich keinerlei Authentifizierung vor. POP und IMAP sehr wohl Denn es sollte jeder User nur seine eigenen Emails sehen, aber nicht jene von anderen USern. Und da mit den POP oder IMAP-Credentials auch ein Login an der Maschine auf der Shell möglich war (mutt, mail, und andere commandline-Tools für Mails setzen ja einen Login auf der Shell auf der MAschine voraus) nutzen diese Protokolle auch gleich diese Unix-User für die Authentifikation.

Abliefern von Emails war in der Anfangszeit ja kein großes Problem, da Spam unbekannt war und MIssbrauch ebenfalls.

Das SMTP-Protokoll wurde aber doch recht bald zur Verbreitung von Müll missbraucht, daher ließ man sich z.B. POP vor SMTP einfallen. Der SMTP-Server nahm von einer IP-Adresse nur dann ein Mail entgegen, wenn diese IP-Adresse zuvor eine erfolgreiche POP-Anmeldung erledigt hatte. Man ließ den Client also am POP-Port authentifizieren und der SMTP erfuhr davon und gestattete ein Abliefern der Email.

Das ist aber umständlich und nicht gründlich und sicher genug.

Daher wurde SMTP-Auth erfunden - also das Protokoll erweitert.

Damit eine SMTP-Sitzung (in der auch mehrere Emails abgeliefert werden können) erfolgreich aufgebaut werden kann, muss sich ein User Authentifizieren. Also einloggen. Dazu benötigt er Usernamen und Passwort. Dies kann der UNIX-Username des Accounts am Mailserver sein, oder ein Username der nur in einer Datenbank oder einem einfachen Textfile gespeichert ist.
Der SMTP-Server prüft ob das Passwort das der Client schickt (nachdem es der USer eingegeben hat oder der Keyring bereitgestellt hat) mit jenem in der Datenbank übereinstimmt und setzt die SMTP-Sitzung fort. Dann werden die Emails gesendet und die Sitzung beendet.

In Thunderbird merkst du das daran, dass du dem SMTP-Server-Zugang als Authentifizierungsmethode Plain oder Login mit Username und Passwort angeben musst. Wenn du keine Authentifizierungsmethode wählst, spricht Thunderbird mit dem SMTP-Server einfaches SMTP, kein SMTP-AUTH!!!

Der Username und das Passwort, das in Thunderbird beim SMTP-Server hinterlegt ist, hat mit dem User der auf der Maschine auf der Thunderbird läuft nichts zu tun. Es kann ja auch Windows oder Android sein... Aber bei allen gibst du Username und Passwort an. Eben jenen eines Accounts auf dem Mailserver!

exim setzt dann die Variable $authenticated_id auf genau jenen USernamen, den du bei den Authentifikations-Credentials in Thunderbird angibst. Und gegen genau diese ID lasse ich meine ACL prüfen.

Wenn das Email von localhost (also von einem Daemon) kommt, dann ist $authentificated_id der USername unter dem der Daemon läuft. Das kann root sein, oder Debian-exim oder _apt oder minidlna... je nachdem unter welchem User eben der Prozess läuft, der das email versendet. Von localhost ist auch in der Regel die Authentifikation abgedreht, sonst könnten nämlich die Daemons keine Emails senden.
Das war/ist ein Problem mit meiner ACL, dass Daemons mit der ACL ebenfalls eine Authentifizierung machen müssten - was diese aber nicht können.

TLS oder STARTTLS hat hingegen nichts mit der Authentifizierung zu tun. Aber eine PLAIN oder LOGIN-Authentifizierung übertragen USername und Passwort im Klartext. Daher setzen diese Authentifikationsmethoden eine TLS-gesicherte Verbindung voraus. (Muss in exim konfiguriert werden)

Wenn du aber kein SMTP-AUTH konfiguriert hast, dann kannst du auch nicht gegen eine authentifizierte ID prüfen und damit kann jeder der eine andere Absenderadresse kennt, diese bei seinen Emails einsetzen und so Missbrauch veranstalten und Emails im Namen anderer versenden. Um das zu verhindern, musst du zwingend SMTP-AUTH aktivieren und zwingend aktivieren. Zumindest für nach außen offene Ports.

Wenn man es streng nimmt, kann der IMAP-Server, der SMTP-Server und der Datenspeicher auf dem die Emails dann physisch abgelegt werden und auch eine Datenbank mit den Userinformationen für die virtuellen User auf völlig getrennten Computern in verschiedenen Rechenzentren installiert sein, und es würde immer noch funktionieren. Der Client authentfiziert sich immer nur am IMAP- und bestenfalls auch am SMTP-Server. Und der IMAP und der SMTP-Server müssen nicht einmal miteinander kommunizieren. Für den Admin ist es einfacher, wenn die Credentials von einem Datenspeicher für beide Server kommen. Muss aber nicht sein. Beide Server (exim und dovecot) haben die Möglichkeit gegen pam zu authentifizieren, gegen /etc/passwd und /etc/shadow, gegen eigene Passwort-fIles, gegen einen mysql-server oder gegen ldap. Exim kann die Authentifikation aber auch an cyrus oder dovecot abtreten und nimmt nur ein ok und $authenticated_id entgegen.

Ich hoffe, jetzt ist es ein wenig klarer geworden mit dem UNIX-User und dem Konto unter dem Thunderbird gestartet wurde...

lg scientific

[TomL]

Alles., was Du mir erklärt hast, war mir soweit technisch bekannt. Der Grund für das Missverständnis ist mir jetzt aber klar...

Die Maildir-Konfiguration von dovecot (ich glaub bei cyrus ist es nicht anders) geht auch von einem Maildir im Home des Users aus. Und hier spreche ich von einem User auf der Maschine auf dem der IMAP-Server läuft, nicht von irgendwelchen Clients auf denen Thunderbird, Android oder Windows in Betrieb ist.

... denn wir hatten die ganze Zeit einen anderen Fokus, eine andere Perspektive auf das Auth-Verfahren gehabt. Du nutzt anscheinend die lokale Anmeldung am Linux-Server, mit dem dortigen Homedir und kennst deshalb den angemeldeten User. Und genau den kenne ich nicht. Für mich war die ganze Zeit über klar, dass meine User das nämlich so nicht nutzen können.

Die Mailordner liegen auch nicht in den Homedirs, sondern zentral auf einer externen Platte, dort aber in userbezogenen Verzeichnissen - auf die der User, wenn er sich lokal am Server anmelden könnte, noch nicht mal Rechte hat. Mein PI hat nämlich keine interne Platte mit installiertem Linux und lokalen Homedirs, sondern nur die 16GB-SD-Card für das Linux, die aber fast komplett von allen Schreibvorgängen ausgenommen ist - das heisst, ausser beim Upgrade wird die nicht beschrieben. Deshalb findet bei mir die Anmeldung immer über virtuelle User statt, genau so wie bei den Internet-Mail-ISP, von beliebigen Clients, von beliebigen OS, übers Internet getunnelt, direkt im LAN, aber immer ohne sich auf dem Server Linux-seitig anmelden zu müssen. Und natürlich gibts ein komplettes Dovecat-Auth, ein ordentliches POP3-Auth, und selbstverständlich ein explizites SMTP-Auth, so das keine "wilden" User senden können.

Aber es gibt eben keine Plausiprüfung, ob der User bei der "benutzerdefinierten Verwendung" einer Absender-Adresse (aus dem Pool aller in Postfix definierten) überhaupt für diese Adresse berechtigt ist. Der User ist gültig und hat sich ordentlich angemeldet, die Absender-Adresse ist gemäß Auth verifiziert und ebenfalls gültig und somit berechtigt, der Relayhost ist gemäß Auth-Tabelle korrekt gesetzt und hat passende Anmeldedaten.... also kann "Bart" einfach als Absender "Homer" eintragen. Die Voraussetzung ist anscheinend, man muss gültige Anmeldedaten haben und eine gültige Absenderadresse kennen, die nicht mir gehört, aber beim gleichen Relayhost bekannt ist.

Ich will morgen mal probieren, ob das nicht sogar auch bei GMX oder Strato möglich ist... in dem ich die GMX-Adresse meines Sohnes als Absender eintrage, aber meine Anmeldedaten für den SMTP verwende.... ich bin mal gespannt, ob das durchgeht.

[scientific]

Alles., was Du mir erklärt hast, war mir soweit technisch bekannt. Der Grund für das Missverständnis ist mir jetzt aber klar...

Die Maildir-Konfiguration von dovecot (ich glaub bei cyrus ist es nicht anders) geht auch von einem Maildir im Home des Users aus. Und hier spreche ich von einem User auf der Maschine auf dem der IMAP-Server läuft, nicht von irgendwelchen Clients auf denen Thunderbird, Android oder Windows in Betrieb ist.

... denn wir hatten die ganze Zeit einen anderen Fokus, eine andere Perspektive auf das Auth-Verfahren gehabt. Du nutzt anscheinend die lokale Anmeldung am Linux-Server, mit dem dortigen Homedir und kennst deshalb den angemeldeten User. Und genau den kenne ich nicht. Für mich war die ganze Zeit über klar, dass meine User das nämlich so nicht nutzen können.

Die Mailordner liegen auch nicht in den Homedirs, sondern zentral auf einer externen Platte, dort aber in userbezogenen Verzeichnissen - auf die der User, wenn er sich lokal am Server anmelden könnte, noch nicht mal Rechte hat. Mein PI hat nämlich keine interne Platte mit installiertem Linux und lokalen Homedirs, sondern nur die 16GB-SD-Card für das Linux, die aber fast komplett von allen Schreibvorgängen ausgenommen ist - das heisst, ausser beim Upgrade wird die nicht beschrieben. Deshalb findet bei mir die Anmeldung immer über virtuelle User statt, genau so wie bei den Internet-Mail-ISP, von beliebigen Clients, von beliebigen OS, übers Internet getunnelt, direkt im LAN, aber immer ohne sich auf dem Server Linux-seitig anmelden zu müssen. Und natürlich gibts ein komplettes Dovecat-Auth, ein ordentliches POP3-Auth, und selbstverständlich ein explizites SMTP-Auth, so das keine "wilden" User senden können.

Wie geschrieben, in der Grundkonfiguration sind die Maildirs im Home des Users.
Ich habe dovecot anders konfiguriert, sodass die Verzeichnisse für die User in /var/mail/$USER liegen. Und /var/mail könnte natürlich ein Mountpunkt für eine externe Platte sein.

Wenn du ein explizites SMTP-AUTH verwendest, hättest du in exim auch die Variable $authenticated_id gesetzt und könntest danach abfragen. Ich gehe davon aus, dass auch postfix eine solche Variable setzt, wenn ein User authentifiziert ist.

Und ich hab das Gefühl, dir fehlt noch ein Stück. exim ist es ziemlich egal, ob das ein tatsächlicher Unix-User des Mailservers ist, oder ein virtueller User aus einer Datenbank. Wenn sich ein Client authentifiziert, dann als einer dieser User.

Aber es gibt eben keine Plausiprüfung, ob der User bei der "benutzerdefinierten Verwendung" einer Absender-Adresse (aus dem Pool aller in Postfix definierten) überhaupt für diese Adresse berechtigt ist. Der User ist gültig und hat sich ordentlich angemeldet, die Absender-Adresse ist gemäß Auth verifiziert und ebenfalls gültig und somit berechtigt, der Relayhost ist gemäß Auth-Tabelle korrekt gesetzt und hat passende Anmeldedaten.... also kann "Bart" einfach als Absender "Homer" eintragen. Die Voraussetzung ist anscheinend, man muss gültige Anmeldedaten haben und eine gültige Absenderadresse kennen, die nicht mir gehört, aber beim gleichen Relayhost bekannt ist.

Ich will morgen mal probieren, ob das nicht sogar auch bei GMX oder Strato möglich ist... in dem ich die GMX-Adresse meines Sohnes als Absender eintrage, aber meine Anmeldedaten für den SMTP verwende.... ich bin mal gespannt, ob das durchgeht.

Und noch was... es authentifiziert sich nicht eine Absenderadresse, sonder ein User. Das ist ein gravierender Unterschied.
Ich weiß, dass bei gmail der Username zum Authentifizieren die Email-Adresse ist. Bei gmx ebenso. Aber die email-Adresse ist in diesen Fällen ident mit dem Authentifizierungsnamen. Aber das muss nicht so sein.

Das bedeutet, du gibst dem Client (Thunderbird) einen Usernamen und nicht eine Emailadresse zum Authentifizieren beim SMTP-Server.

Und deinem SMTP-Server musst du beibringen, dass er zu diesen Usernamen nur bestimmte Absenderadressen zulässt. Das aber nur bei authentifizierten SMTP-Sitzungen. Nichtauthentifizierte Sitzungen dürfen aber nur mehr auf localhost möglich sein. Das zu lösen ist wohl auf einem expliziten Mailserver einfacher, als auf meiner Lösung, wo der Mailserver gleichzeitig auch mein Arbeitsrechner ist...

lg scientific

[TomL]

Moin scientific

Wenn du ein explizites SMTP-AUTH verwendest, hättest du in exim auch die Variable $authenticated_id gesetzt und könntest danach abfragen. Ich gehe davon aus, dass auch postfix eine solche Variable setzt, wenn ein User authentifiziert ist.

Du hörst nicht zu, ich habe das bereits mehrfach gesagt: Postfix macht SMTP-Auth über einen SASL-Password-Check. Das entspricht anscheinend dieser authenticated_id. Das lief bereits schon vom ersten Tag an auf meiner Test-Maschine. "Wilde" (also unberechtigte) Sender von Emails sind gar nicht möglich. Und ich kenne auch den Unterschied zwischen Account-Anmelde-Daten und einer Email-Adresse. Nur orientiere ich mich dabei am etablierten Verfahren der Mail-ISP und verwende deshalb auch die lokale Email-Adresse als Anmelde-Name.

Und ich hab das Gefühl, dir fehlt noch ein Stück. exim ist es ziemlich egal, ob das ein tatsächlicher Unix-User des Mailservers ist, oder ein virtueller User aus einer Datenbank. Wenn sich ein Client authentifiziert, dann als einer dieser User.

Nein, mir fehlt nichts. Du wirst aber feststellen, was Dir noch fehlt, wenn Du Dein Modell auf ein tatsächlich serverbasiertes Konzept ohne synchrone Linux-User-Accounts transportieren willst, wenn es also keine lokale Linux-Benutzererkennung gibt und der Traffic rein via TCP/IP und Ports abläuft, wo Du am Server weder den Linux-User kennst, noch die Art des Clients und der verwendeten Software. Das kann ein Android mit K9-Mail sein, oder ein Windows-PC, oder Linux, ein Thunderbird via Tethering, oder direkt im LAN, oder getunnelt durchs VPN, ein auf dem Linux-Server bekannter User, oder ein unbekannter ganz ohne Server-Zugriff. Das waren nämlich genau die Hürden, wegen derer ich mit exim gescheitert bin. Es war mir deutlich zu kompliziert, das nach meinen Anforderungen einzustellen.

Das bedeutet, du gibst dem Client (Thunderbird) einen Usernamen und nicht eine Emailadresse zum Authentifizieren beim SMTP-Server.

Nein, geb ich nicht - meine Thunderbirds kennen den ISP-SMTP gar nicht, sondern nur ihre Anmeldung an Dovecot/Postfix im LAN. Und beim Senden einer Mail wird über den Relay-SMTP-SASL-Check festgestellt, ob der lokale User überhaupt berechtigt ist, das zu tun. Wie ich sagte, "wilde" Sender sind gesperrt. Da ist eindeutig festgelegt, welche User das dürfen. Aber ganz nebenbei bemerkt, das, was bei mir möglich ist, nämlich dass "Bart" in seiner Mail den benutzerdefinierten Absender "Homer" eintragen kann, geht auch bei GMX und WEB.de. Ich habs gerade getestet. Die Mail kommt mit einem Fake-Absender einwandfrei bei mir an. Es sind die gleichen Rahmenbedingungen.... ich bin als GMX-Kunde mit gültigem Usernamen und Password berechtigt, deren SMTP zu nutzen.... und es wird seitens ISP nicht verhindert, dass ich einen Fake-Absender eintrage. Tja...

Und deinem SMTP-Server musst du beibringen, dass er zu diesen Usernamen nur bestimmte Absenderadressen zulässt.

Dann sag mir mal wie.... wenn anscheinend nicht mal GMX und WEB das machen. Ich kann dem "Usernamen" via SASL-Auth-Check nur erlauben den SMTP-Server zu benutzen und alle anderen sind verboten... aber ich kann ihm keine Vorschriften machen, was seine Mail enthält....und dazu gehört eben auch der Absendername. Solange er als User grundsätzlich berechtigt ist, sich anzumelden und den SMTP zu verwenden, kann er in dieses Feld eintragen, was er will, die Mail geht trotzdem raus. Vesuchs einfach selber, was passiert, wenn Du das OHNE lokale Anmeldung auf der Maschine tust, wo exim und dovecot laufen, sondern mit einem MAIL-ISP-analogen Anmeldeverfahren, und zwar nur über Ports und eine reine TCP/IP-Verbindung.

Nachtrag:
Bei Strato kann ich als Absender auch eintragen, was ich will... sogar 12345@x.de.... genau mit diesem Absender kommt die Mail bei mir an. Also mach ich mir jetzt auch keinen weiteren Kopp darüber. Es kommt nur darauf an, dass ich mit gültigen Anmeldedaten grundsätzlich berechtigt bin, die Services IMAP/POP3/SMPT zu nutzen. Und mal ganz ehrlich... ich habe jetzt echte Zweilfel daran, dass Exim das lösen können soll.

[scientific]

Nun...

$authenticated_id ist eine Servervariable, die exim4 setzt, sobald eine SMTPauthentifizierung erfolgreich gemacht wurde.
Diese Variable steht für diese SMTP-Sitzung dauerhaft zur Verfügung. In Exim!

Ob in dieser Variable der Username aus der Unix-Userdb oder aus einem password-file oder sonstwoher kommt, ist egal.
Du gibst in Thunderbird für den SMTP-Server einen Usernamen an. DAS wird in dieser Variable gespeichert. IN EXIM.

Und da ich meinen Exim voll unter meiner Kontrolle habe, kann ich auch steuern, dass für diesen User, der sich am SMTP-server authentifiziert nur bestimmer Absender im Header zugelassen sind. Anderenfalls wird das Email schon bei der Einlieferung zurückgewiesen.

Was gmx macht, und dass die dort so eine Missbrauchslücke offen haben, ist mir ziemlich powidl. Ein Mailserver unter meiner Kontrolle soll diese Lücke nicht haben...

Lg scientific

[TomL]

Was gmx macht, und dass die dort so eine Missbrauchslücke offen haben, ist mir ziemlich powidl. Ein Mailserver unter meiner Kontrolle soll diese Lücke nicht haben...

Naja, so groß ist die Lücke also nicht. Ich habe das weiterhin noch mit Web und Strato verifiziert, dort ist es dasselbe. Und ich bin zu dem Schluß gekommen, dass das völlig in Ordnung ist und das die From-Adresse im Header als Security-Feature völlig belanglos ist. Ich habe diese Prüfung bei mir also schleunigst entfernt.

Meines Erachtens gibts nur einen Weg, das System zu härten... und zwar, in dem man es selber mit Telnet und OpenSSL testet. Ich habe mich mit reinen Terminalcommands via OpenSSL bei GMX angemeldet und mehrere Mails gesendet, das gleiche bei Strato, also nur mit CLI-Commands... um die Abläufe und Zusammenhänge sowie die Reaktionen des Servers besser zu verstehen. Ich habe mit From's, mit Usernamen und Veränderungen daran experimentiert, mit Passwörtern, die jeweils beide vor dem Senden mit "base64" geschlüsselt werden müssen. Das A und O sind ohne jeden Zweifel der korrekte Username und das dazugehörige korrekte Passwort, um sich via CLI anzumelden und erfolgreich eine Mail zu senden. Was die Mail beinhaltet, eben auch die From-Adresse, ist völlig irrelevant für die Sicherheit. Ich hab das gleiche natürlich auch mit Telnet versucht. Telnet war natürlich nicht erfolgreich.

Die gleiche Test-Prozedur mit OpenSSL und Telnet habe ich dann auf Postfix "losgelassen". Telnet ging erwartungsgemäß natürlich nicht, weil ich zwingend SSL verlange ... aber ...oh Bullshit... ich konnte mich im Terminal und im eigenen LAN direkt auf dem Port 25 via OpenSSL anmelden und ohne Username und Passwd eine Mail senden. Da habe ich erst mal dumm geguckt, weil nämlich damit offenkundig wurde, dass das in Thunderbird eingetragene SMTPD-SASL-Password gar nicht abgefragt wird. Lediglich mein Sender-Filter (also der Envelope-From) wurde geprüft... und war der From gültig, konnte ich via OpenSSL senden.
Daraufhin habe ich natürlich den Sender-Filter schnell wieder entfernt, weil das ja tatsächlich die schwächste Prüfung überhaupt ist und stattdessen einen echten SASL-Auth implementiert. Damit interessiert mich eine auf dem Server lokale Postfix-Berechtigungsverwaltung überhaupt nicht mehr. Der SMTPD-SASL-Auth ist über einen lokalen Socket zur Dovecot-DB umgesetzt. Wer kein Dovecot-Konto hat, hat damit auch keine SMTPD-Berechtigung. Und jetzt ist es auch nicht mehr via CLI und OpenSSL möglich, eine Mail ohne Anmeldung zu senden. Und das wichtigste... erst jetzt hat das Thunderbird-SMTPD-PWD endlich eine Bedeutung. Es sind jetzt also -so, wie es beim Senden sein muss- zwei Authentifizierungsebenen vorhanden, wobei der Client nur eine bedient, und zwar die über den Thunderbird-Client... zum Relay-SMTP regelt das ja Postfix:

Code: Alles auswählen

+-------+    +----------+    +-------+    +---------+    +--------+  
|Client |--->|SMTPD-SASL|--->|Postfix|--->|SMTP-SASL|--->|Mail-ISP|  
+-------+    |Auth.     |    +-------+    |Auth.    |    +--------+  
             +----------+                 +---------+               

Also... eines muss ich ja nach unseren zweimaligen Gedankenaustausch ganz klar feststellen... auch wenn das manchmal wegen unterschiedlichem Fokus und Perspektiven schwierig war.... ohne diesen Austausch wäre mir das alles nicht gelungen, weil ich als Laie niemals von alleine auf die wichtigen Fragen gekommen wäre und dann vermutlich nie die richigen Anworten gefunden hätte. Für mich war das also sehr erfolgreich.

[scientific]

Nun... eine Sicherheitslücke ist es nicht wirklich, da die Integrität des Mailservers damit nicht zerstört werden kann.
Aber ich finde es SEHR bedenklich, wenn andere meine Adresse als Absender im Email verwenden können... Dein Beispiel mit den Simpsons ist das sehr gut gewählt.

Stell dir einmal vor, du bist in der Arbeit in einer unguten Konkurrenzsituation. Es geht um einen Job oder einen großen Auftrag. Und dein Konkurrent schreibt ein kompromittierendes Email an deinen Arbeit- oder Auftraggeber und verwendet deine private gmx-Adresse als Absender... Weil dein Konkurrent ist technisch zumindest auf dem Level, auf dem wir zwei gerade sind und ist neugierig und findet genau diesen Thread... Bei gmx ist man schnell registriert... und ganz ehrlich... welcher Arbeitgeber ist technisch so auf der Höhe, überhaupt Headerzeilen in einem Email zu finden?
Die allermeisten verwenden wohl Outlook. Hast du schon mal probiert in Outlook die Headerzeilen eines Emails anzusehen???
Also das muss man mal finden, und dann muss man noch verstehen, was darin steht und dann braucht man noch ein besseres technisches Verständnis um überhaupt zu glauben, wenn man dem Auftraggeber erklärt, dass dieses Email von jemand anderem versendet wurde...

Für mich ist diese unsere Diskussion wieder ein Grund mehr, von den großen Mailanbietern wegzugehen und ein eigenes Email-Service aufzubauen... nämlich für mich und die Menschen in meinem Umfeld die mir wichtig sind - und die auch ein entsprechendes Sicherheitsbewusstsein haben.

Soviel zum prinzipiellen...

Wo ich allerdings immer noch denke, dass du einen Knopf im Denken hast...

Naja, so groß ist die Lücke also nicht. Ich habe das weiterhin noch mit Web und Strato verifiziert, dort ist es dasselbe. Und ich bin zu dem Schluß gekommen, dass das völlig in Ordnung ist und das die From-Adresse im Header als Security-Feature völlig belanglos ist. Ich habe diese Prüfung bei mir also schleunigst entfernt.

Die Geschichte mir dem Absender als "Security-Feature" zu kennzeichnen ist in der Tat übertrieben. Security ist etwas ganz anderes... Es ist lästig bis geschäfts- und rufschädigend, wenn jemand anderer völlig problemlos ein Email mit meinem Absender versenden kann. Aber die Sicherheit eines Computersystems wird damit niemals untergraben. Damit würd ich es nicht als Security-Problem kennzeichnen.

In der Tat ist es aber ein Security-Problem, wenn man sich auf allen möglichen Ports ohne Login per telnet von überall her auf einer Maschine einloggen kann.
Aber das hat nichts mit einer Prüfung auf einen Absender-Header zu tun.

Das ist eine Konfigurationsgeschichte ob TLS, STARTTLS und ob SMTP oder SMTP-AUTH auf welchen Ports zugelassen wird.

Auf localhost (also 127.0.0.1 oder ::1) muss wohl auf Port 25 ein Abliefern von Emails ohne Authentifikation möglich sein, sonst kann niemals ein Daemon ein Email an root oder den Admin-User senden.
Ob Port 25 nur auf localhost oder dem lo lauscht oder auch auf eth0 oder wlan0 macht einen bedeutenden Unterschied.
Dass auf Port 587 ausschließlich STARTTLS oder TLS möglich ist, und nur wenn eine TLS-gesicherte Verbindung aufgebaut ist dann ein PLAIN oder LOGIN-Authentifizierungsvorgang erzwungen wird, ist wohl heute Grundvoraussetzung.
Hier beginnt die Security im Email-Verkehr. Verschlüsselte Verbindung und erzwungene Authentifizierung. Damit ist ziemlich sichergestellt, dass die Authentifikations-Credentials nicht im Klartext übers Internet geschickt werden, und dass nur bekannte Teilnehmer am Mailverkehr teilnehmen können.

Das ist bei mir allerdings immer noch ein kleines spanisches Dorf, wie ich das bombenfest implementiere, sodass ich damit auch ans öffentliche Netz gehen kann.
Am liebsten wäre mir ja eine Client-Zertifikats-Authentifizierung. Aber da muss ich wohl noch ein wenig weiterstudieren, wie ich das auch nachvollziehbar auf einem anderen Rechner implementieren kann.

Und jetzt nochmal zurück zur eigentlichen Geschichte

Es sind - wie du korrekt erwähnst - zwei Ebenen beim Mailversand über den eigenen Mailserver von Thunderbird oder auch vom CLI.
Erste Ebene:
Der Client (Thunderbird, openssl, mail, telnet) kontaktiert den SMTP-Server.
Der SMTP-Server agiert als Server und nimmt ein Email entgegen oder rejectet es.
Nimmt er das Email an, kommt es in eine Queue.

Zweite Ebene:
Der SMTP-Server kontaktiert einen Smarthost um das Email weiter zu senden.
Der eigene SMTP-Server hat nun die Rolle eines Clients (so wie Thunderbird, openssl oder andere) und der Smarthost ist ein SMTP-Server in der Rolle eines Servers.
Der eigene SMTP-Server arbeitet die Queue ab und versendet ein Email nach dem anderen an den Smarthost indem er eine SMTP-Sitzung aufbaut (authentifiziert oder nicht) und dann ein Email nach dem anderen sendet. dann wird die SMTP-Sitzung wieder beendet.

Das heißt:
der eigene SMTP-Server in seiner Funktion als Server in der ersten Ebene erzwingt eine Authentifizierung mit Username und Passwort von Thunderbird, openssl oder mail..
Kann sich dieser Client authentifizieren, (dann setzt exim4 die Variable $authenticated_ID) nimmt er in Folge für diesen authentifizierten User Emails entgegen und wirft sie in die Queue.
Hier setzt der selbst unter Kontrolle stehende Security-Prozess an.
Habe ich alle Ports so konfiguriert, dass sie TLS verlangen und ein Login erzwingen, oder kann ich mich auch per telnet ohne Authentifizierung ein Mail versenden?
Ich habe an genau dieser Stelle eine zusätzliche Prüfung eingebaut:
Darf der authentifizierte User diese From-Header überhaupt verwenden? Wenn nein, wird das Email zurückgewiesen. Der Client bekommt eine Fehlermeldung.

Ist das Email in der Queue angelangt muss der Server in seiner Funktion als Client in einer Liste/Datenbank nachsehen, welchen SMTP-Server mit welchen Logindaten er zu dieser Absenderadresse zu verwenden hat, um dieses Email erfolgreich weiterzuleiten.
An dieser Stelle ist eine Prüfung auf einen Login-User völlig sinnlos, denn der kann nicht mehr festgestellt werden. An dieser Stelle kann der Server nur mehr SMTP-Server und Logindaten zur Absenderadresse in Erfahrung bringen.
In dieser zweiten Ebene ist exim oder wohl auch postfix ein ganz normaler Client, so wie Thunderbird oder Evolution auch. Zumindest dem empfangenden SMTP-Server gegenüber.

Und nochmal zu den "Usern" und "Absenderadressen"...
Ob exim oder postfix die Usernamen und Passwörter aus einer eigenen Datenbank bezieht, oder die vom Client gelieferten nur an dovecot weiterleitet und ein ok oder nicht ok zurückbekommt ist völlig unerheblich. Ob die Usernamen real existierende Unix-User am Mailserver sind, oder nur in einem Textfile in /etc/exim4/ hinterlegt sind, ist auch unerheblich.
Fakt ist, dass es einen Usernamen mit einem Passwort gibt, der sich bei exim zu auszuweisen hat, sonst stellt exim gar keine SMTP-Session her.
In dieser SMTP-Session (erste Ebene) gibt es einen authentifizierten Usernamen. Der ist in exim in der Variable $authenticated_id für diese Session abgelegt und kann jederzeit abgefragt werden. So auch in einer ACL (Access Control List) in der Stufe wo in der SMTP-Session der From-Header abgeliefert wird.
An dieser Stelle hat der Server eine From-Adresse und einen authentifizierten Usernamen dieser Session.

Dann muss ich den Server bei exim mittels ACL leiten in einer Datenbank (das kann auch ein Textfile sein) nachzuschlagen, ob er diese Absenderadresse überhaupt hat.
Hat er die Absenderadresse, dann muss er nachschlagen ob der authentifizierte Username diese Absenderadresse verwenden darf. Wenn ja, weiter im Prozess. Wenn nein hat er die Session für dieses Mail mit einer Fehlermeldung zu beenden und das Mail zurückzuweisen.

Ob exim jetzt in einer MYSQL-Datenbank nachschlägt, ob der User existiert und das richtige Passwort gesendet hat, oder in einem Textfile oder ob er dovecot diese Arbeit erledigen lässt und ob das ein Unix-User mit lokalem Konto ist oder ein virtueller User nur aus einer Datenbank, ist für exim völlig unerheblich. Ich erklär das jetzt deswegen zum wiederholten Male so ausführlich, weil ich beim Lesen deiner Antworten das Gefühl nicht loswerde, dass du dich so sehr an lokalen Unix-Usern aufhängst, die du nicht hast und nicht willst...
Und ich werd auch das Gefühl nicht los, dass du in deinen Ausführungen immer wieder zwischen Usern am Mailserver und Usern am Clientrechner und Email-Adressen hin und her springst und diese vermischt und dann wieder trennst... Mir kommts halt so vor.

Und du schreibst auch, dass das SMTPD-PWD in Thunderbird keine Bedeutung gehabt hätte...
Das glaube ich so nicht. Du hast wohl deinen SMTP-Server so konfiguriert, dass er sowohl authentifizierte wie auch nicht authentifizierte SMTP-Sitzungen zulässt. Je nachdem was der Client anfordert.
Exim muss man so konfigurieren, dass er auf Port 587 ausschließlich authentifizierte Sitzungen in einer TLS-gesicherten Verbindung erzwingt. Nicht-authentifizierte darf er gar nicht erst anbieten.
Port 25 ist wieder anders konfiguriert. Auf Port 25 müssen auch nicht-authentifizierte Verbindungen möglich sein. Sonst könnte apt oder ein anderer Prozess niemals ein Email an den Administrator senden. Aber Port 25 sollte dann nur auf lo (127.0.0.1) lauschen und niemals auf einem anderen Netwerk-Interface.
Und wenn du den Mailserver anderen anbietest, dann kannst du diese auch dazu "zwingen" ausschließlich Port 587 mit TLS-Verbindungssicherheit und LOGIN-Authentifizierung zu verwenden. Port 25 wird nämlich gar nicht erreichbar sein... hoffentlich.

lg scientific

[TomL]

Auf localhost (also 127.0.0.1 oder ::1) muss wohl auf Port 25 ein Abliefern von Emails ohne Authentifikation möglich sein, sonst kann niemals ein Daemon ein Email an root oder den Admin-User senden.

Ja, isses auch, localhost ist erlaubt.... trotz ansonsten erzwungener Anmeldung mit Anmeldenamen und Pwd.

der eigene SMTP-Server in seiner Funktion als Server in der ersten Ebene erzwingt eine Authentifizierung mit Username und Passwort von Thunderbird, openssl oder mail..

Solange Du nicht auf der niedrigen Ebene eines TCP/IP-Connects via OpenSSL bestätigst, dass es auch wirklich so ist, verlässt Du Dich auf erfülltes Wunschdenken. Du kannst einstellen was Du willst, wenn Du die Wirksamkeit bei einem direkten Connect (ohne Frontend) nicht bestätigst, bleibts ein Glückspiel... vielleicht ist es sicher... vielleicht auch nicht.... Reden bringt keine Sicherheit, nur eine konkrete Prüfung. Angefangen ohne Sicherheitsfeatures, dann schrittweise aufgebaut und jede Ebene separat kontrolliert.

Kann sich dieser Client authentifizieren, (dann setzt exim4 die Variable $authenticated_ID) nimmt er in Folge für diesen authentifizierten User Emails entgegen und wirft sie in die Queue.

Tja, ohne konkrete Prüfung bleibts reine Theorie.

Habe ich alle Ports so konfiguriert, dass sie TLS verlangen und ein Login erzwingen, oder kann ich mich auch per telnet ohne Authentifizierung ein Mail versenden?

Wenn TLS erzwungen ist., ist Telnet nicht möglich, aber OpenSSL. Probiers einfach im Terminal, ob auch eine OpenSSL-Anmeldung ohne Login möglich ist, dann weisst Du es genau.

Und ich werd auch das Gefühl nicht los, dass du in deinen Ausführungen immer wieder zwischen Usern am Mailserver und Usern am Clientrechner und Email-Adressen hin und her springst und diese vermischt und dann wieder trennst... Mir kommts halt so vor.

Ja, weil Du nicht zuhörst *lol* Ich habe das schon mehrfach gesagt, der lokal am Client angemeldete Linux-User, Windows-User oder obskure Default-Android-User hat für diese Baustelle absolut nichts mit den auf dem Server vorhandenen Linux-Usern zu tun, und noch weniger mit den Mailserver-Anmeldenamen/Pwd.... und absolut nichts von den obligatorischen Betriebsystem-Usern wird benötigt. Das Mailserver-Geschäft ist komplett und ausschließlich über Anmeldenamen (virtuelle User, bei mir ist es die lokale Email-Adresse) und ein eigenes Mail-Password geregelt. Du brauchst da nicht immer was reindeuten, was es nicht gibt.

Und du schreibst auch, dass das SMTPD-PWD in Thunderbird keine Bedeutung gehabt hätte...

Noch mal... mach einfach die Gegenprobe mit OpenSSL... solange das nicht bestätigt ist, ist alles nur Theorie und Wunschdenken und wenn Du Pech hast, liegt - wie heisst es so schön?- einfach nur opportunistic behavior vor....

Das glaube ich so nicht. Du hast wohl deinen SMTP-Server so konfiguriert, dass er sowohl authentifizierte wie auch nicht authentifizierte SMTP-Sitzungen zulässt. Je nachdem was der Client anfordert.

Nein, ich hatte den Server auf eigene Netze und eine Liste berechtigter Email-Adressen konfiguriert. Jetzt weiss ich aber, dass das Mist ist. Damit war auch eine Verbindung ohne Auth möglich. Jetzt habe ich das auf erzwungene Authentifizierung mit Anmelde-Name (bei mir die lokale Mailadresse) und Password eingestellt. Der Login mit Anmelde-Name und Password ist Zwang.

Man muss das jetzt auch nicht mehr weiter ausrollen....es ist ja alles gesagt.... weiteres Palavern ist dann nur noch Pudding an die Wand nageln. Wenn Du sicher bist, dass alles so ist, wie es sein soll, dann ist alles gut. Ich jedenfalls bin mir jetzt sicher... weil ich das wirklich sehr gründlich außerhalb der Anwndungssoftware kontrolliert habe. Und die Anwendungssoftware kann sich nicht mehr Rechte angeln oder mit Automatismen Secure-Einstellungen umschiffen, als ich auf niedrigstem Level festgestellt habt.

[scientific]

Auf localhost (also 127.0.0.1 oder ::1) muss wohl auf Port 25 ein Abliefern von Emails ohne Authentifikation möglich sein, sonst kann niemals ein Daemon ein Email an root oder den Admin-User senden.

Ja, isses auch, localhost ist erlaubt.... trotz ansonsten erzwungener Anmeldung mit Anmeldenamen und Pwd.

Das geht noch zu wenig weit. Welche Ports auf localhost?

der eigene SMTP-Server in seiner Funktion als Server in der ersten Ebene erzwingt eine Authentifizierung mit Username und Passwort von Thunderbird, openssl oder mail..

Solange Du nicht auf der niedrigen Ebene eines TCP/IP-Connects via OpenSSL bestätigst, dass es auch wirklich so ist, verlässt Du Dich auf erfülltes Wunschdenken. Du kannst einstellen was Du willst, wenn Du die Wirksamkeit bei einem direkten Connect (ohne Frontend) nicht bestätigst, bleibts ein Glückspiel... vielleicht ist es sicher... vielleicht auch nicht.... Reden bringt keine Sicherheit, nur eine konkrete Prüfung. Angefangen ohne Sicherheitsfeatures, dann schrittweise aufgebaut und jede Ebene separat kontrolliert.

Natürlich muss man das testen, was man konfiguriert hat.
Aber du musst auch unterscheiden, in welcher Rolle der Mailserver gerade arbeitet. Liefert der Client ein Mail bei "meinem" exim ab, ist exim in der Rolle eines Servers.
Liefert exim beim Smarthost ab, ist exim ein Client.

Ist der Smarthost so konfiguriert, dass Hinz und Kunz dort jeden Mist abliefern können ohne zu sagen wer sie sind, ist das nicht meine Verantwortung (außer dass ich dort ein Emailkonto habe...). Wer ein Mail wie bei meinem exim abliefert kann, definiere ich selbst (und teste es natürlich)

Kann sich dieser Client authentifizieren, (dann setzt exim4 die Variable $authenticated_ID) nimmt er in Folge für diesen authentifizierten User Emails entgegen und wirft sie in die Queue.

Tja, ohne konkrete Prüfung bleibts reine Theorie.

Nein. Das hat jetzt weniger mit Prüfung zu tun, ob ich mit openssl oder telnet überhaupt ein Email abliefern kann, sondern mehr mit einem Studieren der Debug-Logs.
Ich liefere mit openssl oder Thunderbird ein Email und sehe im Log zu, was mein exim macht... Welche Router welche ACL, welche Transports werden wie abgearbeitet.

Und siehe da... $authenticated_id ist entweder der authentifizierte User, oder wenn ich von einer Shell am Mailserver abliefere, der Unixuse mit dem ich DORT eingeloggt bin, und wenn ichs von außerhalb und anonym mache(n kann), ist es leer...

Du hüpfst mir grad zu schnell. $authenticated_id ist eine von vielen Variablen, die exim während der Abarbeitung von Emails setzt und verwendet. Da gibt es Variablen die sich auf eine SMTP-Session beziehen und da gibt es Variablen die sich nur auf ein Email beziehen. $authenticated_id bezieht sich auf die Sesseion. Also vom login am Email-Server bis zum Beenden der Session. Wieviele Emails dazwischen gesendet werden, ist unerheblich. (Meist ist es eh nur eines. es können aber auch mehrere sein!!)

Habe ich alle Ports so konfiguriert, dass sie TLS verlangen und ein Login erzwingen, oder kann ich mich auch per telnet ohne Authentifizierung ein Mail versenden?

Wenn TLS erzwungen ist., ist Telnet nicht möglich, aber OpenSSL. Probiers einfach im Terminal, ob auch eine OpenSSL-Anmeldung ohne Login möglich ist, dann weisst Du es genau.

Eh.

Und ich werd auch das Gefühl nicht los, dass du in deinen Ausführungen immer wieder zwischen Usern am Mailserver und Usern am Clientrechner und Email-Adressen hin und her springst und diese vermischt und dann wieder trennst... Mir kommts halt so vor.

Ja, weil Du nicht zuhörst *lol* Ich habe das schon mehrfach gesagt, der lokal am Client angemeldete Linux-User, Windows-User oder obskure Default-Android-User hat für diese Baustelle absolut nichts mit den auf dem Server vorhandenen Linux-Usern zu tun, und noch weniger mit den Mailserver-Anmeldenamen/Pwd.... und absolut nichts von den obligatorischen Betriebsystem-Usern wird benötigt. Das Mailserver-Geschäft ist komplett und ausschließlich über Anmeldenamen (virtuelle User, bei mir ist es die lokale Email-Adresse) und ein eigenes Mail-Password geregelt. Du brauchst da nicht immer was reindeuten, was es nicht gibt.

Du unterstellst mir dauernd, ich würde den Usernamen und das Passwort, mit dem ich mich auf irgend einem Rechner anmelden kann um Thunderbird oder eine Shell mit telnet starten zu können in meine Überlegungen mit einbeziehen...

NEIN!

Am Mailserver, der ein Linuxrechner ist, kann ich lokale User konfigurieren. Mit adduser, homeverzeichnis erzeugen und allem Pipapo bishin zum ssh-Zugang. Wie auf jedem normalen Linux-Rechner eben.
Und diese normalen Unix-User am Mailserver sind in der Regel auch Email-Empfangsfähig. Die Emailadresse dafür lautet z.B. scientific@mailserver, wenn keine nähere fqdn definiert ist und mailserver (oder mailserver.local) im LAN erreichbar ist.
Um mit SMTP-Auth ein Email versenden zu können würde zu dieser Email-Adresse der Loginname für SMTP-Auth scientific sein und das Passwort jenes mit dem sich scientific auch per ssh am Mailserver einlogt.

Das ist eine Möglichkeit. Und wenn ich von lokalen Usern bisher gesprochen habe, habe ich mich IMMER auf diesen Unix-User am Mailserver bezogen. Die Clientrechner interessieren mich nicht. Und als Clientrechner bezeichne ich einen Linux-, Windows oder Android-Rechner auf dem irgend ein SMTP-fähiger Mailclient läuft, der sich dann mit dem Mailserver verbinden kann.

Und irgendwie beschleicht mich grad wieder das Gefühl, dass du jetzt überhaupt nicht auf die beiden Ebenen, die Rollen als Server und Client, die ich beschrieben habe, die exim (oder postfix) im Zuge des Sendens einer Email einnehmen muss, eingehst.

Und du schreibst auch, dass das SMTPD-PWD in Thunderbird keine Bedeutung gehabt hätte...

Noch mal... mach einfach die Gegenprobe mit OpenSSL... solange das nicht bestätigt ist, ist alles nur Theorie und Wunschdenken und wenn Du Pech hast, liegt - wie heisst es so schön?- einfach nur opportunistic behavior vor....

Wenn du das so siehst... Ich schrieb von den Möglichkeiten, wie du einen Mailserver konfigurieren kannst, nicht wie du es getan hast.

Das glaube ich so nicht. Du hast wohl deinen SMTP-Server so konfiguriert, dass er sowohl authentifizierte wie auch nicht authentifizierte SMTP-Sitzungen zulässt. Je nachdem was der Client anfordert.

Nein, ich hatte den Server auf eigene Netze und eine Liste berechtigter Email-Adressen konfiguriert. Jetzt weiss ich aber, dass das Mist ist. Damit war auch eine Verbindung ohne Auth möglich. Jetzt habe ich das auf erzwungene Authentifizierung mit Anmelde-Name (bei mir die lokale Mailadresse) und Password eingestellt. Der Login mit Anmelde-Name und Password ist Zwang.

Wie willst du einen Server auf eine berechtigte Email-Adresse konfigurieren und dann eine Verbindung ohne Authentifikation ermöglichen?
Damit beim SMTP-Server überhaupt eine Absende-Adresse ankommt, muss VORHER ein Authentifikationsvorgang stattgefunden haben (oder keiner konfiguriert sein).

Das SMTP-Protokoll läuft ja so ab, dass sich auf einer Schnittstellt (lo, eth0, wlan0) ein client meldet. Der Server sagt, ob er sich authentifizieren muss (oder nicht), und dann authentifiziert sich der Client. Ob der Anmeldename nun "Hudriwudir0815" oder "scientific" oder "toml@meintollermailserver.example" ist, hängt von der Datenbank ab, die exim (oder postfix) befragt, welche User sich mit welchem Passwort anmelden dürfen. Ist diese Datenbank /etc/passwd und /etc/shadow, dann ist es ein lokaler Unix-User (lokal=am Mailserver), ist es ein File oder eine mysql-Datenbank, kann es auch ein Username sein, der wie eine Emailadresse AUSSIEHT!!!

Schafft der Client das, meldet der Server OK zurück und ist bereit ein Email entgegenzunehmen.
Dann erst kommt da ein Absender und ein Empfänger und der Inhalt des Mails dran.

Ist das Mail gesendet, können in dieser Session weitere Emails versendet werden. Wieder Absender, Empfänger und Inhalt schicken.
Bei all diesen Emails in dieser einen Session die nur einmal am Anfang eine Authentifikation erfordert hat, gibt es diesen einen Usernamen, der sich authentifiziert hat.
Der Mailserver kann nun bei jeder einzelnen Email prüfen, ob dieser User die jeweils zur Email verwendete Absendeadresse überhaupt verwenden darf.
gmx prüft das nicht. Ich lasse es schon prüfen.

Am Ende wird die Sitzung beendet.

Soll erneut ein Email geschickt werden, muss eine neuerliche Authentifikation stattfinden.

Thunderbird beendet nach jedem Email die Session und muss sich erneut einloggen (Beim Versand!!!)

Man muss das jetzt auch nicht mehr weiter ausrollen....es ist ja alles gesagt.... weiteres Palavern ist dann nur noch Pudding an die Wand nageln. Wenn Du sicher bist, dass alles so ist, wie es sein soll, dann ist alles gut. Ich jedenfalls bin mir jetzt sicher... weil ich das wirklich sehr gründlich außerhalb der Anwndungssoftware kontrolliert habe. Und die Anwendungssoftware kann sich nicht mehr Rechte angeln oder mit Automatismen Secure-Einstellungen umschiffen, als ich auf niedrigstem Level festgestellt habt.

Eine Prüfung der Einstellungen ist unumgänglich. Da bin ich voll bei dir.

Und eines muss ich dir auch sagen. Unsere Diskussionen sind durchaus geprägt von "du hörst nicht zu"... Aber beide Threads gaben mir den Anreiz, mich eingehender mit SMTP zu beschäftigen. Und ich hab das Gefühl, erstmalig das halbwegs zu begriffen zu haben, was da überhaupt abrennt. Ich habe noch genauer die Logs studiert um zu verstehen, wann ich wo in den Prozess eingreifen muss, um das zu erreichen, was ich will.
Die Konfiguration von exim ist in der Tat nicht einfach. Die Syntax alles andere als logisch.
Aber ich habs mittlerweile geschafft, in einem Debianpaket Konfigurationsschnipsel so zu bauen und an die richtigen Stellen einzubauen, dass es genügt das Paket zu installieren und in bloß durch das setzen von wenigen Variablen für die Konfig "meine" Erweiterungen zu aktivieren oder auch einfach wieder zu deaktivieren. Genauso wie Debian das exzessiv mit der exim-Konfiguration betreibt. Es fügt sich nahtlos ein. Kommentiere ich die Variable aus, ist das ursprüngliche Verhalten von Debians exim wieder vollkommen hergestellt.

Ich kann so zu Testzwecken (und auch auf Testrechnern) prüfen, ob die Installation und Konfiguration in der Tat so einfach ist, wie ich es mir vorgestellt habe.

lg scientific