"Sowohl Port 465 als auf Port 587 funktionieren, beides ist intern (von Webservern) sowie von extern aus identisch erreichbar.
Ich hab's eben kurz per SSH von einem Webspace aus verifiziert: funktioniert beides, genau wie gewünscht.
(uiserver):u1234:~$ openssl s_client -connect smtp.ionos.de:465 -crlf
[…]
(uiserver): u1234:~$ openssl s_client -connect smtp.ionos.de:587 -crlf -starttls smtp
Unsere Mailrelays nehmen auf so ziemlich jedem leidlich sinnvollen Port authentifizierte Mail an.
Um fremde Mailserver vor Spam zu schützen, kann man von unseren Webservern nur "ausgewählte" Servern direkt auf Port 25 ansprechen, dazu zählen auch unsere Mailrelays.
Seit einem Firewall-Change vor etwa einem Jahr kann man die Ports Port 465 und Port 587 unbeschränkt ansprechen (beide Ports setzen immer eine Authentifizierung voraus, d.h. der Serverbetreiber kann sich gegen Spam wehren). Das "Mailer-Encryption SSL/TLS" ist etwas missverständlich - einige Mailprogramme bezeichnen es so, weil man sich das "damals" so gemerkt hatte. Wer heute noch "echtes" SSL verwendet, tankt sein Auto auch mit verbleitem Normal-Benzin - das ist genauso veraltet und genauso verboten ;-)
SSL als Protokoll (SSLv2, SSLv3) ist seit Jahren tot und wurde etwa zur Jahrtausendwende von TLS 1.0 abgelöst - das inzwischen von TLs 1.1, 1.2, 1.3 abgelöst wurde. Von daher hat dein Bekannter grundsätzlich recht, dass man eher TLS als SSL verwenden sollte - und das tun wir ja auch.
Aber: der Begriff "SSL-Zertifikat" hat sich leider eingebrannt, und das gleiche gilt für das "s" in "https" oder "smtps": viele Leute merken sich das als "SSL" statt als "secure".
Und genauso gilt das auch für die Contao-Konfiguration…
Was ist der Unterschied zwischen den beiden Ports:
- Port 465 ist implizites TLS, Port 587 ist explizites TLS.
o Auf Port 465 muss man immer eine TLS -Verbindung aufbauen, ehe man SMTP (dann über TLS) nutzen kann.
o Auf Port 587 spricht man zuerst etwas unverschlüsseltes SMTP. Der Client fragt den Mailserver nach seinen Fähigkeiten, und mit "STARTTLS" kann dazu auch ein Upgrade der laufenden Verbindung auf TLS gehören. Der Client kann sich dann ein Upgrade wünschen, danach geht's verschlüsselt weiter.
Das explizite TLS per STARTTLS war lange Zeit das einzig standardisierte Verfahren zum verschlüsselten Mailverkehr, smtps war ursprünglich für etwas leicht anderes gedacht und geriet in Vergessenheit.
Vor ein paar Jahren wurde es dann "wieder entdeckt" und der bereits früher reservierte Port 465 wieder neu reserviert: nun aber nicht mehr zur direkten Zustellung (="Postbote wirft Brief in den Hausbriefkasten"), sondern für die Mail Submission/Smarthost/Mailrelay (="jemand wirft einen frankierten Brief in den großen gelben Kasten an der Straßenecke, damit die Post ihn transportiert und zustellt").
Ein Haken bei Port 587: wenn sich ein bösartiger Angreifer (Man-in-the-Middle-Attacke) erfolgreich als Mailserver ausgibt, könnte dieser den Mailclients gegenüber einfach behaupten, der Mailserver würde kein Upgrade per STARTTLS anbieten. Viele Clients loggen sich dann über eine unverschlüsselte Verbindung ein und verschicken ihre Mails ohne Transportverschlüsselung, nur besonders hartnäckig konfigurierte Clients brechen dann ab.
Daher bevorzugt RFC 8314 das implizite TLS vor explizitem TLS: das explizite TLS ist in vielen Protokollen "eher optional" vorhanden, während das implizite TLS "nicht streichbar" ist. Also: Port 465 ist eigentlich der bevorzugte Port, Port 587 wird aber auch weiterhin unterstützt. Und aus Legacy-Gründen erlauben wir weiterhin Mailversand auf Port 25 (mit optionalem STARTTLS). Warum 465 oder 587 bei einigen Benutzern "nicht" geht - ich vermute mal, dass es nicht an der Verbindung liegt, sondern eher an Kleinigkeiten wie einem falsch kodierten Usernamen oder Passwort.
Unser Control Panel drängt leider seit einiger Zeit Benutzer dazu, auch Sonderzeichen in Passworten zu verwenden, dafür muss dann ggf. auch das Passwort in der YAML-Konfiguration entsprechend in Hochkomma gequotet werden.
Für Contao wäre das also dann ein
mailer_password: 'mein-Passwort&123'
… statt…
mailer_password: mein-Passwort&123
Nur so als Vermutung einer möglichen Fehlerquelle.
Der nächste Schritt wäre natürlich, die Fehlermeldung über "geht nicht" hinaus zu präzisieren."
(...)