mailcow<>postfix: num=62:hostname mismatch

camel

Hallo, ich bin seit 1 Woche begeisterter mailcow benutzer und bin begeistern. Hab aber ein kleines Problem:

Der mailcow-server hat dual-stack und beide ptr zeigen auf den hostnamen
mailcow.aaa.tld
welcher auch A und AAAA auf den mailcow hat

Es sollen 3 Domains verwaltet werden:
aaa.tld
bbb.tld
ccc.tld

In mailcow hab ich die SAN Option auf “mail.*” gesetzt und so haben alle 3 letsencrypt Zertifikate jeweils
autodiscover.???.tld autoconfig.???.tld und mail.???.tld

der MX aller Domains steht auf mail.???.tld . DMARC, DKIMund spfsind auch im dns gesetzt, dnssec ist an

Wenn ich mich auf die mailports von aussen verbinde funktioniert SNI und ich bekomme die passenden Zerifikate je domain

ZUHAUSE hab ich schon länger einen aktuellen postifx (kein mailcow) der lokal alles annimmt, auch unverschlüsset.
Abhängig von Absender wird über den entsprechende entfernten Mailaccount gesenden, also gmx, web, gmail und jetzt auch die 3 mailcow domänen

ABER beim verschicken als test@bbb.tld steht im log des lokalen postfix:


postfix/smtp[101647]: A76B954028F: to=<example@gmx.de>, relay=mailcow.aaa.tld[korrekte:ip:v6]:25, delay=2.8, delays=0.07/0.09/2.3/0.3, dsn=5.7.1, status=bounced (host mailcow.aaa.tld[korrekte:ip:v6] said: 554 5.7.1 <example@gmx.de>: Relay access denied (in reply to RCPT TO command))
und 2 sekdunden später
postfix/smtp[101647]: server certificate verification failed for mail.bbb.tld[korrekte:ip:v6]:25: num=62:hostname mismatch
postfix/smtp[101647]: 6CFB5540BB2: Server certificate not verified

scheinbar weigert sich mein lokaler postfix an mailcow anzumelden, evtl weil ihm etwas am ssl nicht passt.

Jetzt weiss ich nicht ob das Problem am lokalen Postfix oder am Mailcow server liegt!
Wenn ich lokal "smtp_tls_security_level" = mayoder nonesetze geht es…
oder wenn ich im lokalen postfix “sender_relay” auf “mailcow.aaa.tls:587” setzte - port MUSS sein und es darf nicht Host mail.aaa.tld sein. Ich hätte aber lieber mail.* …

Hat jemand eine Idee?

Ich kann leider meinen Post nicht editieren…

smtp_tls_security_level=secure geht mit den nicht-mailcow accounts ohne problem, auch ohne Port

Das num=62:hostname mismatch kommt vermutlich von openssl, aber manuell ausgeführt sehe ich keinen Fehler und die korrekten Zertifikate:

  openssl s_client -starttls smtp -connect mailcow.aaa.tld:587  -verify_hostname mailcow.aaa.tld  | openssl x509 -noout -text
  openssl s_client -starttls smtp -connect mail.aaa.tld:587     -verify_hostname mail.aaa.tld     | openssl x509 -noout -text
  openssl s_client -starttls smtp -connect mail.bbb.tld:587     -verify_hostname mail.bbb.tld     | openssl x509 -noout -text

esackbauer

camel der MX aller Domains steht auf mail.???.tld

Das scheint der Fehler zu sein. Dein Mailserver heisst mailcow.aaa.tld und so meldet der sich auch bei einem HELO.
Deshalb soll auch als MX Record für alle domains mailcow.aaa.tld drinstehen.
SMTP kann kein SNI, das geht nur bei nginx.

Steht eigentlich auch so in der Doku:
@ IN MX 10 mail.example.org. (your ${**MAILCOW_HOSTNAME**})

camel

Das hatte ich schon öfter gelesen, hab es dann überprüft und nicht für die Ursache befunden.
Denn sonst bräuchte man SNI für Email überhaupt nicht. zB Google macht es auch nicht so

dig +short gmail.com MX
40 alt4.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.

telnet gmail-smtp-in.l.google.com 25
Trying 2a00:1450:4013:c14::1a...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP a640c23a62f3a-a69127ec0c3si290771966b.917 - gsmtp

nslookup mx.google.com
** server can't find mx.google.com: NXDOMAIN

Also der erste Mailserver von gmail ist gmail-smtp-in.l.google.com
und behauptet von sich mx.google.com zu sein.
Dazu ist mx.google.com gar nicht als ipv4 oder v6 im dns!

Bezüglich PTR:

dig +short google.com MX

10 smtp.google.com.

nslookup smtp.google.com

Non-authoritative answer:
Name:   smtp.google.com
Address: 64.233.166.27
Name:   smtp.google.com
Address: 74.125.71.27
Name:   smtp.google.com
Address: 74.125.71.26
Name:   smtp.google.com
Address: 64.233.167.26
Name:   smtp.google.com
Address: 64.233.166.26
Name:   smtp.google.com
Address: 2a00:1450:400c:c0a::1b
Name:   smtp.google.com
Address: 2a00:1450:400c:c09::1b
Name:   smtp.google.com
Address: 2a00:1450:400c:c09::1a
Name:   smtp.google.com
Address: 2a00:1450:400c:c02::1a

nslookup 64.233.167.26

26.167.233.64.in-addr.arpa      name = wl-in-f26.1e100.net.

esackbauer

camel Also der erste Mailserver von gmail ist gmail-smtp-in.l.google.com

Aber der liefert vermutlich das richtige Zertifikat für diesen DNS Namen aus. Darum geht es.
Dein MX Record zeigt auf einen Namen, der nicht an erster Stelle als Hauptname/Subject im SAN Zertifikat steht.

Scheint der HELO Name wohl zweitrangig zu sein.

camel

Doch, die sind richtig! Ich hab das mit den openssl s_client Befehlen oben geprüft

esackbauer

Ich vermute dann kann openssl mit SNI umgehen, aber dein postfix nicht.

Gib mal openssl s_client -starttls smtp -connect mail.bbb.tld:587 -subject | openssl x509 -noout -text

Und hier steht, dass die Option -verify_hostname auch die SAN überprüft. Dann kein wunder dass es richtig ist. Das macht der postfix aber nicht.

camel

Da ich diese Probleme nur mit den 3 eigenen domains für die ich mailcow installiert hab auftritt ist es wahrscheinlicher dass es an mailcow liegt und nicht am lokalen postfix (fedora 40 auf rapspberry aarch64) . Aber ich weiss es halt nicht

s_client: Unknown option: -subject
s_client: Use -help for summary.
Warning: Reading certificate from stdin since no -in or -new option is given
Could not find certificate from <stdin>

esackbauer

camel s_client: Unknown option: -subject

Mach das mal lokal von deinem Zertifikat aus data/assets/ssl.
openssl x509 -noout -subject -in cert.pem

camel Das hetten wir doch schon, dann sollte es bei google/gmail auch nicht gehen

Doch da geht es genauso:
https://www.checktls.com/TestReceiver?LEVEL=DETAIL&EMAIL=gmail-smtp-in.l.google.com
Der Server liefert genau das Zertifikat mit den subject/common name zurück.

Und deiner liefert eben auf den Namen mail.bbb.tld nur das eine Zertifikat zurück wo mail.bbb.tld irgendwo im SAN steht (die Postfix nicht prüfen kann), aber mailcow.aaa.tls eben im common name steht.
Es muss mailcow.aaa.tld im MX record stehen.

esackbauer

Nö, das liegt ziemlich sicher an deinen MX records.

camel

Das hetten wir doch schon, dann sollte es bei google/gmail auch nicht gehen

camel

in data/assets/ssl gibt es verzeichnisse für die 4 hostname der 3 domains:

find . -name cert.pem
./cert.pem                          subject=CN = mailcow.aaa.tld
./mailcow.aaa.tld/cert.pem          subject=CN = mailcow.aaa.tld
./mail.aaa.tld/cert.pem             subject=CN = mail.aaa.tld
./mail.bbb.tld/cert.pem             subject=CN = mail.bbb.tld
./mail.ccc.tld/cert.pem             subject=CN = mail.ccc.tld

wenn ich mit dem browser die https mailcow config anschaue sehe ich je domain auch die passenden letsencrypt zertifikate

bei www.checktls.com muss man man wohl bezahlen

esackbauer

Ich glaube der postfix im mailcow verwendet nur das hier:
./cert.pem subject=CN = mailcow.aaa.tld

[unknown] https mailcow

Das ist nginx… der händelt die Zertifikate anders.

camel

Nein, das stimmt nicht. In ./data/conf/postfix/sni.map ist jedem Hostnamen sein Zertifikat (automatisch von mailcow) zugeordnet.
Dort sind auch noch die autoconfig+autodiscover für alle domains drin

Und in ./data/conf/nginx/sites.active sowie ./data/conf/dovecot/sni.conf sind auch die 4 zertifikate (automatisch) drin

camel

Nach viel herumprobieren geb ich es vorerst auf da ich keine Ideen mehr habe.

Mit diesen Einstellungen des lokalen Postfix funktioniert es immerhin, auch wenn es nicht schön ist!

smtp_tls_mandatory_ciphers = high

sender_relay:
@aaa.tld     mail.aaa.tld:587
@bbb.tld     mail.bbb.tld:587
@ccc.tld     mail.ccc.tld:587

Ohne den submission port findet keine authentifizierung statt und die mal wird von mailcow abgelehnt.
Andere Anbieter brauchen keine Portangabe

Im Gunde ist mein Setup wie hier beschrieben: https://docs.mailcow.email/post_installation/firststeps-ssl/?h=domain2#the-lets-encrypt-subjectaltname-limit-of-100-domains