Posts by ThomasL

    Das ist doch die richtige vorgehensweise, oder?

    Ja, alles richtig gemacht.

    Verhält sich der Postfix nach außen wie ein Client, oder wie ein Server?

    In dem Fall würde ich sagen, er ist ein Client. Postfix muss sich ja auf dem Server des Mail-Providers anmelden... und das tut er imho als Client. Ist das die einzige Email-Adresse mit dieser Fehlerreaktion? Gibt es bei diesem Mail-Provider andere Adressen, die gehen? Gibt es bei anderen Providern das gleiche Problem? Gibt es überhaupt Adressen, die fehlerfrei funktionieren?


    Also Fakt ist, der Anmelde-Prozess schlägt in diesem Fall fehl.... die Fehlermeldung ist eigentlich eindeutig... die Anmeldedaten sind falsch. Wir wissen jetzt nur noch nicht, warum die falsch sind. Das bedeutet, die müssen nicht mal zwangsläufig aufgrund der Zeichenfolgen falsch sein.... aber ich hoffe, dass Du Password UND Name wirklich sorgfältig verglichen hast und die in der 'relayhost_passwd' eingetragenen Daten per Copy/Paste auch mal direkt im Terminaltest probiert hast.


    Eine weitere Problemquelle kann der Port sein. Mich irritiert Port 25 in Deinen Logs.... eigentlich sollte das für SMTP über Port 587 laufen. Kannst Du mal bitte folgende Variante versuchen und jeweils eine von den zwei folgenden Zeilen anfügen:

    mail.your-server.de smtp:mail.your-server.de:587

    your-server.de smtp:your-server.de:587


    Code
    # cat /etc/postfix/rules/check_local_transport_maps
    # Lokal sender, local recipient - prevents transmission
    # over the Internet, processes only local Traffic
    #=======================================================
    mail lmtp:unix:private/dovecot-lmtp
    mail.your-server.de smtp:mail.your-server.de:587

    Nach der Änderung wieder kompilieren und Postfix restarten:

    Code
    systemctl stop postfix
    systemctl start postfix
    systemctl status postfix

    Wenn das im Dialog-Modus im Terminal funktioniert, muss Postfix das auch können. Wenn Postfix dann mit dieser Meldung

    said: 535 Incorrect authentication data)

    scheitert, ist die Ursache klar... die von Postfix verwendeten Anmeldedaten sind fehlerhaft hinterlegt.


    Das bedeutet, diese Datei ist zu kontrollieren, und zwar zeichenweise:

    /etc/postfix/rules/get_relayhost_passwd


    Und je nachdem, womit diese Datei erzeugt wurde, kann das auch eine Fehlerursache sein. Also wenn Du zuvor diese Datei mit einem Windows-Editor erstellt hast, bin ich sogar sicher, dass das der Fehler ist. Diese Datei muss zwingend mit einem Linux-Editor bearbeitet werden, wie nano, vim oder ne, oder auch dem internen Editor vom Midnight-Commander. Wenn Name und Password zweifelsfrei korrekt enthalten sind und keine falschen Leerzeichen eingefügt sind, trotzdem einmal alle Zeilenvorschübe erst entfernen und dann mit der Entertaste direkt hinter dem letzten Zeichen wieder einfügen. War Windows im Spiel liegt ein fehlerhaftes CR/LR (0x0d,0x0a) vor, Linux verwendet nur 0x0a.


    Nach durchgeführten Änderungen in der Datei nicht vergessen, diese wieder in das *.db-Format zu kompilieren....

    Bitte poste Terminal-Ausgaben in Code-Tags... in der obigen Forum, bunt und fett und variable Schriftgröße ist für alle eine Zumutung. Code-Tags sind das Icon </> in der Toolbar-Leiste:

    Code
    root@raspimail:/home/pi# dpkg -l libsasl2-modules
    | Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
    |/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
    ||/ Name Version Architektur Beschreibung
    +++-================-============-============-=================================
    un libsasl2-modules <keine> <keine> (keine Beschreibung vorhanden)


    Die Lösung kann die Installation des fehlenden Pakets sein... danach zur Sicherheit einfach alles neu starten und testen, ob der Fehler behoben ist.

    Code
    apt update
    apt full-upgrade (wenn Pakete als verfügbar/upgradable angezeigt werden)
    apt install libsasl2-modules
    systemctl reboot

    Das ist jetzt fummelei..... und sucherei.... mal sehen. Wie sind die Ausgaben der beiden folgenden Befehle, jeweils als root:

    Code
    # dpkg -l libsasl2-modules
    # postconf -n | grep smtp_sasl

    Und zweitens, ist sichergestellt, dass der Absender ("from" im Mail-Header) identisch mit der Postfach-Adresse bei gmail ist? Also das der Replace in check_generic_replace_from mit der richtigen from-Adresse ersetzt?

    An dieser Stelle noch einmal ausdrücklich meinen Dank an Lutz und Manu für einige wirklich hilfreiche Anregungen, die ich heute endgültig produktiv gesetzt habe.


    Das ist jetzt der aktuelle Stand dreier relevanter Code-Zeilen, die ich heute morgen ca 'ne halbe Stunde lang mit Stresstests und provozierten Fehlersituationen genervt habe... und verdammte hacke.... alles hat zu meiner großen Freude perfekt funktioniert... (:

    Code
    VirtUser=$(echo "$USER" | sed 's/^[ \t]*//;s/[ \t]*$//')
    LinuxUser=$(awk '$1 == "'$VirtUser'" {print $2;exit}' /etc/dovecot/alias_maps)
    LinuxUser_UID=$(/usr/bin/id -r -u "$LinuxUser" 2>/dev/null)

    ich finde mixed-quoting unschön

    Ja, das stimmt... der Vorteil hierbei ist allerdings, mir fällt die Interpretation bzw. das Verstehen der Bedeutung des Statements beim Lesen einfacher.... weil weniger Elemente..... was natürlich aber auch nur meinen subjektiven Vorlieben entspricht.... und ein wenig dem Alter entgegenkommt *fg*.


    Ich habe jetzt jedenfalls diese Variante produktiv übernommen... womit ich im Moment eigentlich auch zufrieden bin. Die anschließenden Tests haben auch keine Umstimmigkeiten ergeben.

    LinuxUser=$(awk '$1 == "'$VirtUser'" {print $2;exit}' /etc/dovecot/alias_maps)


    Danke Euch beiden.... :thumbup:

    und das geht mit Shell-Vars nicht bzw. wie du schriebst, nur mit wildem, fehlerträchtigen Escapen.

    Anscheinend gehts ja auch ohne escapen, wenn mit ' (vorne und hinten) verhindert wird, dass die Shell-Var expandiert wird. Das heisst, es geht, wenn die Shell-Var als Namen übergeben wird, aber nicht der Inhalt. Und der Inhalt kann nicht übergeben werden, weil die ganze Condition mit ' eingepackt ist, was wiederum die Expansion verhindert.... *hmmm*

    lutz, danke, das habe ich verstanden... ich bin zum einen an der Logik {print $NF;exit} hängengeblieben...und auch an der Tatsache, dass eingabe, greppen, if-condition und ausgeben alles in einem einzigen Statement stattfindet.... welches schließlich an einer Stelle zusätzlich irritierend auch noch eine bestimmte Rückschluss-Logik verwendet.... und zwar wird das letzte Feld von der Anzahl "Number of fields" zurückgegeben, was bei mir quasi nur zufällig mit dem gewollten Ergebnis als Feld 2 übereinstimmt. In meinem Fall eindeutiger und etwas leichter zu verstehen wäre jedoch die Variante {print $2;exit}.


    Aber insgesamt ist das schon starker Tobak.... und wiedermal bin ich total von den Möglichkeiten in Linux beeindruckt.... aber gleichzeitig auch etwas abgeschreckt... weil ich Sourcecode immer eher nach der Prämisse "hohe reproduzierbarkeit" erstellt habe. :conf:

    ...würde ich das gerne verstehen:

    Du hast tatsächlich Recht, das war wirklich nicht das Problem, sondern die Tatsache, dass es mehrere Postfächer gibt, die mit dem Wort "thomas" anfangen.... also nach dem Muster "vorname.nachname@domain.tld". Ich habe 3 Echt-Namen-Postfächer bei 3 Mailhostern. Dementsprechend angelehnt sind die virtuellen User bei Dovecot bezeichnet.

    Das funktioniert.... :conf:... allerdings versehe ich dieses Statement nicht... ich kanns nicht lesen... denn awk ist ja viel mehr, als nur mal eben ne Feld-Ausgabe... und so tief bin ich da leider nicht drin. Meine Version ist zwar länger und offensichtlich auch umständlicher, aber die verstehe wenigstens.... ich bin jetzt echt hin- und hergerissen. :daumendreh2:

    Versuche mal bitte

    Code
    LinuxUser=$(/usr/bin/awk -v user="$VirtUser" '$1 ~ user {print $NF;exit}' /etc/dovecot/alias_maps)

    Ist fehlerhaft... (hier also ein provozierter Fehler), denn den User "tom" gibts nicht, sondern nur "toml"... und führt zu folgender Falsch-Ausgabe

    Code
    # echo $(/usr/bin/awk -v user="tom" '$1 ~ user {print $NF;exit}' /etc/dovecot/alias_maps)
    thomas


    Versuch mal

    Code
    LinuxUser=$(grep -w "^$VirtUser" -i /etc/dovecot/alias_maps | awk '{ print $2 }')

    BTW, sind die virtuellen Userkennungen wirklich case insensitive (Option "-i")?

    Das sieht erst besser aus und führt zu 2 korrekten Ausgaben, aber dann zum gleichen Fehler wie oben, siehe das Otto-Problem. Der Linux-User "thomas" hat mehrere Postfächer (virt.user) und eines von denen heisst auch "thomas", ein weiteres "toml".

    Code
    # echo $(grep -w "^tom" -i /etc/dovecot/alias_maps | awk '{ print $2 }')
    # echo $(grep -w "^toml" -i /etc/dovecot/alias_maps | awk '{ print $2 }')
    thomas
    # echo $(grep -w "^thomas" -i /etc/dovecot/alias_maps | awk '{ print $2 }')
    thomas thomas thomas thomas


    :conf: Meine cat-Variante mit der Einklammerung unterscheidet das im Moment ... ich konnte noch keine weiteren Fehler provozieren.


    Code
    # export VUSER="tom"; echo $(cat /etc/dovecot/alias_maps | awk '{ printf "(%s) %s\n", $1, $2 }' | grep -w "($VUSER)" | awk '{ print $2 }')
    # export VUSER="toml"; echo $(cat /etc/dovecot/alias_maps | awk '{ printf "(%s) %s\n", $1, $2 }' | grep -w "($VUSER)" | awk '{ print $2 }')
    thomas
    # export VUSER="thomas"; echo $(cat /etc/dovecot/alias_maps | awk '{ printf "(%s) %s\n", $1, $2 }' | grep -w "($VUSER)" | awk '{ print $2 }')
    thomas

    In der aktuellen Version habe ich '-i' entfernt, um auch da mehr Eindeutigkeit zu erzwingen... siehe oben 3. (die letzte) Variante in #35.

    So ein Mist... :denker:... das Problem ist deutlich anspruchsvoller.... wie sich jetzt nach Wegfall der zwei Blanks gezeigt hat. Es rappelt nur so mit Fehlermeldungen.... deshalb hier folgend noch mal die Entwicklungsschritte zusammengefasst.


    Ursprünglich mit den 2 Blanks, aber mit der Gefahr bei tabstops zu failen:

    LinuxUser=$(grep "$VirtUser " -i /etc/dovecot/alias_maps | awk -F ' ' '{ print $2 }')


    Die geänderte Variante ohne die zwei Blanks;

    LinuxUser=$(grep -w "$VirtUser" -i /etc/dovecot/alias_maps | awk '{ print $2 }')


    Und genau die failed nun bei folgender Situation in der alias_maps, also wenn der virtueller Dovecot-User gleich mit dem Linux-User ist und der User zusätzlich mehrere Postfächer hat ... also wenn die alias_maps so aussieht:

    Code
    #virtuser: linuxuser:
    otto otto
    ottofake otto
    dummyotto otto
    liselore otto

    Hier wird nach dem virtuellen User "otto" gegrept, der bei dem Inhalt allerdings 5 mal gefunden wird... was ein verrückter Mist..... :wallbash:


    Ich habe jetzt als Lösung diese Variante gefunden, die das ursprüngliche Blank (am virtuser) ersetzt und den virtuser nun mit () einklammert.

    LinuxUser=$(cat /etc/dovecot/alias_maps | awk '{ printf "(%s) %s\n", $1, $2 }' | grep -w "($VirtUser)" | awk '{ print $2 }')


    So ein hintenrum-gewürge....aber damit scheinen jetzt alle Varianten zu klappen... :conf:... welche üblen Fallen man sich selber programmieren kann....


    lutz.... bitte noch mal um Hilfe... und einen kritischen Blick.....

    Genau daran erkennt man den Unterschied zwischen Optimal und Über-Optimal.... und es ist der Beweis dafür, dass Über-Optimal keine Verbesserung ist, sondern tatsächlich eher schädlich ist.


    Ich habe das echt nicht gewusst... Danke für diesen Hinweis... ich habs schon umgebaut... jetzt fehlt nur noch der Update zur Web-Seite.

    Jo, stimmt... aber bei Deinem Background wird dir zweifelsfrei klar sein, dass einzelne Fehler ab einer gewissen Größe der IT-Installationen fast unvermeidlich sind. Und deswegen ist man dabei ja auch immer auf kritische Blicke durch andere angewiesen... weil man selber irgendwann und allzu oft darauf hereinfällt, beim Lesen eher das zu verstehen, was man eigentlich erwartet und dabei weniger die echte Bedeutung erfasst... zumal das ja *hier* bisher gut gelaufen ist. Deswegen kann man nur froh sein, wenn Leute drüber schauen und solche wertvollen Hinweise geben... :thumbup:


    Allerdings hat mir diese Zeile immer noch Kopfzerbrechen bereitet:

    LinuxUser=$(grep -w "$VirtUser" -i /etc/dovecot/alias_maps | awk -F ' ' '{ print $2 }')


    Durch den Parameter '-w' ist jetzt die Frage mit Space und Tab beim grep geklärt, das Ergebnis ist immer eindeutig. Aber das hat ja nicht zwangsläufig das gegebene Blank ' ' im awk-Statement eingeschlossen. Aber dabei haben jetzt alle Tests ergeben, dass (egal ob Tab oder Blank) die Rückgabe von Feld 2 konstant richtig ist. Ist das noch etwas, was Beachtung bedarf oder kann man das so akzeptieren? :conf: Wie ist Deine Meinung?


    Ganz losgelöst davon, habe ich es jetzt trotzdem erst mal aktualisiert hochgeladen... ohne weiteren Extra-Vermerk wegen des Updates. Ich habe drauf verzichtet, weil dieses Thema ja gerade erst gestern mit einem Update-Vermerk zum 2.1.20 versehen wurde.

    Wäre grep -w nicht sinnvoller als das angehängte Leerzeichen,

    Ich habe noch mal damit rumexperimentiert und dabei festgestellt, dass -w tatsächlich die einzig funktionierende Variante ist... so ein Mist... daran habe ich nicht gedacht. Das ergänzende Blank wirkt NUR dann, wenn man es auch wirklich manuell in der alias_maps getippt hat. Hat man stattdessen die Tab-Taste gedrückt und 0x09 wird nicht zu Spaces expandiert, failed meine Variante, mit -w wird es korrekt aufgelöst. :conf:


    Das muss ich heute sofort ändern... Danke für diesen wirklich wichtigen Hinweis.

    Irrtum... (:


    In diesem Fall (schau in den Script-Auszug) enthält $USER als Shell-Variable den virtuellen Dovecot-User.... deswegen das Dilemma mit der Frage überflüssig oder nicht....


    Es handelt sich dabei um eine explizit von Dovecot gestartete Shell (resp. Script als Eventhandler) aufgrund eines Mailuser-Logins in Dovecot... und diese Shell enthält von Dovecot gesetzte Shell-Vars... so eben auch $USER, was hier nix mit Linux-Usern zu tun hat, weil Dovecot gar keine Linux-User kennen muss. Deswegen ja auch meine Brücke mit "alias_maps".

    Wäre grep -w nicht sinnvoller als das angehängte...

    Guter Hinweis, damit werde ich morgen mal befassen.

    ...ergo Zeile 1 imho überflüssig

    Tja, vor dem Hintergrund, dass $USER hier nichts mit dem üblicherweise enthaltenen Linux-User (nach strenger Namensregelung) zu tun hat, sondern sich auf einen virtuellen Dovecot-User bezieht, kann ich diese Aussage resp. Frage gar nicht einschätzen. Diese Variable wird von Dovecot gesetzt und ich weiß schlichtweg nicht, an welche Restriktionen sich Dovecot für virtuelle Usernames hält und ob es ggf. auch unkonventionelle Namen zulässt. Das hier (siehe Zitat) schafft jedenfalls mehr Unsicherheit als Klarheit... irgend eine Idee dazu?


    https://wiki.dovecot.org/VirtualUsers

    "Usernames and domains

    Dovecot doesn't care much about domains in usernames. IMAP and POP3 protocols currently have no concept of "domain", so the username is just something that shows up in your logs and maybe in some configuration, but they have no direct functionality.


    So although Dovecot makes it easier to handle "user@domain" style usernames (eg. %n and %d variables), nothing breaks if you use for example "domain%user" style usernames instead. However some authentication mechanisms do have an explicit support for realms (pretty much the same as domains). If those mechanisms are used, the username is changed to be "user@realm".

    And of course there's no need to have domains at all in the usernames."