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
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)
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
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)
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
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)
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
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
Ehemalige
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)
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
Ehemalige
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)
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
Ehemalige
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.
|