☰

Mutt sendet keine E-Mail, wenn ein SMTP-Server angegeben wird

tag-icon • tag-icon mutt smtp
Mutt sendet keine E-Mail, wenn ein SMTP-Server angegeben wird

Ich versuche, es muttals meinen E-Mail-Client zu verwenden, und es funktioniert gut für mein Gmail-Konto. Aber wenn ich meine Arbeits-E-Mail verwende, werden die E-Mails nicht gesendet. Es wird kein Fehler angezeigt, es werden einfach keine gesendet. Die Zeile in meiner .muttrcDatei, die dieses Problem verursacht, ist:

setze SMTP-URL = "smtp://mail.my_work_email_server.com:587"

Das Verhalten ändert sich weder beim Hinzufügen smtp_passnoch durch die Änderung des Namens des E-Mail-Servers (d. h. durch die Verwendung einer „fiktiven“ Serveradresse).

Antwort1

Ich hatte das Gleiche und das hat bei mir funktioniert.

set ssl_starttls=yes
set ssl_force_tls=yes

set imap_user = "[email protected]"
set imap_pass = "!HASHEDPASSWORD!"
set folder = imap://mail.example.com/
set spoolfile = imap://mail.example.com/INBOX

# SMTP user auth
# # fill in the right user and pass based on your setup
# # protocols: smtp for TLS (25/587), smtps for SSL (465)
set smtp_url = "smtp://[email protected]:587"
set smtp_pass = "$imap_pass"

# Where to save copies of outgoing mail
set record = '+Sent'

Was dazu führte, dass es bei mir NICHT funktionierte, war die Reihenfolge der Dinge in der Konfigurationsdatei und eine Definition für „Datensatz festlegen“ für einen Ordner, die einen Link zu einem nicht vorhandenen Ordner darstellte.

Als ich die Frage zum Erstellen des Ordners mit „Nein“ beantwortete, blieb er hängen und es wurde kein Datenverkehr zum SMTP-Server festgestellt.

PS: Überprüfen Sie die bezogenen Konfigurationsdateien. Diese geben möglicherweise widersprüchliche Einstellungen an und/oder sind in der falschen Reihenfolge.

HTH

Antwort2

Können Sie mit einem anderen Mail-Client auf diesem Rechner erfolgreich E-Mails über SMTP versenden? Können Sie per Telnet auf Ihren SMTP-Server zugreifen und eine Verbindung herstellen? Verwenden Sie STARTTLS?

In Mutt verwenden Sie das Protokoll, smtpsum eine Verbindung zu kennzeichnen, die von Anfang an mit TLS/SSL gesichert ist. Wenn Ihr Mailserver dies erwartet (und das tun heutzutage viele), könnte das Ihr Problem sein.

Wenn Ihr Mailserver jedoch die Verwendung erwartet STARTTLS, verwenden Sie das reguläre smtp://Protokoll in smtp_urlund stellen Sie sicher, dass Sie set ssl_starttls=yes.

Hier ist eine Beispielsitzung telnet, die einen Mailserver zeigt, der STARTTLS verwendet:

$ telnet smtp.example.com 587
Trying 127.0.0.1...
Connected to smtp.example.com.
Escape character is '^]'.
220 smtp.example.com ESMTP Postfix (Debian/GNU)
EHLO test
250-
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

Antwort3

Ich habe einen ganzen Tag damit verbracht, dies herauszufinden und VIELE Kombinationen zwischen verschiedenen SSL/TLS- und Portkonfigurationen zu optimieren, ohne Erfolg, bis ich heute endlich Folgendes gezielt ausprobiert habe:

set ssl_starttls = no

Es scheint, dass Mutts Standardverhalten darin besteht, STARTTLS zu versuchen, also müssen Sie ihm ausdrücklich sagenNICHT

smtp_urlAußer den offensichtlichen war keine weitere Konfiguration erforderlich smtp_pass. Ich kann jetzt problemlos E-Mails mit diesem.muttrc

set ssl_starttls = no
set smtp_url = "smtp://[email protected]@mail.example.com:587/"
set smtp_pass = "password"

Das klappte mit demNicht empfohlenSSL-Konfigurationen von meinem E-Mail-Anbieter. Ich kann die empfohlene Konfiguration mit Port 465 immer noch nicht verwenden.

Dies sind alle Konfigurationen, die ich optimiert habe und die sich auf das Senden von E-Mails auswirken, falls es jemand anderes versuchen möchte:

set ssl_starttls = no    # apparently yes is default.
set ssl_force_tls = yes
set smtp_authenticators = "login"

set smtp_url = "smtp[s]://..."
set certificate_file = "~/.mutt/certificates"    # some recommend creating the file first: mkdir ~/.mutt && touch ~/.mutt/certificates

set ssl_verify_host = no
set ssl_verify_dates = no

Antwort4

Mir ist klar, dass dies ein alter Thread ist, aber gestern habe ich zwei Stunden damit verbracht, herauszufinden, warum die oben genannten Konfigurationen bei mir nicht funktioniert haben, und ich möchte die Lösung teilen, um anderen Leuten Zeit zu sparen.

Das Problem bestand darin, dass ich das Zertifikat vom SMTP-Server von Google mindestens einmal akzeptieren musste. Dazu muss Mutt ausgeführt werden, ohne dass die Eingabe umgeleitet wird. Andernfalls kann Mutt Sie nicht zur Annahme des Zertifikats auffordern.

Übrigens sollten Sie (a) für immer auswählen, damit das Zertifikat in gespeichert wird .mutt/certificates. Wenn Sie (o) für einmal auswählen, wird das mitgelieferte Zertifikat zwar verwendet, aber nicht in gespeichert  .mutt/certificates.

Führen Sie also mutt aus, ohne die Eingabe umzuleiten (das schließt die Weiterleitung zur Standardeingabe ein) und akzeptieren Sie dann das angebotene ZertifikatAimmer. Wenn Sie danach mutt das nächste Mal ausführen, sollte es einfach funktionieren, da es das gespeicherte Zertifikat verwendet.

verwandte Informationen