Folgende Konfiguration bisher:
Ich habe mehrere kleine lokale HTTP-Dienste laufen.
Um auch von außerhalb darauf zuzugreifen habe ich einen nginx Reverse Proxy laufen welcher diesen Diensten noch SSL(TLS) hinzufügt, so dass diese nur per HTTPS zu erreichen sind (Zertifikat von letsencrypt). Dazu kommt noch eine HTTP-Authentification. Läuft wunderbar.

Nun jedoch habe ich auch noch einen lokalen Mail-Server (davmail). Dieser läuft ohne verschlüsselten Zugriff.
Was ich nun eigentlich möchte ist, dass dieser Mailserver genauso wie die HTTP-Dienste über den nginx-Reverse-Proxy von außerhalb zu erreichen ist und der Reverse-Proxy den Zugriff hierauf noch mit SSL/TLS "anreichert".

Folgendes ist mein letzter wesentlicher Konfigurationsstand:[code][...]

mail {
server_name my.domain.com;

ssl on;
ssl_certificate /etc/letsencrypt/live/my.domain.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/my.domain.com/privkey.pem; # managed by Certbot
ssl_trusted_certificate /etc/letsencrypt/live/my.domain.com/fullchain.pem;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;

# IMAP reverse-proxy
# should listen to 993 and serve the imap-data from 192.168.0.6 with transport encryption
server {
listen 993 ssl;
protocol imap;
proxy on;

# dummy authentification (see http-block below)
auth_http localhost:8008/auth-imap;
}
}

http {
[...]

# dummy authentification server
server {
listen 8008;
server_name localhost;

location /auth-imap {
add_header Auth-Status OK;
add_header Auth-Server 192.168.0.6; # backend ip
add_header Auth-Port 1143; # backend port
return 204;
}
}


# example http ssl encryption proxy server
server {
server_name my.domain.com;
listen 443 ssl http2; # managed by Certbot
listen [::]:443 ssl http2;
ssl_certificate /etc/letsencrypt/live/my.domain.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/my.domain.com/privkey.pem; # managed by Certbot
ssl_trusted_certificate /etc/letsencrypt/live/my.domain.com/fullchain.pem;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

[...]

location /example {
proxy_pass http://192.168.0.99/admin;
proxy_buffering off;
}
}

}[/code]
Leider schaffe ich es nicht von einem Mailprogramm mit dieser Konfiguration die Mails abzufragen.
Für Tipps zu meinen Denkfehlern und wie ich es richtig machen muss wäre ich sehr dankbar.

Moin,

da mir diese "Pseudo-Auth"-Geschichte nicht geschmeckt hat, sieht meine Config jetzt so aus:

stream {
server {
listen [::]:143 ipv6only=off;
listen [::]:25 ipv6only=off;
listen [::]:587 ipv6only=off;
listen [::]:993 ipv6only=off;
proxy_pass 10.23.102.251:$server_port;
proxy_protocol on;
}
}

Damit übergibt nginx die Daten 1:1 an den Mailserver. Verschlüsselung und Userauthentifizierung übernimmt der Mailserver. Beim Mailserver ist dann noch wichtig, das er weiß, dass da ein Proxy dazwischen ist, sonst prüft er die White-/Blacklist gegen die IP des nginx-Servers! (Bei Postfix in der main.cf: postscreen_upstream_proxy_protocol= haproxy)

Gruß / Greetz
Florian

Hey ich versuche auch einen email proxy mit nginx zu realisieren.

Mein Test-Setup läuft unter localhost: imap 993, smtp 465, der proxy hört auf imap 1993 und smtp 1465.

Über den Stream-Context hat es auch geklappt, ich habe allerdings noch die Zusatzanforderung, ein sub-domain routing zu realisieren.
Der email server soll also (erstmal testweise) über domain.localhost:1993/1465 zu erreichen sein. Später brauche ich etwas wie: userid.domain.com:993/465.
Da das Stream-Modul auf TCP-Ebene ansetzt, fällt die Option eine Subdomain zu nutzen leider weg.

Aus diesem Grund versuche ich vergeblich den nginx mail proxy zum laufen zu bekommen, da man hier wohl ein Subdomain-Präfix als Servername mit angeben kann.

Irgendwas scheint aber an der Konfiguration noch nicht zu stimmen, ich habe mich eigentlich strikt an das nginx Tutorial gehalten. Hier mal meine config:

mail {
server_name localhost;

proxy on;
proxy_pass_error_message on;

server {
listen 1993 ssl;
protocol imap;
auth_http localhost:993;

ssl_certificate .../cert.pem;
ssl_certificate_key .../key.pem;

#server_name domain.localhost;
}

server {
listen 1465 ssl;
protocol smtp;
auth_http localhost:465;

ssl_certificate .../cert.pem;
ssl_certificate_key .../key.pem;

#server_name domain.localhost;
}
}

Auskommentiert sieht man schon die gewünschten server-names.

Als Auth-Http habe ich mal den echten mail-server angegeben, dieses Mock-Example (return von auth-status, auth-server und auth-port) schien gar nichts zu bringen.

Wenn ich die Konfiguration des Mail-Clients (Thunderbird) abschließen will, bekomme ich auch einen error log im mail-server also scheint die Verbindung irgendwie hergestellt:
time="2019-05-28T16:48:03+02:00" level=info msg="cannot read command: tls: first record does not look like a TLS handshake" addr="localhost:993" task="IMAP Server"

Der Fehlermeldung lässt sich entnehmen, dass es irgendwie mit SSL/TLS zu tun hat. Es gibt wohl ein problem beim TLS handshake.

Das SSL Zertifikat habe ich selbst erstellt, mit "localhost" als "common" und "subject alternative name", ich habe auch schon ein Zertifikat mit "127.0.0.1" versucht.
Die Zertifikate sind in meinem System als vertrauenswürdig eingestuft und ich habe in Thunderbird auch eine entsprechende Ausnahme hinterlegt.

Auch die Benutzung desselben Zertifikats auf Mailservers und Proxy hat keine Verbesserung gebracht.
Mit Wireshark komme ich auch nicht so recht weiter - ich bin etwas am Ende.
Weiß jemand vielleicht Rat?