[Eisfair] mail 1.17.1: fetchmail scheitert am lokalen SMTP

[Marcus Röckrath]

Hallo Alexander,

Alexander Dahl wrote:

>>> Wenn MAIL_USER_USE_MAILONLY_PASSWORDS=no
>>> nicht (mehr) funktioniert, kann man es dann nicht auch gleich weglassen?
>>
>> Es geht doch nur um fetchmail nicht um die weiteren Authentifizierungen
>> deiner normalen User an pop/imap/smtp, für die gibt es hier keinerlei
>> neue Einschränkung/Änderung.
> 
> Das sehe ich anders.  Die Hilfe sagt "Über diesen Parameter wird
> gesteuert, ob eine separate Kennwortdatei für POP3/IMAP verwendet werden
> soll."  Dann müsste ich erstmal neue Passwörter für IMAP/POP3 setzen, da
> sind nämlich aus Sicht des Mail-Pakets bisher gar keine gesetzt.  Und
> würde ich sie setzen, stehen sie dann plötzlich unverschlüsselt als Wert
> von MAIL_USER_x_PASS im System.

Es kommt aber hinzu, dass du nicht nur POP/IMAP authentifiziert machst, 
sondern eben auch über SMTP_AUTH_TYPE=user die Senderichtung 
authentifizierst. Erst jetzt kommt überhaupt fetchmail ins Spiel.

Die zunächst für POP/IMAP gedachten MAIL_ONLY-Passwörter kommen dann auch 
für smtp ins Spiel.

Ist dein Mailserver über smtp von außen erreichbar?

Ist SMTP_AUTH_TYPE=user überhaupt notwendig? Ich habe das hier auf none im 
lokalen Netz.

> Technisch gesehen stimmt das auch.  Das bezieht sich aber nur auf die
> Authentifizierung, nicht auf die Verbindung.  Über eine verschlüsselte
> Verbindung ist eine plain-Text Auth vertretbar.

Klar, und wenn fetchmail Login/Plain-Auth über TLS kann, könnte man das 
gegebenenfalls einbauen. Auf die Schnelle finde ich in der Fetchmail-Doku 
nicht direkt einen Hinweis über TLS bei der lokalen Übermittlung der 
eingehenden Mail an den lokalen smtp. Für den Abruf vom externen Provider 
geht ja schon immer TLS.

> Natürlich.  Ohne Auth geht es auch gar nicht.  Es muss das gleiche
> Passwort angegeben werden wie beim Einloggen auf der Shell bzw. über
> SSH.

Für den Kontakt des Client zum Pop/Imap ist natürlich Authentifizierung 
erforderlich, aber Mails senden geht auch ohne - mache ich hier schon immer 
so.

> Es sei denn eines der nächsten Updates fixed das Verhalten?

Auch nach Debug-Output mit dem vorigen fetchmail kann ich nicht genau sagen, 
was die fetchmail-Macher nun geändert haben, so dass nun mit dem ansonsten 
unveränderten Mail-Paket zur Ablehnung der Verbindung kommt. Der smtp-Part 
in fetchmail scheint einem kompletten Rewriting unterzogen worden zu sein.

> Ich vermute die Authentifizierung am SMTP läuft über PAM?

Für dovecot wird eine pam-Konfiguration erstellt. Könnte exim PAM überhaupt? 
Müsste man mal recherchieren.

Welche Anmeldemethoden am lokalen SMTP bei dir aktiv sind, kannst du in der 
/var/spool/exim/configure ganz am Ende im Block "Authentifizierung" unter 
"server side" sehen. Da sind diverse "*_server:" definiert.

> Irgendwo klemmt es hier zwischen SMTP fordert
> keine Auth an (was auch logisch ist, wenn externe Server hier Mail
> einliefern sollen) und fetchmail will sich nicht authentifizieren.

Mach mal

telnet localhost 25
EHLO dein.server.lan

Was bietet dein eis-SMTP mit dem alten mail-Paket an?

AUTH-Zeile(n) dabei? Welche?

> Da
> das für den Fall SMTP_AUTH_TYPE='server' aber ja funktioniert (mit
> SMTP_AUTH_USER und SMTP_AUTH_PASS dann), muss es ja grundsätzlich gehen.

In diesem Fall erlaubt die Authentifizierung eine Passwortübermittlung im 
Klartext ohne TLS, was es bei "user" nicht tut.

Für mich lautet die Frage: Kann fetchmail eine TLS-Verbindung zum smtp 
aufbauen und welche Einstellungen in der fetchmail.conf sind dafür nötig.

Für mich sieht es im Mailpaket so aus:

Ich arbeite mich gerade auch erst aus gegebenen Anlass ein wenig in 
fetchmail ein, habe aber auf diese Frage noch keine konkrete Antwort.

-- 
Gruß Marcus
[eisfair-Team]