Postfix mit relay für gewisse Domains

J

Joshi

New Member
Servus,

ich habe hier einen Ubuntu Mailserver mit Postfix (alles latest LTS). Ich möchte gern den Versand von gewissen Zieldomains an einen SMTP-Relay (z.B.: MailGun oder SendPulse) weitergeben. Im besten Fall sogar dann sogar alles, was im MX-Record auf .mail.protection.outlook.com endet.

Ich habe mich nach diesem Tutorial hier gerichtet, und folgende Einstellungen gemacht:

/etc/postfix/transport
testtennant-com.mail.protection.outlook.com relay:[smtp-pulse.com]:587

/.*@hotmail.*/i relay:[smtp-pulse.com]:587
/.*@outlook.*/i relay:[smtp-pulse.com]:587
/.*@live.*/i relay:[smtp-pulse.com]:587
Click to expand...

/etc/postfix/sasl/sasl_passwd
[smtp-pulse.com]:587 meine.mailadresse@domain.com:randompasswort
Click to expand...

/etc/postfix/main.cf
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
smtp_sasl_security_options = login
smtp_tls_security_level = may
smtp_tls_loglevel = 1
Click to expand...

postmap transport und sasl_passwd hab ich auch ausgeführt, die db-files sind erstellt, der Postfix durchgestartet. postfix check bring auch keine Probleme.
Die main.cf enthält keine doppelten Einträge. Die mail.log bring auch keine Erkenntnisse, alles läuft, die Mails werden (direkt) zugestellt.

Doch egal was ich mache, der SMTP von SendPulse kommt nicht zum tragen. Die Mails werden direkt zugestellt, und es ist halt jetzt auch schon wieder 6h später, ohne Ergebnis :/

Eventuell sehe ich ja auch den Wald vor lauter Bäumen nicht mehr. Wie auch immer, ich wäre sehr dankbar für einen Tip von euch.

LG und Danke
Joshi
 
Auch ohne selbst nachgesehen zu haben, wage ich zu behaupten, dass "smtp-pulse.com" flachs ist...
 
Korrekt. TransportMaps fehlt wahrscheinlich in main.cf, jedenfalls im hier dargestelltem Auszug.
 
Guten Morgen,

danke schonmal für euren Input.

TransportMaps hab ich in der main.cf schon eingetragen, nur vergessen hier zu posten, weils etwas weiter über meinem Block stand:

transport_maps = hash:/etc/postfix/transport
Click to expand...

relayhost ist leer.
 
Ich habs jetzt hinbekommen, mit viel Trial and error, leider aber auch ohne genau zu wissen, warum es nicht funktioniert hat. Bei mir war diese config dann erfolgreich:

/etc/postfix/main.cf
relayhost = [smtp-pulse]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = static:yourusername:yourpass
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
header_size_limit = 4096000
Click to expand...

Vielleicht hilft das ja mal jemandem. Und wenn noch wer einen Hint für mich hat, warum es anders nicht funktionert hat, auch immer gern :)
 
Mit relayhost = [smtp-pulse]:587 gehen aber alle non-local Nachrichten über diesen Relay.

transport_maps = hash:/etc/postfix/transport definiert eine hash table, deine etc/postfix/transport hat aber das Format einer pcre oder regexp table.
 
Das stimmt natürlich. Ich hab dann nicht geschafft, was ich wollte, und hab dann umgeschwenkt auf volles Relay. Das hat dann aber auch nicht so richtig funktionieren wollen, aber so gings dann. Ich lass das jetzt mal so laufen für die nächsten paar Tage, und wenn ich wieder mehr Luft hab, such ich mir mal ein Wochenende raus und spiel mich etwas mit der Config.
 
.A. said:
Mit relayhost = [smtp-pulse]:587 gehen aber alle non-local Nachrichten über diesen Relay.

transport_maps = hash:/etc/postfix/transport definiert eine hash table, deine etc/postfix/transport hat aber das Format einer pcre oder regexp table.
Click to expand...

Da hab ich noch einen alten Teil der Config drinnen gehabt von einem anderen Turorial. Da wäre es so gegangen:

smtpd_recipient_restrictions = check_recipient_mx_access regexp:/etc/postfix/transport
Click to expand...

Es war gestern schon spät und ich war müde aber gestresst, da passieren solche Fehler leider.
 
smtpd_recipient_restrictions = check_recipient_mx_access regexp:/etc/postfix/transport hätte so aber auch nicht funktioniert.

Zunächst erstmal wird schon seit einer Ewigkeit davon abgeraten, in smtpd_recipient_restrictions irgendwelche Relay-spezifischen Einstellungen zwischen zu mixen (https://www.postfix.org/SMTPD_ACCESS_README.html#danger). Und dann wird in dieser Einstellung nur konfiguriert, was Postfix annimmt, nicht aber wie es die Mails wieder los wird (https://www.postfix.org/postconf.5.html#relayhost).

.A.
 
Joshi said:
Vielleicht hilft das ja mal jemandem. Und wenn noch wer einen Hint für mich hat, warum es anders nicht funktionert hat, auch immer gern :)
Click to expand...
Ich weiß jetzt nicht, wie stark Du Deine main.cf anonymisiert hast, aber das stimmt schon mal nicht (.com fehlt):
relayhost = [smtp-pulse]:587
Click to expand...
Zur Transportmap steht im Tutorial:
We can also have the following configuration, which means that emails sent to your own domain are delivered locally. Email sent to gmail.com are delivered normally by performing MX lookup and all other emails are delivered via the relay host.
your-domain.com local
gmail.com smtp
* relay:[smtp-relay.sendinblue.com]:587
Save and close the file. Then run the following command to build the index file.
sudo postmap /etc/postfix/transport
Restart Postfix for the changes to take effect.
sudo systemctl restart postfix
Click to expand...
Hast Du den Eintrag "*" gemacht, hast du die Hash-Map neu erstellt?

Hilfreich wäre der Output von "postconf -n" und natürlich das Mail-Log.
 
Last edited:
Whistler said:
Ist es nicht: https://www.nslookup.io/domains/smtp-pulse.com/dns-records/
Ungewöhnlich, aber technisch korrekt.
Click to expand...
Nope: https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.5
Code: 
Only resolvable, fully-qualified domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are CNAME RRs whose targets can be
   resolved, in turn, to MX or address RRs.  Local nicknames or
   unqualified names MUST NOT be used.
"smtp-pulse.com" ist nunmal kein FQDN und somit technisch nicht erlaubt...
 
Ich kann momentan in den RFCs keine Limitierung eines FQDN auf drei oder mehr Elemente finden.
Ein dig liefert:
Code: 
;; ANSWER SECTION:
smtp-pulse.com.         7200    IN      SOA     a.dns.gandi.net. hostmaster.gandi.net. 1723096697 10800 3600 604800 10800
smtp-pulse.com.         7200    IN      NS      b.dns.gandi.net.
smtp-pulse.com.         7200    IN      NS      c.dns.gandi.net.
smtp-pulse.com.         7200    IN      NS      a.dns.gandi.net.
smtp-pulse.com.         600     IN      MX      10 smtp-pulse.com.
smtp-pulse.com.         600     IN      A       3.75.113.112
smtp-pulse.com.         600     IN      TXT     "v=spf1 include:mxsmtp.sendpulse.com +a +mx ~all"
smtp-pulse.com.         600     IN      TXT     "google-site-verification=3MFOPyxldsOySW-xLfH9HeLVCtfpr5y_qUSF4V77XYc"
"smtp-pulse.com." ist m.E. ein gültiger FQDN, er ist resolvable (3.75.113.112) und antwortet unter der Adresse (auch wenn er per HTTP nur die Ubuntu-Defaultpage ausliefert). Der MX-Record sieht ebenfalls syntaktisch korrekt aus.
mxtoolbox.com bemängelt lediglich fehlendes TLS und DMARC sowie den RDNS (ec2-3-75-113-112.eu-central-1.compute.amazonaws.com).
 
OK, ich finde tatsächlich auf die Schnelle keine offizielle Syntax für FQDN, allerdings bestehen alle bisherigen Referenzen und Beispiele für FQDN aus <label>.<subdomain>.<domain> was eher für meine Ansicht spechen würde.

Hast Du oder irgendjemand eine offizielle Syntax für FQDN?
 
"Offiziell" dürfte RFC 1034 oder einer der Nachfolger sein., dieser wie auch der Wikipedia-Artikel beschreibt die Unterteilung durch Punkte und den abschließenden Punkt. Allerdings wird nur auf die maximale Länge des gesamten Namens (255 Zeichen) und die der einzelnen Elemente (63 Zeichen) eingegangen, nicht aber auf die zulässige Anzahl der einzelnen Elemente.
Trailing dots are required by the standard format for DNS zone files, as well as to disambiguate cases where an FQDN does not contain any other label separators, such as the FQDNs for the root zone itself and any top-level domain.
Click to expand...
Diesen Satz interpretiere ich so, daß sogar "com." ein FQDN wäre, der Punkt unterscheidet ihn von einem relativen "com".
 
Whistler said:
"Offiziell" dürfte RFC 1034 oder einer der Nachfolger sein., dieser wie auch der Wikipedia-Artikel beschreibt die Unterteilung durch Punkte und den abschließenden Punkt. Allerdings wird nur auf die maximale Länge des gesamten Namens (255 Zeichen) und die der einzelnen Elemente (63 Zeichen) eingegangen, nicht aber auf die zulässige Anzahl der einzelnen Elemente.

Diesen Satz interpretiere ich so, daß sogar "com." ein FQDN wäre, der Punkt unterscheidet ihn von einem relativen "com".
Click to expand...
Ja, aber die ICANN hat es schon länger "discouraged" und bei neueren TLD's verboten.
Ganz seltene Registries trotzen dieser Regelung noch, siehe http://ai./

Technisch gesehen ist eine TLD eine Subdomain der Root-Zone.
 
You must log in or register to reply here.
Back
Top