ubuntuusers.de

Postfix relay

Status: Ungelöst | Ubuntu-Version: Ubuntu 16.04 (Xenial Xerus)
Antworten |

VolkerRaschek

Avatar von VolkerRaschek

Anmeldungsdatum:
19. August 2014

Beiträge: Zähle...

Wohnort: Eifel

Hallo zusammen, ich versuche auf meinem Server Mails einer Domain zu relayen.

Ziel ist es, dass mein Server für die Domain "mmoje.de" als Backup MX-Server dient. Dazu habe ich folgende Einstellungen in Postfix gesetzt.

/etc/postfix/main.cf

# Relay-Domains
#  Hier werden alle Relay-Domains gelistet für die Postfix stellvertretend E-Mails annimmt.
relay_domains                           = btree:/etc/postfix/relay/relay_domain_maps
#                                         mysql:/etc/postfix/mysql/mysql-relay-domains.cf

# Relay-Recipients
#  Hier wenden alle Relay-Postfächer gelistet für die Postfix als Relay dienen soll.
relay_recipient_maps                    = btree:/etc/postfix/relay/relay_recipient_maps
#                                         mysql:/etc/postfix/mysql/mysql-relay-recipient-maps.cf

# Relay-Transport
relay_transport                         = btree:/etc/postfix/relay/relay_transport
#                                         mysql:/etc/postfix/mysql/mysql-relay-transport.cf

/etc/postfix/relay/relay_transport

mmoje.de                        smtp:mail.mmoje.de:587

/etc/postfix/relay/relay_recipient_maps

@mmoje.de                       x

/etc/postfix/relay/relay_domain_maps

mmoje.de                        x

Wenn ich nun von meinem Server eine Mail an max.mustermann@mmoje.de schicke, erhalte ich folgende Meldung im syslog.

Nov 14 16:08:36 kronos postfix/qmgr[3925]: warning: connect to transport private/btree: No such file or directory
Nov 14 16:08:36 kronos postfix/error[3941]: 534D34E08E7: to=<max.mustermann@mmoje.de>, relay=none, delay=0.27, delays
ransport unavailable)

Was habe ich falsch eingestellt?

Viele Grüße
Volker

Doc_Symbiosis

Avatar von Doc_Symbiosis

Anmeldungsdatum:
11. Oktober 2006

Beiträge: 4450

Wohnort: Göttingen

Hast Du nach dem Editieren der Dateien denn auch ein entsprechendes Postmap-Kommando abgesetzt? Sprich z.B.

postmap /etc/postfix/relay/relay_transport

VolkerRaschek

(Themenstarter)
Avatar von VolkerRaschek

Anmeldungsdatum:
19. August 2014

Beiträge: 358

Wohnort: Eifel

Doc_Symbiosis schrieb:

Hast Du nach dem Editieren der Dateien denn auch ein entsprechendes Postmap-Kommando abgesetzt? Sprich z.B.

postmap /etc/postfix/relay/relay_transport

Ja das habe ich, ich habe es auch schon mal hiermit probiert

postmap btree:/etc/postfix/relay/relay_transport

Da bekomme ich die gleichen Fehler.

Doc_Symbiosis

Avatar von Doc_Symbiosis

Anmeldungsdatum:
11. Oktober 2006

Beiträge: 4450

Wohnort: Göttingen

Hm, die syslog Meldung ist irgendwie nicht so ganz vollständig. Bei uns auf dem Postfix sind die Einträge der transport in Klammern gesetzt, also so z.B.

smtp:[mail.mmoje.de]:587

VolkerRaschek

(Themenstarter)
Avatar von VolkerRaschek

Anmeldungsdatum:
19. August 2014

Beiträge: 358

Wohnort: Eifel

Doc_Symbiosis schrieb:

Hm, die syslog Meldung ist irgendwie nicht so ganz vollständig. Bei uns auf dem Postfix sind die Einträge der transport in Klammern gesetzt, also so z.B.

smtp:[mail.mmoje.de]:587

Also ich habe es mal in Klammern gesetzt. Das scheint unter relay_transport nicht zu funktionieren. Ich habe es jetzt mal in transport_maps definiert.

main.cf

# Transport-Maps
#  Definiert einen Grundsätzlichen Transportweg für Mails auf Basis verschiedener Protokolle um Mail-Server zu erreichen, die nicht per DNS definiert sind.
transport_maps                          = btree:/etc/postfix/transport/transport_maps

btree:/etc/postfix/transport/transport_maps

mmoje.de smtp:[mail.mmoje.de]:587

Da sieht es so aus, als ob ich einen Schritt weiter wäre. Er versucht glaube ich die Mail zu zustellen aber bekommt immer ein Access Denied.

Nov 14 17:50:10 kronos postfix/smtp[6215]: A82314E076F: to=<markus.pesch@mmoje.de>, relay=mail.mmoje.de[46.38.242.163]:587, delay=0.93, delays=0.04/0.01/0.7/0.18, dsn=5.7.1, status=bounced (host mail.mmoje.de[46.38.242.163] said: 554 5.7.1 <p578aoo92.dip0.t-ipconnect.de[88.148.191.145]>: Client host rejected: Access denied (in reply to RCPT TO command))

Doc_Symbiosis

Avatar von Doc_Symbiosis

Anmeldungsdatum:
11. Oktober 2006

Beiträge: 4450

Wohnort: Göttingen

Was sagen denn folgende Kommandos?

postconf smtpd_client_restrictions
postconf smtpd_relay_restrictions

Ich würde mal behaupten, dass der Mailserver die Mails nicht animmt, weil da eine Restiction gesetzt ist, die das verhindert. Kenne mich aber leider auchnicht so super mit Postfix aus...

VolkerRaschek

(Themenstarter)
Avatar von VolkerRaschek

Anmeldungsdatum:
19. August 2014

Beiträge: 358

Wohnort: Eifel

Doc_Symbiosis schrieb:

Was sagen denn folgende Kommandos?

postconf smtpd_client_restrictions
postconf smtpd_relay_restrictions

Auf meinem Backup-Server sehen die wie folgt aus.

root@kronos:~# postconf smtpd_client_restrictions
smtpd_client_restrictions = reject_unauth_pipelining, reject_rbl_client zen.spamhaus.org, permit
root@kronos:~# postconf smtpd_relay_restrictions
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

Auf dem Hauptserver kann ich momentan nicht zugreifen.

Doc_Symbiosis

Avatar von Doc_Symbiosis

Anmeldungsdatum:
11. Oktober 2006

Beiträge: 4450

Wohnort: Göttingen

Hm, mache die beiden vielleicht mal kurz leer und probiere es nochmal. Dann wiesst Du wenigstens, ob es daran liegt...

misterunknown Team-Icon

Ehemalige
Avatar von misterunknown

Anmeldungsdatum:
28. Oktober 2009

Beiträge: 4403

Wohnort: Sachsen

VolkerRaschek schrieb:

Ziel ist es, dass mein Server für die Domain "mmoje.de" als Backup MX-Server dient. Dazu habe ich folgende Einstellungen in Postfix gesetzt.

Ok.

relay_transport                         = btree:/etc/postfix/relay/relay_transport

Ich glaube Transport-Tables unterstützen btree nicht. Dort solltest du einfach eine Textdatei mit den entsprechenden Optionen angeben. Siehe auch. Diese Option kannst du aber auch getrost weglassen. Die Default-Einstellung ist, dass Postfix nachschaut, welcher Mailserver für diese Domain eigentlich zuständig ist (MX-Record der Domain) und sie dann versucht dahin zuzustellen. Falls du also hier auch nur die Default-Einstellungen drin hast, kannst du das weglassen.

/etc/postfix/relay/relay_recipient_maps

@mmoje.de                       x

Wenn du eh eine Wildcard-Weiterleitung machst, kannst du die Option auch weglassen. Das ist Standardverhalten.

Da sieht es so aus, als ob ich einen Schritt weiter wäre. Er versucht glaube ich die Mail zu zustellen aber bekommt immer ein Access Denied.

Nov 14 17:50:10 kronos postfix/smtp[6215]: A82314E076F: to=<markus.pesch@mmoje.de>, relay=mail.mmoje.de[46.38.242.163]:587, delay=0.93, delays=0.04/0.01/0.7/0.18, dsn=5.7.1, status=bounced (host mail.mmoje.de[46.38.242.163] said: 554 5.7.1 <p578aoo92.dip0.t-ipconnect.de[88.148.191.145]>: Client host rejected: Access denied (in reply to RCPT TO command))

Dann nimmt der Haupt-Mailserver für mmoje.de scheinbar noch keine Mails vom Backup-MX an. Am einfachsten ist es, wenn du den Backup-MX auf dem Haupt-MX whitelistest. Bei mir sieht das so aus:

/etc/postfix/main.cf:
    smtpd_recipient_restrictions = ... check_client_access hash:/etc/postfix/whitelist ...

/etc/postfix/whitelist:
    1.2.3.4  OK

VolkerRaschek

(Themenstarter)
Avatar von VolkerRaschek

Anmeldungsdatum:
19. August 2014

Beiträge: 358

Wohnort: Eifel

misterunknown schrieb:

Ich glaube Transport-Tables unterstützen btree nicht.

Okay das werde ich ausprobieren.

Die Default-Einstellung ist, dass Postfix nachschaut, welcher Mailserver für diese Domain eigentlich zuständig ist (MX-Record der Domain) und sie dann versucht dahin zuzustellen. Falls du also hier auch nur die Default-Einstellungen drin hast, kannst du das weglassen.

Was ist denn nun, wenn ich als Backup MX diene. Also MX 10 wäre der Primäre Server und MX 20 wäre mein Server. Da der MX 10 jetzt down ist, würde mein Server doch im Deadlock hängen da er immer auf sich selber zweigt oder etwa nicht?

Wenn du eh eine Wildcard-Weiterleitung machst, kannst du die Option auch weglassen. Das ist Standardverhalten.

Ok

Dann nimmt der Haupt-Mailserver für mmoje.de scheinbar noch keine Mails vom Backup-MX an. Am einfachsten ist es, wenn du den Backup-MX auf dem Haupt-MX whitelistest. Bei mir sieht das so aus:

/etc/postfix/main.cf:
    smtpd_recipient_restrictions = ... check_client_access hash:/etc/postfix/whitelist ...

/etc/postfix/whitelist:
    1.2.3.4  OK

Okay, damit kann ich was anfangen, doch habe ich gelesen das es dafür die Option permit_mx_backup_networks gibt und man diese in den restictions hinzufügt.

# IP-Adresse/n von Backup MX-Servern
permit_mx_backup_networks               = 1.2.3.4/32

smtpd_recipient_restrictions            =
                                        # Keine unsauberen Mails annehmen!
                                                reject_non_fqdn_hostname,
                                                reject_non_fqdn_sender,
                                                reject_non_fqdn_recipient,
                                                reject_unknown_sender_domain,
                                                reject_unknown_recipient_domain,
                                                reject_invalid_hostname,
                                        # Unsere Benutzer erlauben!
                                                permit_sasl_authenticated,
                                        # Meine Netzwerke erlauben!
                                                permit_mynetworks,
                                        # MX-Backup-Server erlauben!
                                                permit_mx_backup,
                                        # Alles andere Relaying verbieten
                                                reject_unauth_destination,
                                        # SPF Sicherheit
                                                check_policy_service            unix:private/policy-spf
                                        # Dynamische Empfängervalidierung
                                                reject_unverified_recipient,
                                        # RBL Checken
                                        #  Blacklistanbieter mit Blacklist von Servern von denen Spam verschickt wird.
                                        #  zen.spamhaus.org funktioniert nicht mit GoogleDNS, daher DNS ändern!
                                                reject_rbl_client               zen.spamhaus.org,
                                                reject_rbl_client               ix.dnsbl.manitu.net,
                                        # Quota-Status des Users auf dem IMAP-Server prüfen
                                                check_policy_service            inet:localhost:12340,
                                        # Was übrig bleibt darf durch
                                                permit

Geht das auch?

Gruß
Volker

misterunknown Team-Icon

Ehemalige
Avatar von misterunknown

Anmeldungsdatum:
28. Oktober 2009

Beiträge: 4403

Wohnort: Sachsen

VolkerRaschek schrieb:

Was ist denn nun, wenn ich als Backuo MX diene. Also MX 10 wäre der Primäre Server und MX 20 wäre mein Server. Da der MX 10 jetzt down ist, würde mein Server doch im Deadlock hängen da er immer auf sich selber zweit oder etwa nicht?

Nein, er würde versuchen an den primären MX zuzustellen. Wenn das nicht geht, schiebt er die Mail in die Queue. Danach probiert er es immer wieder, bis die maximal_queue_lifetime abgelaufen ist. Diese steht per Default auf 5 Tagen. Das ist auch die Empfehlung im RFC.

Du könntest die Mail theoretisch auch in ein lokales Postfach zustellen und dieses per imapsync mit dem primären IMAP-Server synchronisieren, allerdings würde die Mail dann jede weitere Überprüfung durch den primären MX (Spam- oder Virenfilter) umgehen. Auch Sieve-Skripte würden IMHO nicht ausgeführt.

Okay, damit kann ich was anfangen, doch habe ich gelesen das es dafür die Option permit_mx_backup_networks gibt und man diese in den restictions hinzufügt.

Durchaus, das ist sicherlich die saubere Variante. Meine Postfix-Konfiguration ist auch erst gewachsen^^

VolkerRaschek

(Themenstarter)
Avatar von VolkerRaschek

Anmeldungsdatum:
19. August 2014

Beiträge: 358

Wohnort: Eifel

misterunknown schrieb:

Nein, er würde versuchen an den primären MX zuzustellen. Wenn das nicht geht, schiebt er die Mail in die Queue. Danach probiert er es immer wieder, bis die maximal_queue_lifetime abgelaufen ist. Diese steht per Default auf 5 Tagen. Das ist auch die Empfehlung im RFC.

Das ist sehr gut! Ich habe die maximal_queue_lifetime auf 5 Tagen stehen.

Du könntest die Mail theoretisch auch in ein lokales Postfach zustellen und dieses per imapsync mit dem primären IMAP-Server synchronisieren, allerdings würde die Mail dann jede weitere Überprüfung durch den primären MX (Spam- oder Virenfilter) umgehen. Auch Sieve-Skripte würden IMHO nicht ausgeführt.

Der Tipp hört sich nicht schlecht an, doch wenn 5 Tage vorbei sind, sind sie vorbei.

Ich habe allerdings immer noch das Problem mit den zwei transport methoden transport_maps und relay_transport

Hier mal mein Ausschnitt aus der main.cf

# Relay-Transport
relay_transport                         = mysql:/etc/postfix/mysql/mysql-relay-transport.cf

# Transport-Maps
#  Definiert einen Grundsätzlichen Transportweg für Mails auf Basis verschiedener Protokolle um Mail-Server zu erreichen, die nicht per DNS definiert sind.
transport_maps                          = $relay_transport

Hier mein mysql-relay_transport.cf

hosts           = 127.0.0.1
user            = <Benutzer>
password        = <Passwort>
dbname          = <Datenbank>
query 		= SELECT CONCAT(d.domain, CONCAT(' ',CONCAT('smtp:[', CONCAT('%d',']')))) FROM domain d WHERE d.domain='%d' AND d.active='1' AND d.transport='relay'

Ich erhalte immer die folgende Fehlermeldung bzw. Warnung im Log

Nov 17 23:33:20 kronos postfix/qmgr[5532]: warning: connect to transport private/mmoje.de smtp: No such file or directory

Stehe ich da auf dem Schlauch? Ich kann den Fehler nicht erkennen bzw. warum er meckert.

misterunknown Team-Icon

Ehemalige
Avatar von misterunknown

Anmeldungsdatum:
28. Oktober 2009

Beiträge: 4403

Wohnort: Sachsen

VolkerRaschek schrieb:

Ich habe allerdings immer noch das Problem mit den zwei transport methoden transport_maps und relay_transport

Hier mal mein Ausschnitt aus der main.cf

# Relay-Transport
relay_transport                         = mysql:/etc/postfix/mysql/mysql-relay-transport.cf

# Transport-Maps
#  Definiert einen Grundsätzlichen Transportweg für Mails auf Basis verschiedener Protokolle um Mail-Server zu erreichen, die nicht per DNS definiert sind.
transport_maps                          = $relay_transport

Hier mein mysql-relay_transport.cf

hosts           = 127.0.0.1
user            = <Benutzer>
password        = <Passwort>
dbname          = <Datenbank>
query 		= SELECT CONCAT(d.domain, CONCAT(' ',CONCAT('smtp:[', CONCAT('%d',']')))) FROM domain d WHERE d.domain='%d' AND d.active='1' AND d.transport='relay'

Ich erhalte immer die folgende Fehlermeldung bzw. Warnung im Log

Nov 17 23:33:20 kronos postfix/qmgr[5532]: warning: connect to transport private/mmoje.de smtp: No such file or directory

Stehe ich da auf dem Schlauch? Ich kann den Fehler nicht erkennen bzw. warum er meckert.

Das Problem ist meines Erachtens, dass relay_transport keine Lookup-Table unterstützt, sondern direkt einen String erwartet, der den Next-Hop definiert. Siehe auch hier. Wenn du eine Lookup-Table definieren willst, die den Transport regelt, dann musst du direkt transport_maps nutzen. Im Eintrag für relay_transport steht auch, dass es durch transport(5) überschrieben werden kann.

relay_transport ist also eher etwas für lokale Mailserver, die alle Emails über ein bestimmtes Relay rausschicken sollen. Ein Beispiel wäre eine Firma, deren Abteilungen separate Mailserver benutzen, externe Mails jedoch alle über ein zentrales Gateway (Smarthost) schicken sollen.

Antworten |