Hallo zusammen, ich teste von Zeit zu Zeit meinen Server über internet.nl. Dabei tauchen nun zwei Fehler auf: > Verdict: > At least one of your mail servers supports one or more insufficiently secure hash functions for key exchange. > > Technical details: > Mail server (MX) Outdated hash function > mail.xxxxxx.yyyy. SHA1 > Test explanation: > We check if your receiving mail servers (MX) support secure hash functions to create the digital signature during key exchange. > > The receiving mail server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The mail server creates this digital signature by signing the output of a hash function. > > Note that this subtest is only relevant for TLS 1.2. The supported hash functions can be configured via a separate TLS setting (e.g. SignatureAlgorithms in OpenSSL) and are not part of the cipher suite configuration. > > For more details on the status of SHA-1 and MD5, see RFC 9155. We do not test for MD5 because it is only supported by very outdated software. > > See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 3.3.5. > > Security level of hash functions for key exchange > > Good: SHA-256, SHA-384, SHA-512 > Phase out: SHA-224 (rarely used) > Insufficient: SHA-1, MD5 Sowie: > Verdict: > The public key of at least one of your mail server certificates is based on a signing algorithm with parameters that should be phased out as they are weaker, although you might still use them if absolutely needed. In a future update, they will likely become insufficient. > > Technical details: > Mail server (MX) Outdated signature parameter > mail.xxxxxx.yyyy. R13: RSAPublicKey-2048 > ... phase out > Test explanation: > We check if the public key of your mail server certificate and every intermediate certificate is based on a secure signing algorithm with secure parameters. > > The verification of certificates makes use of digital signatures. The public key of a certificate can be used to verify that a signature was created using the corresponding private key. > > Signing algorithm: The signing algorithm is determined when generating the certificate. A certificate can only contain one signing algorithm. It is possible to configure multiple certificates on a server to support more than one algorithm. Only the signing algorithms ECDSA, RSA and EdDSA are considered sufficiently secure. EdDSA is actually rarely, if ever, used. All mentioned algorithms are vulnerable to the quantum threat. They offer sufficient protection for now. Quantum-safe alternatives are not yet part of the TLS standards. > > Parameters: The security of ECDSA and EdDSA digital signatures depends on the chosen curve. The security of RSA is tied to the key length of the public key. > > For details on the relevant certificate field name see paragraph "4.1.2.7. Subject Public Key Info" of RFC 5280. > > See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 3.3.2 > > Security level of elliptic curves for ECDSA > > Sufficient: > > secp521r1 (rarely used) > secp384r1 > secp256r1 > x448 > x25519 > brainpoolP512r1 (rarely used) > brainpoolP384r1 (idem) > brainpoolP256r1 (idem) > Phase out: > > secp224r1 > Insufficient: > > Other curves > Security level of length of RSA keys > > Sufficient: At least 3072 bit > Phase out: 2048 – 3071 bit > Insufficient: Less than 2048 bit > Security level of Edwards curves for EdDSA (rarely used) > > Sufficient: > > Ed448 > Ed25519 > Insufficient: > > Other curves Dazu gab es die folgenden Support Beiträge welche nicht mehr aktuell sind: https://docs.mailcow.email/de/manual-guides/Postfix/u_e-postfix-harden_ciphers/ https://docs.mailcow.email/de/manual-guides/Dovecot/u_e-dovecot-harden_ciphers/ Kann mir jemand sagen was ich wo ändern muss damit mein Server wieder als grün angezeigt wird?

Puuuh. 🤔🤔🤔🤔🤷♂️🤷♂️🤷♂️ Lt. internet.nl kann ich mich der Frage nur anschließen. Sieht bei unserem System auch nicht ganz optimal aus. Jedoch große Testsysteme wie z. B. mxtoolbox.com kommen zu einem gegenteiligen Ergebnis. Ich habe zwar keine Verbesserung unseres Mailservers erreicht, dafür weiß ich jetzt, was ein Bimi-Logo ist 😂😂😂

@"Hindin-The-G"#p32114 hi. I've opened a request on Github to improve the Mailcow encryption suite, so you can get it again https://github.com/mailcow/mailcow-dockerized/issues/7208

@"Cisco30"#p32131 Vielen Dank für das erstellen des GitHub Issues! Ich bin gespannt, ob angepasst wird.

Guten Morgen, ich konnte zumindest den ersten Fehler beheben. Ich bin wie folgt vorgegangen: Datei anpassen oder erstellen: `/opt/mailcow-dockerized/data/conf/postfix/openssl.cnf` das muss rein: `openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] MinProtocol = TLSv1.2 CipherString = DEFAULT@SECLEVEL=2 #DAS IST DER FIX: SignatureAlgorithms = RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384` Dann In docker-compose.override.yml folgendes ergänzen: `services: postfix-mailcow: volumes: - ./data/conf/postfix/openssl.cnf:/etc/ssl/openssl.cnf:ro` Dann alles neu starten und danach war be mir das erste Finding gelöst. Allerdings kann nun mein Ceph Cluster keine E-Mails mehr an Mailcow abliefern, es kommt dann folgender Fehler: [upl-image-preview uuid=f7a64153-54c3-43bb-b961-9f29d23cdfed url=https://community.mailcow.email/assets/files/2026-04-30/1777529770-965125-cleanshot-2026-04-30-at-081558-at-2x.png alt={TEXT?}] Also erhöhte Sicherheit nimmt sich dann wieder die Balance mit Produktivität.

Die Einstellungen sollten standardmäßig "intermediate" sein. Servercow sollte in jedem Fall die neusten Cipher-Suites anbieten, sowie sämtliche veralteten und überholten Cipher als gesperrt abweisen. Was zeigt es eigentlich bei https://www.ssllabs.com/ssltest/ bei Euch an? Kann ich selbst nicht gegentesten, da hier Port 443 getestet wird und bei uns ein Reverse-Proxy antwortet.

Bei mir wird A+ angezeigt, was auch immer das bedeuten mag

@"Ganzjahresgriller"#p32136 Das Bedeutet "sehr gut". Also verwendet Ngix entweder bessere Cipher-Suites als per TLS over SMTP angeboten wird. Oder die Bewertungsmethode von internet.nl ist zu hart. Es bringt ja (noch) nichts alleinig die modernsten Cipher anzubieten, wenn 80% der großen Mailserver noch nicht umgestellt wurden. Somit endet die Nachrichtenzustellbarkeit sehr schnell. 😅😅

Bei mir auch. Aber die testen ja nur den Web Server, wo ja wiederum andere Cyphers konfiguriert sein können als für Postfix und Dovecot. Hier trotzdem noch das Rating und die Ciphers aus dem Test von SSL Labs: [upl-image-preview uuid=ddbc5b0e-291c-4d6e-877d-00fb33271b0b url=https://community.mailcow.email/assets/files/2026-04-30/1777541357-470727-image.png alt={TEXT?}] [upl-image-preview uuid=2fbf1692-4e6e-4569-aaae-22980e12a9b0 url=https://community.mailcow.email/assets/files/2026-04-30/1777541389-977229-image.png alt={TEXT?}]

Irgendwas scheint internet.nl geändert zu haben bei mir schlägt bei den Tests der Netfilter zu und blockt deren IP. Im Log steht: 62.204.66.10 matched rule id 4 (warning: non-SMTP command from internet.nl[62.204.66.10]: GET _ HTTP_1.1) Das hat aber schon mal sehr gut funktioniert.

@"mlcwuser"#p32138 So wird es vermutlich auch sein. Dass Ngix auf einen neuen Stand gebracht wurde, das "alte" SMTP Protokoll aber vernachlässigt.

mailcow Ciphers verstärken nicht merh aktuell

Becker884

Ja, allerdings kommen dort nicht so viele E-Mails rein, bisher ist mir nichts negatives aufgefallen.

KI sagt:

Wenn du diese “insufficient” Ciphers abschaltest, kann es in seltenen Fällen passieren, dass sehr alte Mailserver (die z.B. noch auf Windows Server 2008 oder uralten Linux-Distributionen laufen) keine TLS-Verbindung mehr zu dir aufbauen können. Diese würden E-Mails dann entweder im Klartext (falls erlaubt) oder gar nicht mehr zustellen.

Für den “Hausgebrauch” und moderne Kommunikation ist das Abschalten aber absolut empfehlenswert, um die 100% (und echte Sicherheit) zu erreichen.

Opportunistic TLS (STARTTLS) zwischen MTAs fällt zwar auf Plaintext zurück, wenn TLS scheitert – aber das ist kein Argument dafür, schwache Cipher anzubieten
Große Provider (Google, Microsoft, Posteo etc.) unterstützen alle modernen Cipher problemlos
Das BSI und NCSC empfehlen auch für SMTP moderne Cipher-Profile

Das Argument gilt höchstens für sehr alte Legacy-Systeme, die kaum noch im Umlauf sind.

CK_beats

Becker884
Danke für die Info!
Ich habe die Cipher Suites bei uns im Produktivbetrieb auch verändert. Bin gespannt, was passiert. Bzw. ob es Probleme gibt.
Außerdem ist mir aufgefallen, dass unser externer ITler damals bei der Installation von Mailcow die Zertifikat-Chain komplett hinterlegt hatte. Aber das R13 Zwischenzertifikat ist natürlich mittlerweile abgelaufen.

Anscheinend cached internet.nl alte Einstellungen und prüft sie nicht neu. Ich habe trotz Neustart aller Container keine Veränderung in der Bewertung. 🤔🤔🤔🤔

LS_RSA_WITH_CAMELLIA_256_CBC_SHA256	insufficient
...	TLS_RSA_WITH_CAMELLIA_256_CBC_SHA	insufficient
...	TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256	insufficient
...	TLS_RSA_WITH_CAMELLIA_128_CBC_SHA	insufficient
...	TLS_RSA_WITH_ARIA_256_GCM_SHA384	insufficient
...	TLS_RSA_WITH_ARIA_128_GCM_SHA256	insufficient
...	TLS_RSA_WITH_AES_256_GCM_SHA384	insufficient
...	TLS_RSA_WITH_AES_256_CCM_8	insufficient
...	TLS_RSA_WITH_AES_256_CCM	insufficient
...	TLS_RSA_WITH_AES_256_CBC_SHA256	insufficient
...	TLS_RSA_WITH_AES_256_CBC_SHA	insufficient
...	TLS_RSA_WITH_AES_128_GCM_SHA256	insufficient
...	TLS_RSA_WITH_AES_128_CCM_8	insufficient
...	TLS_RSA_WITH_AES_128_CCM	insufficient
...	TLS_RSA_WITH_AES_128_CBC_SHA256	insufficient
...	TLS_RSA_WITH_AES_128_CBC_SHA	insufficient
...	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA	insufficient
...	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA	insufficient
...	TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA	insufficient
...	TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA	insufficient
...	TLS_DHE_RSA_WITH_AES_256_CCM_8	insufficient
...	TLS_DHE_RSA_WITH_AES_256_CBC_SHA	insufficient
...	TLS_DHE_RSA_WITH_AES_128_CCM_8	insufficient
...	TLS_DHE_RSA_WITH_AES_128_CBC_SHA	insufficient
...	TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384	phase out
...	TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256	phase out
...	TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384	phase out
...	TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256	phase out
...	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384	phase out
...	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	phase out
...	TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256	phase out
...	TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256	phase out
...	TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256	phase out
...	TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384	phase out
...	TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256	phase out
...	TLS_DHE_RSA_WITH_AES_256_GCM_SHA384	phase out
...	TLS_DHE_RSA_WITH_AES_256_CCM	phase out
...	TLS_DHE_RSA_WITH_AES_256_CBC_SHA256	phase out
...	TLS_DHE_RSA_WITH_AES_128_GCM_SHA256	phase out
...	TLS_DHE_RSA_WITH_AES_128_CCM	phase out
...	TLS_DHE_RSA_WITH_AES_128_CBC_SHA256	phase out

… sowie

remote.kn-koehler.de.	R13: RSAPublicKey-2048
...	phase out

Becker884

Ich habe mit internet.nl auch mehrmals rumgespielt und die Einstellungen wurde sofort richtig erkannt, kein Cache!

Was sagt denn?
docker exec $(docker ps -qf name=postfix-mailcow) postconf -h tls_high_cipherlist ?

/usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 209: overriding earlier entry: smtp_tls_protocols=>=TLSv1.2 /usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 213: overriding earlier entry: smtpd_tls_protocols=>=TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

und
docker exec $(docker ps -qf name=dovecot) doveconf -n | grep ssl

CK_beats

Becker884
Vielen Dank für Deine Unterstützung!

Bei mir kommt eine völlig andere Ausgabe:

root@kn-mc01:/opt/mailcow-dockerized# docker exec $(docker ps -qf name=postfix-mailcow) postconf -h tls_high_cipherlist
/usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 203: overriding earlier entry: message_size_limit=104857600
aNULL:-aNULL:HIGH:@STRENGTH

Dovecot scheint zu passen:

root@kn-mc01:/opt/mailcow-dockerized# docker exec $(docker ps -qf name=dovecot) doveconf -n | grep ssl
    ssl = yes
    ssl = yes
ssl_cert = </etc/ssl/mail/cert.pem
ssl_cipher_list = ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:!eNULL:!3DES:!MD5:!PSK:!DSS:!RC4:!SEED:!IDEA:+HIGH:+MEDIUM
ssl_dh = # hidden, use -P to show it
ssl_key = # hidden, use -P to show it
ssl_options = no_compression no_ticket
ssl_prefer_server_ciphers = yes

Tante Edit:
Ich hätte natürlich das komplette Workaround machen sollen. Bitte um Entschuldigung.
Ausgabe nun:

root@kn-mc01:/opt/mailcow-dockerized/data/conf/clamav# docker exec $(docker ps -qf name=postfix-mailcow) postconf -h tls_high_cipherlist
/usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 203: overriding earlier entry: message_size_limit=104857600
/usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 214: overriding earlier entry: smtp_tls_protocols=>=TLSv1.2
/usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 218: overriding earlier entry: smtpd_tls_protocols=>=TLSv1.2
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

CK_beats

Postfix log:

08.05.2026, 18:50:51 postfix/smtpd: warning: TLS library problem: error:0A0000C1:SSL routines::no shared cipher:../ssl/statem/statem_srvr.c:2220:
08.05.2026, 18:50:51 postfix/smtpd: SSL_accept error from internet.nl[62.204.66.10]: -1

😂😂😂😂😂
Jetzt ist komplett Ruhe.

Becker884

also jetzt hast du auch 100% ?

CK_beats

Eher 0%. 😂😂😂😂
Ich vermute, da ssl_prefer_server_ciphers = yes aktiviert ist werden serverseitig unsererseits erst einmal keine Cipher-Suites mehr offeriert? 🤔🤔
Keine Ahnung.
SHA-1 ist draußen. Das wird bestätigt. Sonst nichts mehr.
Außerdem bemängelt es immer noch, dass die Zertifikatskette ein abgelaufenes R13 Zertifikat enthält, was definitiv nicht stimmt.

Wenn ich hingegen dieses Tool https://www.checktls.com/TestReceiver nutze,
MTA-STS ebenfalls prüfe, sowie auf die SNI, das Ganze auf IPv4 und -v6 liegen wir bei 100%.
Einzig DANE funktioniert nicht, sowie DNSSEC, da unser DNS-Provider das nicht unterstützt.

Aber:
Serverseitig hat sich in jedem Fall etwas geändert. Unser Scanner konnte den Mailserver nicht mehr kontaktieren. Hier war SSL aktiviert und vermutlich sind nur alte Cipher installiert. Verbindung schlug fehl, was aber zuvor funktionierte.
Müsste hier bei Minolta nach einem Update fragen.
Habe einfach Verschlüsselung komplett deaktiviert. Läuft jetzt plain auf Port 25. Ist aber eh internes Netz, von daher…

Becker884

So schauts bei mir aus

Zuhause entsprechend Punktabzug:

wegen rDNS

CK_beats

So muss es sein!
Dann ist die volle Funktion in Bezug auf Zustellbarkeit & (hoffentlich auch) Sicherheit gegeben!

adamz

My Mailcow installation has a 94% score on the Internet.nl email tests which is great. I’m wondering if a future mailcow update will fix some of the errors that still appear. Or are we on our own? I haven’t learned how to fix them myself yet, but the internet.nl fediverse account sent some tips: https://mastodon.nl/@internet_nl/116563691424080742

Here’s a list of the internet.nl errors with the current July 2026 version of Mailcow:

… TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 insufficient
… TLS_RSA_WITH_CAMELLIA_256_CBC_SHA insufficient
… TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 insufficient
… TLS_RSA_WITH_CAMELLIA_128_CBC_SHA insufficient
… TLS_RSA_WITH_ARIA_256_GCM_SHA384 insufficient
… TLS_RSA_WITH_ARIA_128_GCM_SHA256 insufficient
… TLS_RSA_WITH_AES_256_GCM_SHA384 insufficient
… TLS_RSA_WITH_AES_256_CCM_8 insufficient
… TLS_RSA_WITH_AES_256_CCM insufficient
… TLS_RSA_WITH_AES_256_CBC_SHA256 insufficient
… TLS_RSA_WITH_AES_256_CBC_SHA insufficient
… TLS_RSA_WITH_AES_128_GCM_SHA256 insufficient
… TLS_RSA_WITH_AES_128_CCM_8 insufficient
… TLS_RSA_WITH_AES_128_CCM insufficient
… TLS_RSA_WITH_AES_128_CBC_SHA256 insufficient
… TLS_RSA_WITH_AES_128_CBC_SHA insufficient
… TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA insufficient
… TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA insufficient
… TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA insufficient
… TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA insufficient
… TLS_DHE_RSA_WITH_AES_256_CCM_8 insufficient
… TLS_DHE_RSA_WITH_AES_256_CBC_SHA insufficient
… TLS_DHE_RSA_WITH_AES_128_CCM_8 insufficient
… TLS_DHE_RSA_WITH_AES_128_CBC_SHA insufficient
… TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 phase out
… TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 phase out
… TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 phase out
… TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 phase out
… TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 phase out
… TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 phase out
… TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 phase out
… TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 phase out
… TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 phase out
… TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 phase out
… TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 phase out
… TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 phase out
… TLS_DHE_RSA_WITH_AES_256_CCM phase out
… TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 phase out
… TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 phase out
… TLS_DHE_RSA_WITH_AES_128_CCM phase out
… TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 phase out

Cipher suite order preference is not set to descending order of their security levels:
Cipher suite preferred by server Expected preferred cipher suite
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Mail server supports insufficiently secure parameters for Diffie-Hellman key exchange: DH-2048

Mail server supports one or more insufficiently secure hash functions for key exchange: SHA1

The public key of at least one of your mail server certificates is based on a signing algorithm with parameters that should be phased out as they are weaker:
YR1: RSAPublicKey-2048
… phase out

Mail server domains does not have an active DANE scheme for a reliable rollover of certificate keys.

Becker884

adamz I haven’t learned how to fix them myself yet

look above.

nano /opt/mailcow-dockerized/data/conf/postfix/extra.cf

myhostname = mail.myhostname.com

tls_config_file = /opt/postfix/conf/openssl.cnf
tls_config_name = postfix

tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

smtp_tls_ciphers = high
smtp_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high

The official documentation contains unnecessary duplicate entries:
https://docs.mailcow.email/manual-guides/Postfix/u_e-postfix-harden_ciphers/
=> 98%

For 100% see:
mailcow/mailcow-dockerized7208
and create:

nano /opt/mailcow-dockerized/data/conf/postfix/openssl.cnf

postfix = postfix_settings

[postfix_settings]
ssl_conf = postfix_ssl_settings

[postfix_ssl_settings]
system_default = postfix_tls_defaults

[postfix_tls_defaults]
SignatureAlgorithms = rsa_pss_rsae_sha512:rsa_pss_rsae_sha384:rsa_pss_rsae_sha256:RSA+SHA512:RSA+SHA384:RSA+SHA256:ECDSA+SHA512:ECDSA+SHA384:ECDSA+SHA256

restart postfix

adamz

Becker884
Wow! Thanks so much for the clear and simple consolidated instructions! It worked! Sorry if I was searching the wrong place.

« Previous Page