[pfx] Re: non_smtpd relayhost ?
On Fri, Jun 21, 2024 at 16:22:24 -0400, Wietse Venema wrote: > Locally-generated bounces are generated by the Postfix bounce > daemon which talks to a cleanup service to queue a message. > One could run bounce daemons with a cleanup_service override > in master.cf: Thanks Wietse, that makes sense. I'll try your approach. Geert ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: non_smtpd relayhost ?
Geert Hendrickx via Postfix-users:
> Hi
>
> We have few different sets of Postfix mailservers with different roles;
> inbound servers, outbound servers that DKIM sign outgoing mail with a
> milter, and some other servers that just relay mail that is already signed
> elsewhere.
>
> The first and third types of mailservers don't need to sign mail passing
> through them, but we are looking for a way to sign their locally generated
> mail (bounces or DSN's), preferably without having to setup and maintain
> DKIM milters (and corresponding private keys) on all those servers.
So you're looking at setting up a host that will sign bounces that were
generated on those machines and not elsewhere.
And "those machines" could be back-end hosts that deliver to a
message store.
Fortunately, there is a way to distinguish between locally- and
remotely-generated bounces.
Locally-generated bounces are generated by the Postfix bounce daemon
which talks to a cleanup service to queue a message. One could run
bounce daemons with a cleanup_service override in master.cf:
(Postfix 3.0 long parameter syntax)
bounce ... ... ... ... ... ... ... bounce
-o { cleanup_service = ndr-cleanup }
defer ... ... ... ... ... ... ... bounce
-o { cleanup_service = ndr-cleanup }
trace ... ... ... ... ... ... ... bounce
-o { cleanup_service = ndr-cleanup }
This approach is reatively safe, because it is unlikely to clash
with bounce parameter settings in main.cf. Such main.cf settings
are extremely rare.
To queue the messages, configure a clone of the cleanup service
with a content_filter override that forces delivery to an ndr-signer
host.
ndr-cleanup ... ... ... ... ... ... ... cleanup
-o {content_filter = smtp:[ndr-signer] }
This approach may conflict with main.cf parameters that target the
"normal" cleanup service. If that is the case then you can override
the conflicting main.cf setting with a ndr-cleanup master.cf override
for that parameter.
A long list is at https://www.postfix.org/cleanup.8.html.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] non_smtpd relayhost ?
Hi We have few different sets of Postfix mailservers with different roles; inbound servers, outbound servers that DKIM sign outgoing mail with a milter, and some other servers that just relay mail that is already signed elsewhere. The first and third types of mailservers don't need to sign mail passing through them, but we are looking for a way to sign their locally generated mail (bounces or DSN's), preferably without having to setup and maintain DKIM milters (and corresponding private keys) on all those servers. Is there a way to make Postfix relay locally-generated mail to a specific relayhost (one that DKIM signs outbound e-mail), without impacting regular mail routing? Similar to non_smtpd_milters for locally generated mail? (a sender_dependent_relayhost_maps override for empty senders won't do, as such mail could come in via smtpd as well, and shouldn't be signed.) Geert ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: configure a relayhost
On Mon, Sep 11, 2023 at 09:59:55AM +0200, François Patte via Postfix-users wrote: > > If you continue to treat the hostname of your ISP's (FAI's) SMTP relay > > as restricted sensitive information, the help you'll receive will also > > be restricted to vague generalities. > > My new main.cf : > > relayhost = [smtp.gmx.com]:465 That's much better, thanks. Given comments below, secure connections to this server under the name "mail.gmx.com" (that's the only DNS SAN in the certificate) pass certificate verification at the "secure" level, as demonstrated below: $ posttls-finger -w -lsecure -F /etc/ssl/cert.pem "[mail.gmx.com]:465" posttls-finger: mail.gmx.com[212.227.17.184]:465: matched peername: mail.gmx.com posttls-finger: mail.gmx.com[212.227.17.184]:465: subject_CN=mail.gmx.com, issuer=GeoTrust TLS RSA CA G1, cert fingerprint=76:81:79:C2:6A:B1:1D:F8:EE:81:69:36:EA:9D:0C:4C:B0:F3:8F:22:8F:48:D7:7C:63:BF:22:0F:60:F4:60:9D, pkey fingerprint=4C:23:2B:C8:10:CC:0C:F4:9B:77:78:FE:4E:00:32:2F:1D:B8:CB:33:09:72:9A:2A:55:92:E1:57:F7:DA:8F:F8 posttls-finger: Verified TLS connection established to mail.gmx.com[212.227.17.184]:465: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 You'll need to change the "relayhost" setting to: relayhost = [mail.gmx.com]:465 which, if performed correctly, will resolve the "name mismatch errors" you reported. > smtp_sasl_auth_enable = yes > smtp_sasl_mechanism_filter = plain, login > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd > smtp_sasl_security_options = > smtp_sasl_tls_security_options = noanonymous > smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt > smtp_tls_CApath = /etc/pki/tls/certs > smtp_tls_loglevel = 1 > smtp_tls_secure_cert_match = smtp.gmx.com But, of course, you'll also need to change the above. Most robust choice is to just use the special "strategy": smtp_tls_secure_cert_match = nexthop as documented in postconf(5) under "smtp_tls_verify_cert_match" and "smtp_tls_secure_cert_match". > smtp_tls_security_level = encrypt And then change this to "secure" (in fact, "verify" is equivalent, when the relay is enclosed in "[]", which avoids MX lookups, or the match criteria do not include "hostname"). > smtp_tls_verify_cert_match = pingala.fqdn This is nonsense. The SMTP client is matching *remote* hostnames in their presented certificates, this should be the *same* as the "smtp_tls_secure_cert_match" parameter above: smtp_tls_verify_cert_match = nexthop > smtpd_tls_CApath = /etc/pki/tls/certs You don't need this. Your server does not request client certificates, so the CA file and path are pointless for "smtpd". Delete this setting from main.cf. > smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem > smtpd_tls_key_file = /etc/pki/tls/private/postfix.key > smtpd_tls_req_ccert = Also delete this, which defaults to "no". > unknown_local_recipient_reject_code = 550 > > And updated the security level to "secure". > > If I turn this to "secure", I get in maillog file: > > server certificate verification failed for > smtp.gmx.com[212.227.17.174]:465: num=62:hostname mismatch See above. > > > > > smtpd_tls_security_level = encrypt > > > > > > > > Nor this, except on the submission services in master.cf. > > Suppressed (I don't understand : "except on the submission services in > master.cf" I did not change anything in master.cf) You would change master.cf, if you wanted to support SMTP submission over TLS with SASL. Otherwise, you don't need these at all. > > And turn off SASL AUTH on your inbound port 25. > > I don't understand this... In main.cf, don't leave "smtpd_sasl_auth_enable" at its default "no" setting (by not mentioning it in main.cf). > > returns the expected result. (The "cat -etv" should highlight > > any unexpected invisible characters). > > I made an error in password_maps : the relayhost wanted my full email > address as my user name. Corrected. You're almost done. All that remains is fixing the server name settings, and setting the security level to "secure" (or "verify"). > > Is your server supposed to receive any mail from outside? Or > > is it a "send-only" server? > > A "send-only" server. Not much point in SASL for a server that only accepts mail on the loopback interface. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: configure a relayhost
On 11/09/23 19:59, François Patte via Postfix-users wrote: And updated the security level to "secure". If I turn this to "secure", I get in maillog file: server certificate verification failed for smtp.gmx.com[212.227.17.174]:465: num=62:hostname mismatch Le 11/09/2023 à 13:33, Peter via Postfix-users a écrit : The cert is signed for mail.gmx.com, either change the relayhost setting to reflect this or create a new cert that also includes smtp.gmx.com. On 11.09.23 14:23, François Patte via Postfix-users wrote: Changing the relayhost does not change the behavior: turning security level to "secure" complain is always: server certificate verification failed for mail.gmx.com[212.227.17.184]:465: num=62:hostname mismatch looks you have misconfigured smtp_tls_verify_cert_match: smtp_tls_verify_cert_match = pingala.fqdn http://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_match perhaps unset it and try if the default work. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: configure a relayhost
Le 11/09/2023 à 14:23, Matus UHLAR - fantomas via Postfix-users a écrit : And updated the security level to "secure". On 11/09/23 19:59, François Patte via Postfix-users wrote: If I turn this to "secure", I get in maillog file: server certificate verification failed for smtp.gmx.com[212.227.17.174]:465: num=62:hostname mismatch On 11.09.23 23:33, Peter via Postfix-users wrote: The cert is signed for mail.gmx.com, either change the relayhost setting to reflect this or create a new cert that also includes smtp.gmx.com. since I assume you con't control that server, you need to change relayhost to [mail.gmx.com]:465 and then change server name in /etc/postfix/sasl_passwd into [mail.gmx.com]:465 As I just replied to Peter, this change does"nt change anything Of course I changed the sasl_passwd too! F.P. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: configure a relayhost
Le 11/09/2023 à 13:33, Peter via Postfix-users a écrit : On 11/09/23 19:59, François Patte via Postfix-users wrote: And updated the security level to "secure". If I turn this to "secure", I get in maillog file: server certificate verification failed for smtp.gmx.com[212.227.17.174]:465: num=62:hostname mismatch The cert is signed for mail.gmx.com, either change the relayhost setting to reflect this or create a new cert that also includes smtp.gmx.com. Changing the relayhost does not change the behavior: turning security level to "secure" complain is always: server certificate verification failed for mail.gmx.com[212.227.17.184]:465: num=62:hostname mismatch F.P. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: configure a relayhost
And updated the security level to "secure". On 11/09/23 19:59, François Patte via Postfix-users wrote: If I turn this to "secure", I get in maillog file: server certificate verification failed for smtp.gmx.com[212.227.17.174]:465: num=62:hostname mismatch On 11.09.23 23:33, Peter via Postfix-users wrote: The cert is signed for mail.gmx.com, either change the relayhost setting to reflect this or create a new cert that also includes smtp.gmx.com. since I assume you con't control that server, you need to change relayhost to [mail.gmx.com]:465 and then change server name in /etc/postfix/sasl_passwd into [mail.gmx.com]:465 -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. On the other hand, you have different fingers. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: configure a relayhost
On 11/09/23 19:59, François Patte via Postfix-users wrote: And updated the security level to "secure". If I turn this to "secure", I get in maillog file: server certificate verification failed for smtp.gmx.com[212.227.17.174]:465: num=62:hostname mismatch The cert is signed for mail.gmx.com, either change the relayhost setting to reflect this or create a new cert that also includes smtp.gmx.com. Peter ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: configure a relayhost
Le 10/09/2023 à 18:23, Viktor Dukhovni via Postfix-users a écrit : On Sun, Sep 10, 2023 at 10:38:27AM +0200, François Patte via Postfix-users wrote: Sep 9 16:50:49 myserver postfix/smtp[205832]: 92BEFB4BEA: to=, relay=my-fai-smtp[x.x.x.x]:465, delay=0.22, delays=0.04/0.08/0.08/0.02, dsn=5.0.0, status=bounced (host my-fai-smtps[x.x.x.x] said: 530 Authentication required (in reply to MAIL FROM command)) https://www.postfix.org/DEBUG_README.html#mail It looks like you "tampered" with the logs. They don't match your reported configuration below. If you continue to treat the hostname of your ISP's (FAI's) SMTP relay as restricted sensitive information, the help you'll receive will also be restricted to vague generalities. My new main.cf : alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin compatibility_level = 3.7 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 html_directory = no inet_interfaces = localhost inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man meta_directory = /etc/postfix mydestination = myhostname = pingala.fqdn newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix/README_FILES relayhost = [smtp.gmx.com]:465 sample_directory = /usr/share/doc/postfix/samples sender_canonical_maps = sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop shlib_directory = /usr/lib64/postfix smtp_generic_maps = hash:/etc/postfix/generic smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = plain, login smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = smtp_sasl_tls_security_options = noanonymous smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt smtp_tls_CApath = /etc/pki/tls/certs smtp_tls_loglevel = 1 smtp_tls_secure_cert_match = smtp.gmx.com smtp_tls_security_level = encrypt smtp_tls_verify_cert_match = pingala.fqdn smtp_tls_wrappermode = yes smtpd_tls_CApath = /etc/pki/tls/certs smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem smtpd_tls_key_file = /etc/pki/tls/private/postfix.key smtpd_tls_req_ccert = unknown_local_recipient_reject_code = 550 smtp_enforce_tls = yes smtp_use_tls = yes These are obsolete and redundant. You should have by now removed these settings from "main.cf" (so that these parameters no longer appear in "postconf -n" output). Removed smtp_tls_security_level = encrypt If the relay has a valid certificate, make that "secure". smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt smtp_tls_CApath = /etc/pki/tls/certs Otherwise, no need to bother with CAfile / CApath. You should also have "smtp_tls_loglevel = 1". And updated the security level to "secure". If I turn this to "secure", I get in maillog file: server certificate verification failed for smtp.gmx.com[212.227.17.174]:465: num=62:hostname mismatch smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_tls_verify_cert_match = myhost.fqdn And switched to : smtp_tls_secure_cert_match = ... not so secret ISP relay ... [ definitely not your server's hostname, if that's what "myhost.fqdn" is supposed to be. ] Done smtpd_sasl_auth_enable = yes You probably don't want this. smtpd_tls_security_level = encrypt Nor this, except on the submission services in master.cf. Suppressed (I don't understand : "except on the submission services in master.cf" I did not change anything in master.cf) And turned off SASL AUTH on your inbound port 25. I don't understand this... You're obfuscating the essential hostnames, making help needlessly difficult. Did you read the text in SASL_README that explains the lookup key syntax for the password table, when using "[]" and/or ":port" in the relay name? You probably have the wrong lookup key syntax. You need to post the exact syntax of the lookup key in your "smtp_sasl_password_maps" table, and check that: # postmap -q "$(postconf -xh relayhost)" \ $(postconf -xh smtp_sasl_password_maps) | cat -etv returns the expected result. (The "cat -etv" should highlight any unexpected invisible characters). I made an error in password_maps : the relayhost wanted my full email address as my user name. Corrected. #postconf -n inet_interfaces = localhost Is your server supposed to receive any mail from outside? Or is it a "send-only" server? A "send-only" server. myhostname = myhost.fqdn relayhost = [smtp.myfai.fqdn]:465 More needless obfuscation. ok smtp_sasl_au
[pfx] Re: configure a relayhost
On Sun, Sep 10, 2023 at 10:38:27AM +0200, François Patte via Postfix-users wrote: > > > > > Sep 9 16:50:49 myserver postfix/smtp[205832]: 92BEFB4BEA: > > > > > to=, relay=my-fai-smtp[x.x.x.x]:465, > > > > > delay=0.22, > > > > > delays=0.04/0.08/0.08/0.02, dsn=5.0.0, status=bounced (host > > > > > my-fai-smtps[x.x.x.x] said: 530 Authentication required (in reply to > > > > > MAIL FROM command)) > > > > > > > > https://www.postfix.org/DEBUG_README.html#mail > > > > It looks like you "tampered" with the logs. They don't match your > > reported configuration below. If you continue to treat the hostname of your ISP's (FAI's) SMTP relay as restricted sensitive information, the help you'll receive will also be restricted to vague generalities. > > > smtp_enforce_tls = yes > > > smtp_use_tls = yes > > > > These are obsolete and redundant. You should have by now removed these settings from "main.cf" (so that these parameters no longer appear in "postconf -n" output). > > > smtp_tls_security_level = encrypt > > > > If the relay has a valid certificate, make that "secure". > > > > > smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt > > > smtp_tls_CApath = /etc/pki/tls/certs > > > > Otherwise, no need to bother with CAfile / CApath. > > > > You should also have "smtp_tls_loglevel = 1". And updated the security level to "secure". > > > smtp_sasl_auth_enable = yes > > > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd > > > > > smtp_tls_verify_cert_match = myhost.fqdn And switched to : smtp_tls_secure_cert_match = ... not so secret ISP relay ... [ definitely not your server's hostname, if that's what "myhost.fqdn" is supposed to be. ] > > > smtpd_sasl_auth_enable = yes > > > > You probably don't want this. > > > > > smtpd_tls_security_level = encrypt > > > > Nor this, except on the submission services in master.cf. And turned off SASL AUTH on your inbound port 25. > > You're obfuscating the essential hostnames, making help needlessly > > difficult. Did you read the text in SASL_README that explains the > > lookup key syntax for the password table, when using "[]" and/or ":port" > > in the relay name? > > > > You probably have the wrong lookup key syntax. You need to post the exact syntax of the lookup key in your "smtp_sasl_password_maps" table, and check that: # postmap -q "$(postconf -xh relayhost)" \ $(postconf -xh smtp_sasl_password_maps) | cat -etv returns the expected result. (The "cat -etv" should highlight any unexpected invisible characters). > #postconf -n > inet_interfaces = localhost Is your server supposed to receive any mail from outside? Or is it a "send-only" server? > myhostname = myhost.fqdn > relayhost = [smtp.myfai.fqdn]:465 More needless obfuscation. > smtp_enforce_tls = no > smtp_use_tls = yes See above. > smtp_sasl_auth_enable = yes > smtp_sasl_mechanism_filter = login Why insist on "login"? Any reason to not include "plain"? > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd See above for a test of the lookup key and content. > smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt > smtp_tls_CApath = /etc/pki/tls/certs Only useful with the security level set to "secure" (or "verify", given equal "*_cert_match" values). > smtp_tls_loglevel = 1 That's better. > smtp_tls_security_level = encrypt > smtp_tls_verify_cert_match = myhost.fqdn But these have not been fixed. > smtpd_sasl_auth_enable = yes And this remains in place. > smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem > smtpd_tls_key_file = /etc/pki/tls/private/postfix.key > smtpd_tls_security_level = secure This makes no sense, the Postfix SMTP server only supports "none", "may" and "encrypt". This was supposed to be "smtp" not "smtpd". > Sep 10 08:31:30 pingala postfix/smtp[216476]: > Trusted TLS connection established to smtp.myfai.fqdn[x.x.x.x]:465: > TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) > key-exchange X25519 server-signature RSA-PSS (2048 bits) > server-digest SHA256 This is due to the security level being only "encrypt". You should be seeing "Verififed" not "Trusted", once your configuration is correct. > Sep 10 08:31:30 pingala postfix/smtp[216476]: 9A2ECB6DCF: SASL > authentication failed; server smtp.myfai.fqdn[x.x.x.x] said: 535 > Authentication credentials invalid So something was now found in the "smtp_sasl_password_maps" table matching the relay host, but the ISP did not accept the credentials. Perhaps they wanted a different mechanism? > It seems that the connection with the relay host is opened but why are > the credential rejected? These credentials work perfecctly if I use > ssmtp! Nobody can tell you why an undisclosed ISP rejected undisclosed credentials that haven't been checked for correctness. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: configure a relayhost
On 10.09.23 10:38, François Patte via Postfix-users wrote: relayhost = [smtp.myfai.fqdn]:465 smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = login smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd what is on your /etc/postfix/sasl_passwd ? It should be [smtp.myfai.fqdn]:465 : and now, if I try to send a mail the maillog says: Sep 10 08:31:30 pingala postfix/smtp[216476]: 9A2ECB6DCF: SASL authentication failed; server smtp.myfai.fqdn[x.x.x.x] said: 535 Authentication credentials invalid Sep 10 08:31:30 pingala postfix/smtp[216476]: 9A2ECB6DCF: to=, relay=smtp.myfai.fqdn[x.x.x.x]:465, delay=0.32, delays=0.03/0.06/0.24/0, dsn=4.0.0, status=deferred (SASL authentication failed; server smtp.myfai.fqdn[x.x.x.x] said: 535 Authentication credentials invalid) It seems that the connection with the relay host is opened but why are the credential rejected? These credentials work perfecctly if I use ssmtp! perhaps they are incorrectly entered? Perhaps you forgot to use run "postmap /etc/postfix/sasl_passwd" after change? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I drive way too fast to worry about cholesterol. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: configure a relayhost
Le 09/09/2023 à 19:53, Viktor Dukhovni via Postfix-users a écrit : On Sat, Sep 09, 2023 at 07:37:13PM +0200, François Patte via Postfix-users wrote: As my postfix install is configured, I get only (in mail-log): Sep 9 16:50:49 myserver postfix/qmgr[205575]: 92BEFB4BEA: from=, size=484, nrcpt=1 (queue active) Sep 9 16:50:49 myserver postfix/smtp[205832]: 92BEFB4BEA: to=, relay=my-fai-smtp[x.x.x.x]:465, delay=0.22, delays=0.04/0.08/0.08/0.02, dsn=5.0.0, status=bounced (host my-fai-smtps[x.x.x.x] said: 530 Authentication required (in reply to MAIL FROM command)) https://www.postfix.org/DEBUG_README.html#mail It looks like you "tampered" with the logs. They don't match your reported configuration below. postconf -n relayhost = [myfai.fqdn]:465 This is not equal to "my-fai-smtp". smtp_tls_wrappermode = yes Good, needed for transmission via port 465. smtp_enforce_tls = yes smtp_use_tls = yes These are obsolete and redundant. smtp_tls_security_level = encrypt If the relay has a valid certificate, make that "secure". smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt smtp_tls_CApath = /etc/pki/tls/certs Otherwise, no need to bother with CAfile / CApath. You should also have "smtp_tls_loglevel = 1". smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_tls_verify_cert_match = myhost.fqdn More needless tampering with the configuration. THe real setting is surely not secret, and should be equal to what you expect to find in the relayhost's certificate. And this is only needed if the security level is "verify", but it is currently "encrypt" (should be "secure", with the corresponding "cert_match" set if need be). smtpd_sasl_auth_enable = yes You probably don't want this. smtpd_tls_security_level = encrypt Nor this, except on the submission services in master.cf. https://www.postfix.org/SASL_README.html#client_sasl My main.cf has the same values for the smtp_xxx listed on the page; other values are the default ones given by the postfix package. You're obfuscating the essential hostnames, making help needlessly difficult. Did you read the text in SASL_README that explains the lookup key syntax for the password table, when using "[]" and/or ":port" in the relay name? You probably have the wrong lookup key syntax. Hi, I I added the cyrus-sasl-plain package and modify my main.cf: #postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin compatibility_level = 3.7 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 html_directory = no inet_interfaces = localhost inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man meta_directory = /etc/postfix mydestination = myhostname = myhost.fqdn newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix/README_FILES relayhost = [smtp.myfai.fqdn]:465 sample_directory = /usr/share/doc/postfix/samples sender_canonical_maps = sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop shlib_directory = /usr/lib64/postfix smtp_enforce_tls = no smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = login smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = smtp_sasl_tls_security_options = noanonymous smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt smtp_tls_CApath = /etc/pki/tls/certs smtp_tls_loglevel = 1 smtp_tls_security_level = encrypt smtp_tls_verify_cert_match = myhost.fqdn smtp_tls_wrappermode = yes smtp_use_tls = yes smtpd_sasl_auth_enable = yes smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem smtpd_tls_key_file = /etc/pki/tls/private/postfix.key smtpd_tls_security_level = secure unknown_local_recipient_reject_code = 550 (reverse-i-search)`cyru': dnf install cyrus-sasl-plain and now, if I try to send a mail the maillog says: Sep 10 08:31:30 pingala postfix/pickup[216370]: 9A2ECB6DCF: uid=0 from= Sep 10 08:31:30 pingala postfix/cleanup[216474]: 9A2ECB6DCF: message-id=<20230910083130.9a2ecb6...@myhost.fqdn> Sep 10 08:31:30 pingala postfix/qmgr[216371]: 9A2ECB6DCF: from=, size=484, nrcpt=1 (queue active) Sep 10 08:31:30 pingala postfix/smtp[216476]: Trusted TLS connection established to smtp.myfai.fqdn[x.x.x.x]:465: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 Sep 10 08:31:30 pingala postfix/smtp[216476]: 9A2ECB6DCF: SASL authentication failed; server smtp.myfai.fqdn[x.x.x.x] said: 535 Authentication credentials invalid Sep 10 08:31:30 pingala postfix/smtp[216
[pfx] Re: configure a relayhost
On Sat, Sep 09, 2023 at 07:37:13PM +0200, François Patte via Postfix-users wrote: > > > As my postfix install is configured, I get only (in mail-log): > > > > > > Sep 9 16:50:49 myserver postfix/qmgr[205575]: 92BEFB4BEA: > > > from=, size=484, nrcpt=1 (queue active) > > > Sep 9 16:50:49 myserver postfix/smtp[205832]: 92BEFB4BEA: > > > to=, relay=my-fai-smtp[x.x.x.x]:465, delay=0.22, > > > delays=0.04/0.08/0.08/0.02, dsn=5.0.0, status=bounced (host > > > my-fai-smtps[x.x.x.x] said: 530 Authentication required (in reply to > > > MAIL FROM command)) > > > > https://www.postfix.org/DEBUG_README.html#mail It looks like you "tampered" with the logs. They don't match your reported configuration below. > postconf -n > relayhost = [myfai.fqdn]:465 This is not equal to "my-fai-smtp". > smtp_tls_wrappermode = yes Good, needed for transmission via port 465. > smtp_enforce_tls = yes > smtp_use_tls = yes These are obsolete and redundant. > smtp_tls_security_level = encrypt If the relay has a valid certificate, make that "secure". > smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt > smtp_tls_CApath = /etc/pki/tls/certs Otherwise, no need to bother with CAfile / CApath. You should also have "smtp_tls_loglevel = 1". > smtp_sasl_auth_enable = yes > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd > smtp_tls_verify_cert_match = myhost.fqdn More needless tampering with the configuration. THe real setting is surely not secret, and should be equal to what you expect to find in the relayhost's certificate. And this is only needed if the security level is "verify", but it is currently "encrypt" (should be "secure", with the corresponding "cert_match" set if need be). > smtpd_sasl_auth_enable = yes You probably don't want this. > smtpd_tls_security_level = encrypt Nor this, except on the submission services in master.cf. > > https://www.postfix.org/SASL_README.html#client_sasl > > My main.cf has the same values for the smtp_xxx listed on the page; > other values are the default ones given by the postfix package. You're obfuscating the essential hostnames, making help needlessly difficult. Did you read the text in SASL_README that explains the lookup key syntax for the password table, when using "[]" and/or ":port" in the relay name? You probably have the wrong lookup key syntax. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: configure a relayhost
Le 09/09/2023 à 19:10, Viktor Dukhovni via Postfix-users a écrit : On Sat, Sep 09, 2023 at 06:55:03PM +0200, François Patte via Postfix-users wrote: I would like to use my fai smtp server to send mails using postfix. As my postfix install is configured, I get only (in mail-log): Sep 9 16:50:49 myserver postfix/qmgr[205575]: 92BEFB4BEA: from=, size=484, nrcpt=1 (queue active) Sep 9 16:50:49 myserver postfix/smtp[205832]: 92BEFB4BEA: to=, relay=my-fai-smtp[x.x.x.x]:465, delay=0.22, delays=0.04/0.08/0.08/0.02, dsn=5.0.0, status=bounced (host my-fai-smtps[x.x.x.x] said: 530 Authentication required (in reply to MAIL FROM command)) https://www.postfix.org/DEBUG_README.html#mail postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin compatibility_level = 3.7 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 html_directory = no inet_interfaces = localhost inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man meta_directory = /etc/postfix mydestination = myhostname = myhost.fqdn newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix/README_FILES relayhost = [myfai.fqdn]:465 sample_directory = /usr/share/doc/postfix/samples sender_canonical_maps = sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop shlib_directory = /usr/lib64/postfix smtp_enforce_tls = yes smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = smtp_sasl_tls_security_options = noanonymous smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt smtp_tls_CApath = /etc/pki/tls/certs smtp_tls_security_level = encrypt smtp_tls_verify_cert_match = myhost.fqdn smtp_tls_wrappermode = yes smtp_use_tls = yes smtpd_sasl_auth_enable = yes smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem smtpd_tls_key_file = /etc/pki/tls/private/postfix.key smtpd_tls_security_level = encrypt unknown_local_recipient_reject_code = 550 https://www.postfix.org/SASL_README.html#client_sasl My main.cf has the same values for the smtp_xxx listed on the page; other values are the default ones given by the postfix package. F.P. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: configure a relayhost
On Sat, Sep 09, 2023 at 06:55:03PM +0200, François Patte via Postfix-users wrote: > I would like to use my fai smtp server to send mails using postfix. > > As my postfix install is configured, I get only (in mail-log): > > Sep 9 16:50:49 myserver postfix/qmgr[205575]: 92BEFB4BEA: > from=, size=484, nrcpt=1 (queue active) > Sep 9 16:50:49 myserver postfix/smtp[205832]: 92BEFB4BEA: > to=, relay=my-fai-smtp[x.x.x.x]:465, delay=0.22, > delays=0.04/0.08/0.08/0.02, dsn=5.0.0, status=bounced (host > my-fai-smtps[x.x.x.x] said: 530 Authentication required (in reply to > MAIL FROM command)) https://www.postfix.org/DEBUG_README.html#mail https://www.postfix.org/SASL_README.html#client_sasl -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] configure a relayhost
Bonjour, I would like to use my fai smtp server to send mails using postfix. As my postfix install is configured, I get only (in mail-log): Sep 9 16:50:49 myserver postfix/qmgr[205575]: 92BEFB4BEA: from=, size=484, nrcpt=1 (queue active) Sep 9 16:50:49 myserver postfix/smtp[205832]: 92BEFB4BEA: to=, relay=my-fai-smtp[x.x.x.x]:465, delay=0.22, delays=0.04/0.08/0.08/0.02, dsn=5.0.0, status=bounced (host my-fai-smtps[x.x.x.x] said: 530 Authentication required (in reply to MAIL FROM command)) I would like some help. Thank you. F.P. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: send clear text passwords to relayhost?
Am 06.07.23 um 21:39 schrieb Viktor Dukhovni via Postfix-users: So the service provider advertises, but fails to implement "PLAIN", that sounds like a bad idea. Open a bug report. They should not do that. I did have one open. More for cram-md5 than plain, of course. The issue is: For older accounts created with them cram-md5 (an plain?) still do work. Currently there are still two accounts left, where I may (or rather have to) use the old method (cram-md5). If I were to change the passwords of those two accounts (or alter them in any other way), they would need to switch to login. That is true for both their pop3 as well as smtp service. Both of which, from their perspective, are intended to be used with mail clients, not postfix or fetchmail. While this may be a questionable way of doing things, it surely is intentional, so they won't fix it. It is part of their migration path, I assume. Having dedicated server for either methods would have been better in my account. But it is how it is So technicalls their smtp server still does support cram-md5 - and therefore supposedly also plain - just not for all accounts. As confirmed by their (rather questionable) support. What consequences this may have, remains to be seen. WIP. changing back to login: There are no "superset mechanisms" in SASL. Just discrete method names, however for purposes of options there are some required mechanism properties that one configure in the SASL security options. Postfix supports: forward_secrecy mutual_auth noactive noanonymous nodictionary noplaintext There also these days no "kerberos" mechanism, just "gssapi". Thanks for that comprehensive list. But it confirms my confusion: noplaintext is no sasl mechanism, but it is a superset of at least two mechanisms (to disallow): login and plain. It is the way postfix does it, and may make sense from a security perpective, but when I was trying to read the documentation, I was focued on how to tell postfix what to do and not, what not to do. The last four in your list are starting with "no" That is why I have gotten the sasl filter initially completely wrong. smtp_sasl_security_options are focused on metasets (as noplaintext, on what I of course have been focussed), while the smtp_sasl_mechanism_filter uses concrete sasl mechanism. If you know it, you figure, as it already states it in the name, but I did not get the logic initially. Therefore again a big, big thanks for your time and help and explanations. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: send clear text passwords to relayhost?
On Thu, Jul 06, 2023 at 06:38:34PM +0200, Ede Wolf via Postfix-users wrote: > Jep, I just retested. Changed to plain, restarted postfix and mail gets > deferred: > > relay=smtp.worldserver.net[217.13.200.36]:587, delay=1, > delays=0.07/0.01/0.95/0, dsn=4.7.0, status=deferred (SASL authentication > failed; cannot authenticate to server smtp.world So the service provider advertises, but fails to implement "PLAIN", that sounds like a bad idea. Open a bug report. They should not do that. > changing back to login: > > relay=smtp.worldserver.net[217.13.200.36]:587, delay=190, > delays=185/0.02/0.22/4.6, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued > as D302E1E0A44) In that case stick with just "login". > I have used "password" as a superset or class of all clear text password > methods, as opposed to fundamentally different methods, such as > kerberos or ntlm. There are no "superset mechanisms" in SASL. Just discrete method names, however for purposes of options there are some required mechanism properties that one configure in the SASL security options. Postfix supports: forward_secrecy mutual_auth noactive noanonymous nodictionary noplaintext There also these days no "kerberos" mechanism, just "gssapi". -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: send clear text passwords to relayhost?
Am 06.07.23 um 14:51 schrieb Viktor Dukhovni via Postfix-users: I am surprised to hear that "login" works and "plain" does not, are you sure about that? Jep, I just retested. Changed to plain, restarted postfix and mail gets deferred: relay=smtp.worldserver.net[217.13.200.36]:587, delay=1, delays=0.07/0.01/0.95/0, dsn=4.7.0, status=deferred (SASL authentication failed; cannot authenticate to server smtp.world changing back to login: relay=smtp.worldserver.net[217.13.200.36]:587, delay=190, delays=185/0.02/0.22/4.6, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as D302E1E0A44) smtp_sasl_mechanism_filter = plain, login and let SASL choose whichever it prefers when both are offered. Have not tried this, as "login" works, but using both, I am afraid we might run into the same issue as with cram-md5, since the server offers all three (plain, login, cram). So, if plain is preferred by postfix, as cram-md5 used to be, mail would not get through. So why take a risk, if login works? The mechanism name is "PLAIN" or "plain" (case insensitive). Both "PLAIN" and "LOGIN" use cleartext passwords, there is no mechanism named "password". Thanks for the heads up again. As smtp_sasl_security_options specifies: noplaintext Disallow methods that use plaintext passwords. I have used "password" as a superset or class of all clear text password methods, as opposed to fundamentally different methods, such as kerberos or ntlm. Which is wrong, I (hopefully) get it now, but was the reason why I have misunderstood the smtp_sasl_mechanism_filter in the first place. sasl will never by my friend, I am afraid. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: send clear text passwords to relayhost?
On Thu, Jul 06, 2023 at 08:10:39AM +0200, Ede Wolf via Postfix-users wrote:
> > BINGO! The server is advertising CRAM-MD5, and unless you filter it out
> > SASL will attempt to use that instead of plain. Therefore, in the
> > proposed "master.cf" entry you also need:
> >
> > -o { smtp_sasl_mechanism_filter = plain }
>
> Well, I did not before my last post. Doing telnet style mail
> communication with TLS came up during my try to fixing this this.
>
> However, smtp_sasl_mechanism = plain
> did not work either, but "login" made my day.
Of course not, it should be:
smtp_sasl_mechanism_filter = plain
I am surprised to hear that "login" works and "plain" does not, are you
sure about that? You can also set the filter to:
smtp_sasl_mechanism_filter = plain, login
and let SASL choose whichever it prefers when both are offered.
> > See: https://www.postfix.org/postconf.5.html#smtp_sasl_mechanism_filter
>
> Thanks, I misread this one, I have misunderstood the sasl mechanisms as
> in password, gssapi.. I guess I'll never understand sasl.
The mechanism name is "PLAIN" or "plain" (case insensitive). Both
"PLAIN" and "LOGIN" use cleartext passwords, there is no mechanism
named "password".
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: send clear text passwords to relayhost?
Hello Viktor,
again, thanks very much for your help
See below, with the critical additional detail you present now (and
sadly did not know to present before), there's more to be done.
The problem here is, that the annoucement of CRAM-MD5 is false. While it
still does work for older accounts, it does not any more not for newly
created or somehow modified older ones.
BINGO! The server is advertising CRAM-MD5, and unless you filter it out
SASL will attempt to use that instead of plain. Therefore, in the
proposed "master.cf" entry you also need:
-o { smtp_sasl_mechanism_filter = plain }
Well, I did not before my last post. Doing telnet style mail
communication with TLS came up during my try to fixing this this.
However, smtp_sasl_mechanism = plain
did not work either, but "login" made my day.
See: https://www.postfix.org/postconf.5.html#smtp_sasl_mechanism_filter
Thanks, I misread this one, I have misunderstood the sasl mechanisms as
in password, gssapi.. I guess I'll never understand sasl.
So probably, to answer your initial question, I do suppose I have been
using cram-md5 until now. Now I need to force (not just admit) plain
and, unless I have missed something, the smtp_tls* settings are not enough.
Correct, see above. Ideally you'd have known to share this new
information, but if you had known it to be important, you might
have solved the problem without outside help, or been close to
doing so...
No, I just did not know before
Anyway, thanks again for your help, highly appreciated!
Ede
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: send clear text passwords to relayhost?
On Wed, Jul 05, 2023 at 10:09:12PM +0200, Ede Wolf via Postfix-users wrote:
> thanks very much for your reply. I still may have some understanding issues:
>
> Am 05.07.23 um 16:22 schrieb Viktor Dukhovni via Postfix-users:
> > On Wed, Jul 05, 2023 at 02:42:54PM +0200, Ede Wolf via Postfix-users wrote:
> >
> >> I am having a weired issue. My provider for the relayhost switched to
> >> SSL - which is fine by itself - but that also changed the authentication
> >> scheme.
> >
> > What SASL mechanism was used before that?
>
> Frankly, I do not know, it just worked with the posted configuration.
You answer this below.
> > likely progress. As is enabling TLS, regardless of whether the SASL
> > mechanism is challenge-response based.
>
> Thanks for the heads up. According to the support, they now do store the
> hash.
Presumably *only* the hash, with the cleartext passwords not stored.
Otherwise, the result is less secure.
> > That's not quite the whole story, the relevant documented defaults are:
> >
> > smtp_sasl_security_options (default: noplaintext, noanonymous)
> > smtp_sasl_tls_security_options (default: $smtp_sasl_security_options)
> > smtp_sasl_tls_verified_security_options (default:
> > $smtp_sasl_tls_security_options)
> >
> > But you need at least the last of these to admit "plaintext" (i.e. not
> > specify "noplaintext"). The correct (security-minded) configuration is:
> >
> > # smtp_sasl_security_options = noplaintext noanonymous
> > # smtp_sasl_tls_security_options = $smtp_sasl_security_options
> > smtp_sasl_tls_verified_security_options = noanonymous
>
> Not sure I am understanding this correctly. While commented out in my
> above example, I have been using:
>
> smtp_sasl_security_options = noanonymous
You should if possible change just:
> > smtp_sasl_tls_verified_security_options = noanonymous
and make sure that the connection to the is "verified" (TLS security
level "secure").
> before, and it did not work, that is why I removed the noanonymous.
> However, now I have tried both:
>
> smtp_sasl_tls_verified_security_options = noanonymous
>
> and:
>
> smtp_sasl_tls_security_options = noanonymous
See below, with the critical additional detail you present now (and
sadly did not know to present before), there's more to be done.
> and all three of them. Again, I do not comprehend, how noanymous forces
> PLAIN.
It doesn't "force" PLAIN, it *unblocks* PLAIN, but other offered
mechanisms will be considered, and may be preferred.
> Anyway, there is no difference at all, mail is being rejected.
As expected see below.
> > Use a custom "default_transport" with an explicit "nexthop" relay,
> > instead of just "relayhost". This makes it possible to specify
> > appropriate TLS policy settings without resorting to a TLS policy table.
> >
> > main.cf:
> > # Possibly with a ":port" suffix
> > default_transport = isprelay:[smtp.provider.net]
> >
> > master.cf:
> > # Note, no chroot!
> > isprelay unix - - n - - smtp
> > -o { smtp_tls_security_level = secure }
> > -o { smtp_tls_CAfile = /etc/postfix/ispcas.pem }
> >
> > The "ispcas.pem" file (or pick another pathname) can list just the CAs
> > you trust and expect to issue the ISPs certificate (ideally less than
> > the entire browser CA/B forum CA "bundle").
> >
>
> What advantages may this have to simply specifying:
>
> smtp_tls_security_level = encrypt
The latter is not authenticated, so an MITM could "steal" your password.
> The Server advertises:
>
> EHLO nebelschwaden.de
>
> 00d0 - 90 ee e2 1b 4b
> 250-mail.worldserver.net
> 250-PIPELINING
> 250-SIZE 71303168
> 250-VRFY
> 250-ETRN
> 250-AUTH PLAIN LOGIN CRAM-MD5
> 250-AUTH=PLAIN LOGIN CRAM-MD5
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 CHUNKING
>
> The problem here is, that the annoucement of CRAM-MD5 is false. While it
> still does work for older accounts, it does not any more not for newly
> created or somehow modified older ones.
BINGO! The server is advertising CRAM-MD5, and unless you filter it out
SASL will attempt to use that instead of plain. Therefore, in the
proposed "master.cf" entry you also need:
-o { smtp_sasl_mechanism_filter = plain }
See: https://www.postfix.org/postconf.5.html#smtp_sasl_mechanism_filter
> So probably, to answer your initial question, I d
[pfx] Re: send clear text passwords to relayhost?
Hello Viktor,
thanks very much for your reply. I still may have some understanding issues:
Am 05.07.23 um 16:22 schrieb Viktor Dukhovni via Postfix-users:
On Wed, Jul 05, 2023 at 02:42:54PM +0200, Ede Wolf via Postfix-users wrote:
I am having a weired issue. My provider for the relayhost switched to
SSL - which is fine by itself - but that also changed the authentication
scheme.
What SASL mechanism was used before that?
Frankly, I do not know, it just worked with the posted configuration.
So most likely switching from, say, CRAM-MD5 or similar to PLAIN is
likely progress. As is enabling TLS, regardless of whether the SASL
mechanism is challenge-response based.
Thanks for the heads up. According to the support, they now do store the
hash.
So now I am wondering, wether or how this could be accomplished with
postfix?
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:$meta_directory/smtp_auth
smtp_sasl_security_options =
#smtp_sasl_security_options = noanonymous
But I am not sure, how to convert this into simple plain text auth.
Google advised to leave the smtp_sasl_security_options
empty, but that did not do the trick.
That's not quite the whole story, the relevant documented defaults are:
smtp_sasl_security_options (default: noplaintext, noanonymous)
smtp_sasl_tls_security_options (default: $smtp_sasl_security_options)
smtp_sasl_tls_verified_security_options (default:
$smtp_sasl_tls_security_options)
But you need at least the last of these to admit "plaintext" (i.e. not
specify "noplaintext"). The correct (security-minded) configuration is:
# smtp_sasl_security_options = noplaintext noanonymous
# smtp_sasl_tls_security_options = $smtp_sasl_security_options
smtp_sasl_tls_verified_security_options = noanonymous
Not sure I am understanding this correctly. While commented out in my
above example, I have been using:
smtp_sasl_security_options = noanonymous
before, and it did not work, that is why I removed the noanonymous.
However, now I have tried both:
smtp_sasl_tls_verified_security_options = noanonymous
and:
smtp_sasl_tls_security_options = noanonymous
and all three of them. Again, I do not comprehend, how noanymous forces
PLAIN.
Anyway, there is no difference at all, mail is being rejected.
Generally, while of course TLS should be used with plain passwords,
those are two different things, aren't they? Establishing an encrypted
connection is one thing, after the connection has been established,
sending the password is another. As fas as I can see, I am not having
connection issues.
Use a custom "default_transport" with an explicit "nexthop" relay,
instead of just "relayhost". This makes it possible to specify
appropriate TLS policy settings without resorting to a TLS policy table.
main.cf:
# Possibly with a ":port" suffix
default_transport = isprelay:[smtp.provider.net]
master.cf:
# Note, no chroot!
isprelay unix - - n - - smtp
-o { smtp_tls_security_level = secure }
-o { smtp_tls_CAfile = /etc/postfix/ispcas.pem }
The "ispcas.pem" file (or pick another pathname) can list just the CAs
you trust and expect to issue the ISPs certificate (ideally less than
the entire browser CA/B forum CA "bundle").
What advantages may this have to simply specifying:
smtp_tls_security_level = encrypt
in the main.cf, which I already do have?
As mentioned before, I do not seem to have connection issues:
Jul 5 21:24:32 mail.info postfix/smtp[5484]: B70A010F2CE:
to=, relay=smtp.worldserver.net[217.13.200.36]:587,
delay=270, delays=267/0.02/2.5/0, dsn=4.7.8, status=deferred (SASL
authentication failed; server smtp.worldserver.net[217.13.200.
So we are already past the handshake, just the way the password is
presented to the server does not get accepted.
The Server advertises:
EHLO nebelschwaden.de
00d0 - 90 ee e2 1b 4b
250-mail.worldserver.net
250-PIPELINING
250-SIZE 71303168
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN CRAM-MD5
250-AUTH=PLAIN LOGIN CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 CHUNKING
The problem here is, that the annoucement of CRAM-MD5 is false. While it
still does work for older accounts, it does not any more not for newly
created or somehow modified older ones.
Also, with an old account I can send mails via thunderbird with
"password encrypted", while this does not work any more with a newly
created account, where I have to use TLS and "password, transmitted
insecurely"
So probably, to answer your initial question, I do suppose I have been
using cram-md5 until now. Now I need to force (not just admit) plain
and, unless I have missed something, the smtp_tls* settings are not enough.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: send clear text passwords to relayhost?
On Wed, Jul 05, 2023 at 02:42:54PM +0200, Ede Wolf via Postfix-users wrote:
> I am having a weired issue. My provider for the relayhost switched to
> SSL - which is fine by itself - but that also changed the authentication
> scheme.
What SASL mechanism was used before that? You're in fact generally
better off with SASL "plain", because the risk of password compromise
is higher when password-equivalent material is stored on the server,
rather than some sort of one-way hash, which requires the client to
send the "plain" password for verification.
There are of course in the cryptography literature various "PAKE"
algorithms, that make it possible for the client to prove knowledge of a
password without sending it to the server, and without the server
storing password-equivalent material, but such mechanisms are not IIRC
at all widely supported by SASL implementations, and are not easy to
configure.
So most likely switching from, say, CRAM-MD5 or similar to PLAIN is
likely progress. As is enabling TLS, regardless of whether the SASL
mechanism is challenge-response based.
> So SASL, what worked for over a decade, does not work any more, instead
> I need to send plain text username/pw. Confirmed by the providers support.
Possibly a case of the blind leading the blind, but probably correct.
> Wether this is good or braindead is not a matter of debate on the short
> term. It is, what it currently has become.
See above, this is likely progress. I do hope they scrubbed the
cleartext passwords in the process and now store just the hashes.
> So now I am wondering, wether or how this could be accomplished with
> postfix?
>
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:$meta_directory/smtp_auth
> smtp_sasl_security_options =
> #smtp_sasl_security_options = noanonymous
>
> But I am not sure, how to convert this into simple plain text auth.
> Google advised to leave the smtp_sasl_security_options
> empty, but that did not do the trick.
That's not quite the whole story, the relevant documented defaults are:
smtp_sasl_security_options (default: noplaintext, noanonymous)
smtp_sasl_tls_security_options (default: $smtp_sasl_security_options)
smtp_sasl_tls_verified_security_options (default:
$smtp_sasl_tls_security_options)
But you need at least the last of these to admit "plaintext" (i.e. not
specify "noplaintext"). The correct (security-minded) configuration is:
# smtp_sasl_security_options = noplaintext noanonymous
# smtp_sasl_tls_security_options = $smtp_sasl_security_options
smtp_sasl_tls_verified_security_options = noanonymous
Use a custom "default_transport" with an explicit "nexthop" relay,
instead of just "relayhost". This makes it possible to specify
appropriate TLS policy settings without resorting to a TLS policy table.
main.cf:
# Possibly with a ":port" suffix
default_transport = isprelay:[smtp.provider.net]
master.cf:
# Note, no chroot!
isprelay unix - - n - - smtp
-o { smtp_tls_security_level = secure }
-o { smtp_tls_CAfile = /etc/postfix/ispcas.pem }
The "ispcas.pem" file (or pick another pathname) can list just the CAs
you trust and expect to issue the ISPs certificate (ideally less than
the entire browser CA/B forum CA "bundle").
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] send clear text passwords to relayhost?
Hello, I am having a weired issue. My provider for the relayhost switched to SSL - which is fine by itself - but that also changed the authentication scheme. So SASL, what worked for over a decade, does not work any more, instead I need to send plain text username/pw. Confirmed by the providers support. Wether this is good or braindead is not a matter of debate on the short term. It is, what it currently has become. So now I am wondering, wether or how this could be accomplished with postfix? My current configuration: smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:$meta_directory/smtp_auth smtp_sasl_security_options = #smtp_sasl_security_options = noanonymous But I am not sure, how to convert this into simple plain text auth. Google advised to leave the smtp_sasl_security_options empty, but that did not do the trick. For those, who by chance also know thunderbird, when trying to connect directly to my providers outgoing mail server (the relayhost), the setting now required is "password, transmitted insecurely", while "password encrypted" does not work (any more). However, instead of talkng to my provider directly, the mailclients should use postfix, that in turn relays mail to my provider. Would that be possible to archive with postfix, to send plain text passwords to a relay host? And, off topic: Fetchmail has the same issue now, it cannot retrieve mails any more. Just in case someone has a solution here as well. Thanks Ede ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: relayhost and backup MX
> On 21.05.23 15:53, Tom Reed via Postfix-users wrote: >>My postfix has setup another MTA for relay host, >> >>relayhost = [relay_ip] >> >>If I setup this postfix as backup mx for a domain, such as foo.com. >>will messages for foo.com relay from relay_ip too, or go directly to the >>primary MX? > > messages will go TO the relay_ip unless you override it in transport_maps. > > example.com relay:example.com > > Can backup MX use primary MX as relay server then? backup mx domain and relayed domain are different ones. Thank you. -- sent from https://dkinbox.com/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: relayhost and backup MX
On 21.05.23 15:53, Tom Reed via Postfix-users wrote: My postfix has setup another MTA for relay host, relayhost = [relay_ip] If I setup this postfix as backup mx for a domain, such as foo.com. will messages for foo.com relay from relay_ip too, or go directly to the primary MX? On 21.05.23 11:38, Matus UHLAR - fantomas via Postfix-users wrote: messages will go TO the relay_ip unless you override it in transport_maps. example.com relay:example.com sorry, correct: example.com relay:[primary-mx.example.com] so we don't deliver to backup MX addresses. the first example is fine for exemptions we aren't backup MX for. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Silvester Stallone: Father of the RISC concept. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: relayhost and backup MX
On 21.05.23 15:53, Tom Reed via Postfix-users wrote: My postfix has setup another MTA for relay host, relayhost = [relay_ip] If I setup this postfix as backup mx for a domain, such as foo.com. will messages for foo.com relay from relay_ip too, or go directly to the primary MX? messages will go TO the relay_ip unless you override it in transport_maps. example.com relay:example.com -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] relayhost and backup MX
Hello list, My postfix has setup another MTA for relay host, relayhost = [relay_ip] If I setup this postfix as backup mx for a domain, such as foo.com. will messages for foo.com relay from relay_ip too, or go directly to the primary MX? Thanks in advance. -- sent from https://dkinbox.com/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: [EXTERNAL] Re: MX records and relayhost: Am I going this correctly ?
Thank you again. Great information. __ Daniel E. White daniel.e.wh...@nasa.gov<mailto:daniel.e.wh...@nasa.gov> NASCOM Linux Engineer NASA Goddard Space Flight Center Office: (301) 286-6919 Mobile: (240) 513-5290 From: on behalf of Wietse Venema Reply-To: Postfix users Date: Wednesday, October 26, 2022 at 15:38 To: Postfix users Subject: Re: [EXTERNAL] Re: MX records and relayhost: Am I going this correctly ? White, Daniel E. (GSFC-770.0)[AEGIS]: Many thanks for the sanity check, Mr. Postfix I am using the explicit domain name rather than $mydomain mainly on client machines because they are not guaranteed to have the same domain as the mail servers. Is there any way to shorten/remove the delay I saw in the MX-failover ? By reducing smtp_connect_timeout from the default 300s to a more reasonable value, maybe 10-30s. Note that Postfix will shuffle the order of equal-preference MX hosts, so that a down server will delay only some of the traffic. Wietse Again, many thanks for the quick response From: mailto:owner-postfix-us...@postfix.org>> on behalf of Wietse Venema mailto:wie...@porcupine.org>> Reply-To: Postfix users mailto:postfix-users@postfix.org>> Date: Wednesday, October 26, 2022 at 14:09 To: Postfix users mailto:postfix-users@postfix.org>> Subject: [EXTERNAL] Re: MX records and relayhost: Am I going this correctly ? White, Daniel E. (GSFC-770.0)[AEGIS]: MX Records: mydomain.tld. 33 INMX 10 relay-1.mydomain.tld. mydomain.tld. 33 INMX 20 relay-2.mydomain.tld. with relay-1 and relay-2 having appropriate A and PTR records. Then in /etc/postfix/main.cf, I have relayhost = mydomain.tld I have seen this work with relay-1 unavailable. This is the obvious (to me) approach when the domain has multiple MX hosts. It is also similar to the first relayhost example in the stock main.cf file: relayhost = $mydomain The outgoing message sat in the queue for a brief time, then went out through relay-2. I found a Red Hat solution https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F4025391&data=05%7C01%7Cdaniel.e.white%40nasa.gov%7C157b6b61ac174ded95ec08dab789b6c5%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638024099350096166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W%2BFFkuCrI0261JyqNAgyuuzngImMdHnVMl3HYmlRKQs%3D&reserved=0 that suggests using relayhost = [relay-1.mydomain.tld] smtp_fallback_relay = [relay-2.mydomain.tld] This also works, but it would be less obvious to me. Wietse
Re: [EXTERNAL] Re: MX records and relayhost: Am I going this correctly ?
White, Daniel E. (GSFC-770.0)[AEGIS]: > Many thanks for the sanity check, Mr. Postfix > > I am using the explicit domain name rather than $mydomain mainly on client > machines because they are not guaranteed to have the same domain as the mail > servers. > > Is there any way to shorten/remove the delay I saw in the MX-failover ? By reducing smtp_connect_timeout from the default 300s to a more reasonable value, maybe 10-30s. Note that Postfix will shuffle the order of equal-preference MX hosts, so that a down server will delay only some of the traffic. Wietse > Again, many thanks for the quick response > > From: on behalf of Wietse Venema > > Reply-To: Postfix users > Date: Wednesday, October 26, 2022 at 14:09 > To: Postfix users > Subject: [EXTERNAL] Re: MX records and relayhost: Am I going this correctly ? > > White, Daniel E. (GSFC-770.0)[AEGIS]: > MX Records: > >mydomain.tld. 33 INMX 10 > relay-1.mydomain.tld. >mydomain.tld. 33 INMX 20 > relay-2.mydomain.tld. > > with relay-1 and relay-2 having appropriate A and PTR records. > > Then in /etc/postfix/main.cf, I have > > relayhost = mydomain.tld > > I have seen this work with relay-1 unavailable. > > This is the obvious (to me) approach when the domain has multiple > MX hosts. It is also similar to the first relayhost example in the > stock main.cf file: > > relayhost = $mydomain > > The outgoing message sat in the queue for a brief time, then went > out through relay-2. > > I found a Red Hat solution > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F4025391&data=05%7C01%7Cdaniel.e.white%40nasa.gov%7Cec472cf769824ce55a8e08dab77d47f4%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638024045956278652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WFi3rKroF5DsLvomCS5NcG9%2ByCKQOlC3ITI1KFW4oyU%3D&reserved=0 > that suggests using > >relayhost = [relay-1.mydomain.tld] >smtp_fallback_relay = [relay-2.mydomain.tld] > > This also works, but it would be less obvious to me. > > Wietse > >
Re: [EXTERNAL] Re: MX records and relayhost: Am I going this correctly ?
Many thanks for the sanity check, Mr. Postfix I am using the explicit domain name rather than $mydomain mainly on client machines because they are not guaranteed to have the same domain as the mail servers. Is there any way to shorten/remove the delay I saw in the MX-failover ? Again, many thanks for the quick response From: on behalf of Wietse Venema Reply-To: Postfix users Date: Wednesday, October 26, 2022 at 14:09 To: Postfix users Subject: [EXTERNAL] Re: MX records and relayhost: Am I going this correctly ? White, Daniel E. (GSFC-770.0)[AEGIS]: MX Records: mydomain.tld. 33 INMX 10 relay-1.mydomain.tld. mydomain.tld. 33 INMX 20 relay-2.mydomain.tld. with relay-1 and relay-2 having appropriate A and PTR records. Then in /etc/postfix/main.cf, I have relayhost = mydomain.tld I have seen this work with relay-1 unavailable. This is the obvious (to me) approach when the domain has multiple MX hosts. It is also similar to the first relayhost example in the stock main.cf file: relayhost = $mydomain The outgoing message sat in the queue for a brief time, then went out through relay-2. I found a Red Hat solution https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F4025391&data=05%7C01%7Cdaniel.e.white%40nasa.gov%7Cec472cf769824ce55a8e08dab77d47f4%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638024045956278652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WFi3rKroF5DsLvomCS5NcG9%2ByCKQOlC3ITI1KFW4oyU%3D&reserved=0 that suggests using relayhost = [relay-1.mydomain.tld] smtp_fallback_relay = [relay-2.mydomain.tld] This also works, but it would be less obvious to me. Wietse
Re: MX records and relayhost: Am I going this correctly ?
White, Daniel E. (GSFC-770.0)[AEGIS]: > MX Records: > > mydomain.tld. 33 IN MX 10 relay-1.mydomain.tld. > mydomain.tld. 33 IN MX 20 relay-2.mydomain.tld. > > with relay-1 and relay-2 having appropriate A and PTR records. > > Then in /etc/postfix/main.cf, I have > >relayhost = mydomain.tld > > I have seen this work with relay-1 unavailable. This is the obvious (to me) approach when the domain has multiple MX hosts. It is also similar to the first relayhost example in the stock main.cf file: relayhost = $mydomain > The outgoing message sat in the queue for a brief time, then went > out through relay-2. > > I found a Red Hat solution https://access.redhat.com/solutions/4025391 > that suggests using > > relayhost = [relay-1.mydomain.tld] > smtp_fallback_relay = [relay-2.mydomain.tld] This also works, but it would be less obvious to me. Wietse
MX records and relayhost: Am I going this correctly ?
MX Records: mydomain.tld. 33 IN MX 10 relay-1.mydomain.tld. mydomain.tld. 33 IN MX 20 relay-2.mydomain.tld. with relay-1 and relay-2 having appropriate A and PTR records. Then in /etc/postfix/main.cf, I have relayhost = mydomain.tld I have seen this work with relay-1 unavailable. The outgoing message sat in the queue for a brief time, then went out through relay-2. I found a Red Hat solution https://access.redhat.com/solutions/4025391 that suggests using relayhost = [relay-1.mydomain.tld] smtp_fallback_relay = [relay-2.mydomain.tld] Comments ? Suggestions ?
Re: How to send 10 messages, per second, through my relayhost?
Danil Smirnov:
> On Thu, Sep 1, 2022 at 1:27 PM Wietse Venema wrote:
>
> > There is a missing colon: the syntax is randmap:{list...}
>
> Great! It works now. :) Thank you, Wietse.
>
> Is it possible to confirm that the approach is working in the postfix logs?
Look at the time stamps.
grep relay=your.isp.example /var/log/maillog |
awk '{ print $1, $2, $3 }' | uniq -c
This prints the number of recipients per second. If you have
single-recipient messages, that is also the number of messages sent
per second.
The awk program assumes that your logfile is formatted as
Sep 1 00:01:05 ...
Wietse
Re: How to send 10 messages, per second, through my relayhost?
On Thu, Sep 1, 2022 at 1:27 PM Wietse Venema wrote:
> There is a missing colon: the syntax is randmap:{list...}
>
Great! It works now. :) Thank you, Wietse.
Is it possible to confirm that the approach is working in the postfix logs?
They look just the same way as without
"sender_dependent_default_transport_maps" parameter...
Danil
Re: How to send 10 messages, per second, through my relayhost?
Danil Smirnov:
> Hi!
>
> On Wed, Feb 23, 2022 at 7:01 PM Wietse Venema wrote:
>
> > Short answer:
> >
> > Use randmap to select from 10 delivery agents.
> >
> > sender_dependent_default_transport_maps = randmap{smtp1:, smtp2:, ...}
There is a missing colon: the syntax is randmap:{list...}
Wietse
Re: How to send 10 messages, per second, through my relayhost?
Hi!
On Wed, Feb 23, 2022 at 7:01 PM Wietse Venema wrote:
> Short answer:
>
> Use randmap to select from 10 delivery agents.
>
> sender_dependent_default_transport_maps = randmap{smtp1:, smtp2:, ...}
>
> Use rate delays of 1s.
>
> smtp1_transport_rate_delay = 1s
> smtp2_transport_rate_delay = 1s
>
I tried to follow this advice but with no luck.
Could you explain please how to configure those delivery agents smtp1,
smtp2, ... in the same postfix instance?
I tried
postconf -M smtp1/unix="smtp1 unix - - n - -
smtp"
postconf -M smtp2/unix="smtp2 unix - - n - -
smtp"
but then I have an error
postfix | Sep 01 08:05:20 test
postfix/trivial-rewrite[190]: error: unsupported dictionary type:
randmap{smtp1
postfix | Sep 01 08:05:20 test
postfix/trivial-rewrite[190]: warning: randmap{smtp1:, smtp2:} is
unavailable. unsupported dictionary type: randmap{smtp1
postfix | Sep 01 08:05:20 test
postfix/trivial-rewrite[190]: warning: randmap{smtp1:, smtp2:} lookup error
for "email@redacted"
postfix | Sep 01 08:05:20 test
postfix/trivial-rewrite[190]: warning:
sender_dependent_default_transport_maps lookup failure
My postfix version is version 3.6.4.
Sincerely,
Danil Smirnov
Re: relayhost per-server wrappermode setting
On 20.08.22 03:43, Wietse Venema wrote: Maybe you have chroot turned on in master.cf? You're right, that was the issue. Thanks for the hint! That is NOT POSTFIX. And neither did I claim it was - I was just showing that it could be an issue of my postfix configuration because it worked with my previous MUA, as shown by the logs :) -- witcher signature.asc Description: PGP signature
Re: relayhost per-server wrappermode setting
witcher: > Aug 19 23:02:43 portable-navi postfix/smtp[385223]: 2190C1428ED: > to=, relay=none, delay=585, delays=585/0.11/0/0, > dsn=4.4.3, status=deferred (Host or domain name not found. Name service > error for name=smtp.example.com type=MX: Host not found, try again) That is Postfix. Maybe you have chroot turned on in master.cf? postconf -F "*/unix/chroot=no" postfix reload > This is a weird error as sending with `msmtp` seems to work fine, which > is using `smtp.example.com` as well: > ``` > Aug 19 23:09:53 host=smtp.example.com tls=on auth=on user=mail > from=m...@example.com recipients=m...@example.com mailsize=121 > smtpstatus=250 smtpmsg='250 2.0.0 Ok: queued as B22D3A524795' > exitcode=EX_OK That is NOT POSTFIX. Wietse
Re: relayhost per-server wrappermode setting
On 19.08.22 09:48, Matus UHLAR - fantomas wrote: sender_dependent_default_transport_maps allows specifying transport, with some limits I see! It *seems* to use the correct transport for the server now, but now I'm getting another error: ``` Aug 19 23:02:43 portable-navi postfix/smtp[385223]: 2190C1428ED: to=, relay=none, delay=585, delays=585/0.11/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=smtp.example.com type=MX: Host not found, try again) ``` This is a weird error as sending with `msmtp` seems to work fine, which is using `smtp.example.com` as well: ``` Aug 19 23:09:53 host=smtp.example.com tls=on auth=on user=mail from=m...@example.com recipients=m...@example.com mailsize=121 smtpstatus=250 smtpmsg='250 2.0.0 Ok: queued as B22D3A524795' exitcode=EX_OK ``` Any ideas? Thank you very much for your help so far! -- witcher signature.asc Description: PGP signature
Re: relayhost per-server wrappermode setting
On 19.08.22 02:12, Matus UHLAR - fantomas wrote: you can define multiple transports in master.cf and use them if you need different client settings. That's interesting, thank you for the tip and example configuration! so you can use transport like "smtpssl:" in your *relayhost_maps: smtpssl unix - - y - - smtp -o smtp_tls_wrappermode=yes -o smtp_tls_security_level=encrypt On 19.08.22 21:01, witcher wrote: I'll be using the following example as the server I'm configuring is using STARTTLS: smtpstarttls unix - - y - - smtp -o smtp_tls_wrappermode=no -o smtp_tls_security_level=may I saw that the service name, here `smtpstarttls`, should be used in the following format in the sender_relay file specified with `sender_dependent_relayhost_maps` in main.cf: m...@example.comsmtpstarttls:[smtp.example.com]:587 The error I'm encountering is the following one, taken from the postfix logs: Aug 19 20:37:55 portable-navi postfix/smtp[360340]: fatal: valid hostname or network address required in server description: smtpstarttls:[smtp.example.com]:587 oh! http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps looks like sender_dependent_relayhost_maps requires just relayhost, not transport. It is also overridden with other settings, see the page above. sender_dependent_default_transport_maps allows specifying transport, with some limits: http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The early bird may get the worm, but the second mouse gets the cheese.
Re: relayhost per-server wrappermode setting
On 19.08.22 02:12, Matus UHLAR - fantomas wrote: you can define multiple transports in master.cf and use them if you need different client settings. That's interesting, thank you for the tip and example configuration! so you can use transport like "smtpssl:" in your *relayhost_maps: smtpssl unix - - y - - smtp -o smtp_tls_wrappermode=yes -o smtp_tls_security_level=encrypt I'll be using the following example as the server I'm configuring is using STARTTLS: ``` smtpstarttls unix - - y - - smtp -o smtp_tls_wrappermode=no -o smtp_tls_security_level=may ``` I saw that the service name, here `smtpstarttls`, should be used in the following format in the sender_relay file specified with `sender_dependent_relayhost_maps` in main.cf: ``` m...@example.comsmtpstarttls:[smtp.example.com]:587 ``` The error I'm encountering is the following one, taken from the postfix logs: ``` Aug 19 20:37:55 portable-navi postfix/smtp[360340]: fatal: valid hostname or network address required in server description: smtpstarttls:[smtp.example.com]:587 Aug 19 20:37:56 portable-navi postfix/qmgr[360216]: warning: private/smtp socket: malformed response Aug 19 20:37:56 portable-navi postfix/qmgr[360216]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description Aug 19 20:37:56 portable-navi postfix/master[360214]: warning: process /usr/lib/postfix/bin/smtp pid 360340 exit status 1 Aug 19 20:37:56 portable-navi postfix/master[360214]: warning: /usr/lib/postfix/bin/smtp: bad command startup -- throttling Aug 19 20:37:56 portable-navi postfix/error[360343]: 2BE0C1428EA: to=, relay=none, delay=1.1, delays=0.03/1.1/0/0.02, dsn=4.3.0, status=deferred (unknown mail transport error) ``` The mail is sent to and from `m...@example.com`. The above sender_relay file seems to be in the wrong format. How do I specify what service is being used for which relay correctly? -- witcher signature.asc Description: PGP signature
Re: relayhost per-server wrappermode setting
On 19.08.22 13:27, witcher wrote: I've set up Postfix for use as a relayhost, using multiple SMTP servers via `sender_dependent_relayhost_maps`. The issue I have is that one needs to use the settings `smtp_tls_security_level = encrypt` and `smtp_tls_wrappermode = yes`, while another one needs `smtp_tls_security_level = may` and `smtp_tls_wrappermode = no`. I configured `smtp_tls_security_level` per sender with `smtp_tls_policy_maps`, but can't seem to figure out what (if it exists at all) the attribute is called to set `smtp_tls_wrappermode` in the policy maps. It doesn't seem to be `wrappermode` and I can't find anything about what attributes are even supported here in the docs. you can define multiple transports in master.cf and use them if you need different client settings. the default "smtp" transport and "relay" transport for domains in relay_domains point to these: smtp unix - - y - - smtp relay unix - - y - - smtp -o syslog_name=postfix/$service_name # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 so you can use transport like "smtpssl:" in your *relayhost_maps: smtpssl unix - - y - - smtp -o smtp_tls_wrappermode=yes -o smtp_tls_security_level=encrypt -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
relayhost per-server wrappermode setting
Hello, I've set up Postfix for use as a relayhost, using multiple SMTP servers via `sender_dependent_relayhost_maps`. The issue I have is that one needs to use the settings `smtp_tls_security_level = encrypt` and `smtp_tls_wrappermode = yes`, while another one needs `smtp_tls_security_level = may` and `smtp_tls_wrappermode = no`. I configured `smtp_tls_security_level` per sender with `smtp_tls_policy_maps`, but can't seem to figure out what (if it exists at all) the attribute is called to set `smtp_tls_wrappermode` in the policy maps. It doesn't seem to be `wrappermode` and I can't find anything about what attributes are even supported here in the docs. Thank you in advance! -- witcher signature.asc Description: PGP signature
Re: Why does smtp ignore trivial-rewrite's next hop, replacing it with main.cf's relayhost or DNS-MX-resolution?
Am 08.07.2022 um 21:35 schrieb Viktor Dukhovni: On Fri, Jul 08, 2022 at 09:08:28PM +0200, Postfix-jtroendle wrote: submission/inet/rewrite_service_name = submission-rewrite Your mistake is believing that the trivial rewrite service setting in smtpd(8) can determine message routing. This is not the case. This only determines the address class for access control. Actual routing decisions are made by qmgr(8) when it contacts the default rewrite service. Whatever you're trying to do with "rewrite_service_name" is too clever, and either can be done more simply within a single Postfix instance, or requires a separate Postfix instance for submission, in which there's a dedicated qmgr(8) that uses the custom transport table. Thank you very much for your explanation, Viktor. I followed your second recommendation and set up a multi instance setup that works perfectly now. Jul 8 19:02:04 localhost postfix/submission/smtpd[106104]: warning: dict_nis_init: NIS domain name not set - NIS lookups disabled You should change local_recipient_maps or whatever default setting that is trying to do "nis". It was alias_maps with its default value. Fixed. Josef
Re: Why does smtp ignore trivial-rewrite's next hop, replacing it with main.cf's relayhost or DNS-MX-resolution?
On Fri, Jul 08, 2022 at 09:08:28PM +0200, Postfix-jtroendle wrote: > submission/inet/rewrite_service_name = submission-rewrite Your mistake is believing that the trivial rewrite service setting in smtpd(8) can determine message routing. This is not the case. This only determines the address class for access control. Actual routing decisions are made by qmgr(8) when it contacts the default rewrite service. Whatever you're trying to do with "rewrite_service_name" is too clever, and either can be done more simply within a single Postfix instance, or requires a separate Postfix instance for submission, in which there's a dedicated qmgr(8) that uses the custom transport table. > Jul 8 19:02:04 localhost postfix/submission/smtpd[106104]: warning: > dict_nis_init: NIS domain name not set - NIS lookups disabled You should change local_recipient_maps or whatever default setting that is trying to do "nis". On Fri, Jul 08, 2022 at 04:26:04PM +0200, Postfix-jtroendle wrote: > Jul 8 10:29:19 localhost postfix/submission-rewrite/trivial-rewrite[103626]: > maps_find: address_verify_transport_maps: > hash:/etc/postfix/transport_to_exo_domains(0,lock|no_regsub|fold_fix|utf8_request): > * = relay:[1.1.1.3] This is not a routing decision, see above. So it is not surprising that it does not do what you thought it does. Routing decisions are made by the queue manager each time a message enters the active queue, and not preselected at message ingestion. -- Viktor.
Re: Why does smtp ignore trivial-rewrite's next hop, replacing it with main.cf's relayhost or DNS-MX-resolution?
Goedenavond Wietse, your help is very much appreciated :) Am 08.07.2022 um 17:04 schrieb Wietse Venema: When will the queue manager ignore the nexthop from trivial-rewrite? The queue manager will override that nexthop when a destination is specified with REDIRECT or FILTER. Maybe I set up accidentally a REDIRECT or FILTER. postconf -n compatibility_level = 3.6 inet_protocols = ipv4 mydomain = mydomain.com myhostname = smarthost.mydomain.com mynetworks = 127.0.0.0/8 relayhost = [4.4.4.1] smtp_tls_note_starttls_offer = yes smtpd_tls_cert_file = /etc/ssl/certs/smarthost_mydomain_com-fullchain.crt smtpd_tls_key_file = /etc/ssl/private/smarthost_mydomain_com.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tls_random_prng_update_period = 3600s tls_random_source = dev:/dev/urandom postconf -P smtp/inet/content_filter = smtp/inet/mynetworks = /etc/postfix/exo_networks smtp/inet/smtp_tls_mandatory_ciphers = high smtp/inet/smtp_tls_mandatory_protocols = >=TLSv1.2 smtp/inet/smtp_tls_security_level = encrypt smtp/inet/smtpd_client_restrictions = permit_mynetworks,reject submission/inet/content_filter = submission/inet/rewrite_service_name = submission-rewrite submission/inet/smtp_tls_security_level = encrypt submission/inet/smtpd_client_restrictions = permit_sasl_authenticated,reject submission/inet/smtpd_sasl_auth_enable = yes submission/inet/smtpd_sasl_path = private/auth submission/inet/smtpd_sasl_security_options = noanonymous submission/inet/smtpd_sasl_tls_security_options = noanonymous submission/inet/smtpd_sasl_type = dovecot submission/inet/syslog_name = postfix/submission 2525/inet/content_filter = 2525/inet/mynetworks = 127.0.0.0/8,10.10.10.0/24,10.11.20.0/24,10.10.30.0/24 2525/inet/receive_override_options = no_unknown_recipient_checks,no_header_body_checks,no_milters 2525/inet/rewrite_service_name = from-relay-rewrite 2525/inet/smtpd_client_restrictions = 2525/inet/smtpd_helo_restrictions = 2525/inet/smtpd_recipient_restrictions = permit_mynetworks,reject 2525/inet/smtpd_relay_restrictions = 2525/inet/smtpd_sender_restrictions = submission-rewrite/unix/sender_dependent_relayhost_maps = hash:/etc/postfix/transport_to_senders_relay submission-rewrite/unix/syslog_name = postfix/submission-rewrite submission-rewrite/unix/transport_maps = hash:/etc/postfix/transport_to_exo_domains from-relay-rewrite/unix/relayhost = [mydomain-com02b.mail.protection.outlook.com] relay/unix/syslog_name = postfix/$service_name The services "smtp" and "2525" are only placeholders right now. I tried to get the "submission" service up and running first, that is where I went into the nexthop issue. The non-debug log of an e-mail from testa to testa is Jul 8 19:02:04 localhost postfix/submission/smtpd[106104]: warning: dict_nis_init: NIS domain name not set - NIS lookups disabled Jul 8 19:02:05 localhost postfix/submission/smtpd[106104]: connect from XYZ.dynamic.kabel-deutschland.de[188.194.X.Y] Jul 8 19:02:06 localhost postfix/submission/smtpd[106104]: Anonymous TLS connection established from XYZ.dynamic.kabel-deutschland.de[188.194.X.Y]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 Jul 8 19:02:08 localhost postfix/submission/smtpd[106104]: C9C5E4A99A: client=XYZ.dynamic.kabel-deutschland.de[188.194.X.Y], sasl_method=PLAIN, sasl_username=m...@mydomain.com Jul 8 19:02:08 localhost postfix/cleanup[106110]: C9C5E4A99A: message-id= Jul 8 19:02:08 localhost postfix/qmgr[106093]: C9C5E4A99A: from=, size=868, nrcpt=1 (queue active) Jul 8 19:02:08 localhost postfix/submission/smtpd[106104]: disconnect from XYZ.dynamic.kabel-deutschland.de[188.194.X.Y] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8 Jul 8 19:02:38 localhost postfix/smtp[106112]: connect to 4.4.4.1[4.4.4.1]:25: Connection timed out Jul 8 19:02:38 localhost postfix/smtp[106112]: C9C5E4A99A: to=, relay=none, delay=30, delays=0.07/0.01/30/0, dsn=4.4.1, status=deferred (connect to 4.4.4.1[4.4.4.1]:25: Connection timed out) Best regards, Josef
Re: Why does smtp ignore trivial-rewrite's next hop, replacing it with main.cf's relayhost or DNS-MX-resolution?
The Postfix SMTP client is not as smart as you appear to believe. It receives the nexthop from the queue manager. - If the nexthop from the queue manager is an [ipaddress] then the SMTP client uses that address. - If the nexthop from the queue manager is a domain name, then the SMTP client uses DNS (dpending on smtp_host_lookup configuration). When will the queue manager ignore the nexthop from trivial-rewrite? The queue manager will override that nexthop when a destination is specified with REDIRECT or FILTER. Insteead of debug logging, all we need is "postconf -n" command output, non-debug logging, and perhaps "postconf -P" command output. Based on that we can find out if any table queries are needed. Wietse
Why does smtp ignore trivial-rewrite's next hop, replacing it with main.cf's relayhost or DNS-MX-resolution?
Hello all,
I try to understand Postfix's relaying behaviour but I'm struggling with
the last guy in the chain called smtp. It simply ignores the decision of
his very smart precursor, named trivial-rewrite.
Inspecting the log, trivial-rewrite uses transport_maps and
sender_dependent_relayhost_maps to correctly identify 1.1.1.1 as next
hop. But then, managed by qmgr, smtp takes over and chooses either
4.4.4.1 (relayhost in main.cf) or resolves the next hop via DNS (if no
relayhost in main.cf):
Jul 8 10:29:19 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: maps_find:
address_verify_transport_maps:
hash:/etc/postfix/transport_to_exo_domains(0,lock|no_regsub|fold_fix|utf8_request):
* = relay:[1.1.1.3]
Jul 8 10:29:19 localhost
postfix/submission-rewrite/trivial-rewrite[103626]:
wildcard_{chan:hop}={relay:[1.1.1.3]}
Jul 8 10:29:19 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: maps_find:
transport_maps:
hash:/etc/postfix/transport_to_exo_domains(0,lock|no_regsub|fold_fix|utf8_request):
mydomain.com = relay:[1.1.1.1]
Jul 8 10:29:19 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: mail_addr_find:
te...@mydomain.com -> relay:[1.1.1.1]
Jul 8 10:29:19 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: `' ->
`te...@mydomain.com' -> (`relay' `[1.1.1.1]' `te...@mydomain.com' `4096')
Jul 8 10:29:19 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: send attr transport
= relay
Jul 8 10:29:19 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: send attr nexthop =
[1.1.1.1]
Jul 8 10:29:20 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: maps_find:
sender_dependent_relayhost_maps:
hash:/etc/postfix/transport_to_senders_relay(0,lock|no_regsub|fold_fix|utf8_request):
@mydomain.com = relay:[2.2.2.1]
Jul 8 10:29:20 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: mail_addr_find:
te...@mydomain.com -> relay:[2.2.2.1]
Jul 8 10:29:20 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: maps_find:
transport_maps:
hash:/etc/postfix/transport_to_exo_domains(0,lock|no_regsub|fold_fix|utf8_request):
mydomain.com = relay:[1.1.1.1]
Jul 8 10:29:20 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: mail_addr_find:
te...@mydomain.com -> relay:[1.1.1.1]
Jul 8 10:29:20 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: `te...@mydomain.com'
-> `te...@mydomain.com' -> (`relay' `[1.1.1.1]' `te...@mydomain.com' `4096')
Jul 8 10:29:20 localhost
postfix/submission-rewrite/trivial-rewrite[103626]: send attr nexthop =
[1.1.1.1]
# ---> So far, so perfect, but then smtp
goes wrong!
# If relayhost=[4.4.4.1] in main.cf
Jul 8 10:29:20 localhost postfix/smtp[103629]: smtp socket: wanted
attribute: nexthop
Jul 8 10:29:20 localhost postfix/smtp[103629]: input attribute name:
nexthop
Jul 8 10:29:20 localhost postfix/smtp[103629]: input attribute value:
[4.4.4.1]
Jul 8 10:29:20 localhost postfix/smtp[103629]: smtp_parse_destination:
[4.4.4.1] smtp
# Or without relayhost in main.cf, DNS resolution is used
Jul 8 10:26:07 localhost postfix/smtp[103317]: smtp socket: wanted
attribute: nexthop
Jul 8 10:26:07 localhost postfix/smtp[103317]: input attribute name:
nexthop
Jul 8 10:26:07 localhost postfix/smtp[103317]: input attribute value:
mydomain.com
Jul 8 10:26:07 localhost postfix/smtp[103317]: dns_query: mydomain.com
(MX): OK
Jul 8 10:26:07 localhost postfix/smtp[103317]: dns_get_answer: type MX
for mydomain.com
Jul 8 10:26:07 localhost postfix/smtp[103317]: smtp_addr_one: host
mydomain-com03c.mail.protection.outlook.com
As I read smtp.8.html and qmgr.8.html, I cannot overwrite smtp's nexthop
decision. If nexthop is set correctly by trivial-rewrite, what goes
wrong with smtp (or maybe qmgr)?
Thank you very much for your help.
Josef
Re: How to send 10 messages, per second, through my relayhost?
Russell Jones:
> > perhaps changing the delay to 0... why did you change it at all?
>
> Is setting it to 0 not allowing it to send out as quickly as possible with
> no delay at all?
>
> I set it to 1s because I was attempting to configure 10 messages per second
> (default_destination_concurrency_limit (10) *
> default_destination_rate_delay (1) = 10 per second).
>
>
> I'm clearly lost - how can I ensure 10 messages per second maximum sending
> rate? A delay of 0 doesn't compute for me.
>
Short answer:
Use randmap to select from 10 delivery agents.
sender_dependent_default_transport_maps = randmap{smtp1:, smtp2:, ...}
Use rate delays of 1s.
smtp1_transport_rate_delay = 1s
smtp2_transport_rate_delay = 1s
Wietse
-
Re: How to send 10 messages, per second, through my relayhost?
> perhaps changing the delay to 0... why did you change it at all? Is setting it to 0 not allowing it to send out as quickly as possible with no delay at all? I set it to 1s because I was attempting to configure 10 messages per second (default_destination_concurrency_limit (10) * default_destination_rate_delay (1) = 10 per second). I'm clearly lost - how can I ensure 10 messages per second maximum sending rate? A delay of 0 doesn't compute for me. On Wed, Feb 23, 2022 at 10:29 AM Matus UHLAR - fantomas wrote: > On 23.02.22 10:21, Russell Jones wrote: > >That configuration option only takes whole seconds - How can I achieve 10 > >messages per second with it? > > default_destination_rate_delay (default: 0s) > > perhaps changing the delay to 0... why did you change it at all? > > > >On Wed, Feb 23, 2022 at 10:12 AM Yves-Marie Le Pors Chauvel < > >ym.leporschau...@ccmbenchmark.com> wrote: > >> You have to change your default_destination_rate_delay, as said in the > >> documentation : > >> > >> *The default amount of delay that is inserted between individual message > >> deliveries to the same destination and over the same message delivery > >> transport.* > >> > >> So, in your case, it sends only 1 message every second. > > 1 message every second per 1 connection, with > default_destination_concurrency_limit=10 it should mean up to 10 messages > per second. > > > >> Le mer. 23 févr. 2022 à 17:08, Russell Jones a > >> écrit : > >>> I am struggling to understand why my postfix configuration is not > >>> allowing me to send 10 messages per second through my configured > relayhost. > >>> When watching the logs, it is sending 1 message per second. > >>> > >>> initial_destination_concurrency = 10 > >>> default_destination_concurrency_limit = 10 > >>> default_destination_rate_delay = 1s > >>> > >>> smtpinetn - n - - smtpd -o > >>> smtpd_sasl_auth_enable=no -o myhostname=mail.example.com > >>> > >>> > >>> To me, this is saying "send 10 messages every 1 second". To Postfix, > this > >>> doesn't seem to be happening. > >>> > >>> Could I have some help with gaining some insight into what I'm missing? > > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > Due to unexpected conditions Windows 2000 will be released > in first quarter of year 1901 >
Re: How to send 10 messages, per second, through my relayhost?
On 23.02.22 10:21, Russell Jones wrote: That configuration option only takes whole seconds - How can I achieve 10 messages per second with it? default_destination_rate_delay (default: 0s) perhaps changing the delay to 0... why did you change it at all? On Wed, Feb 23, 2022 at 10:12 AM Yves-Marie Le Pors Chauvel < ym.leporschau...@ccmbenchmark.com> wrote: You have to change your default_destination_rate_delay, as said in the documentation : *The default amount of delay that is inserted between individual message deliveries to the same destination and over the same message delivery transport.* So, in your case, it sends only 1 message every second. 1 message every second per 1 connection, with default_destination_concurrency_limit=10 it should mean up to 10 messages per second. Le mer. 23 févr. 2022 à 17:08, Russell Jones a écrit : I am struggling to understand why my postfix configuration is not allowing me to send 10 messages per second through my configured relayhost. When watching the logs, it is sending 1 message per second. initial_destination_concurrency = 10 default_destination_concurrency_limit = 10 default_destination_rate_delay = 1s smtpinetn - n - - smtpd -o smtpd_sasl_auth_enable=no -o myhostname=mail.example.com To me, this is saying "send 10 messages every 1 second". To Postfix, this doesn't seem to be happening. Could I have some help with gaining some insight into what I'm missing? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Due to unexpected conditions Windows 2000 will be released in first quarter of year 1901
Re: How to send 10 messages, per second, through my relayhost?
Thanks! That configuration option only takes whole seconds - How can I achieve 10 messages per second with it? On Wed, Feb 23, 2022 at 10:12 AM Yves-Marie Le Pors Chauvel < ym.leporschau...@ccmbenchmark.com> wrote: > Hi Russel, > > You have to change your default_destination_rate_delay, as said in the > documentation : > > *The default amount of delay that is inserted between individual message > deliveries to the same destination and over the same message delivery > transport.* > > So, in your case, it sends only 1 message every second. > > Regards, > YM > > Le mer. 23 févr. 2022 à 17:08, Russell Jones a > écrit : > >> Hi all, >> >> I am struggling to understand why my postfix configuration is not >> allowing me to send 10 messages per second through my configured relayhost. >> When watching the logs, it is sending 1 message per second. >> >> initial_destination_concurrency = 10 >> default_destination_concurrency_limit = 10 >> default_destination_rate_delay = 1s >> >> smtpinetn - n - - smtpd -o >> smtpd_sasl_auth_enable=no -o myhostname=mail.example.com >> >> >> To me, this is saying "send 10 messages every 1 second". To Postfix, this >> doesn't seem to be happening. >> >> Could I have some help with gaining some insight into what I'm missing? >> >> Thanks! >> >> > > -- > Yves-Marie LE PORS-CHAUVEL > Email Product Manager > *T: +33 2 23 45 57 99* (3043) > 23, rue du Bignon - 35 135 Chantepie > www.ccmbenchmark.com >
Re: How to send 10 messages, per second, through my relayhost?
Hi Russel, You have to change your default_destination_rate_delay, as said in the documentation : *The default amount of delay that is inserted between individual message deliveries to the same destination and over the same message delivery transport.* So, in your case, it sends only 1 message every second. Regards, YM Le mer. 23 févr. 2022 à 17:08, Russell Jones a écrit : > Hi all, > > I am struggling to understand why my postfix configuration is not allowing > me to send 10 messages per second through my configured relayhost. When > watching the logs, it is sending 1 message per second. > > initial_destination_concurrency = 10 > default_destination_concurrency_limit = 10 > default_destination_rate_delay = 1s > > smtpinetn - n - - smtpd -o > smtpd_sasl_auth_enable=no -o myhostname=mail.example.com > > > To me, this is saying "send 10 messages every 1 second". To Postfix, this > doesn't seem to be happening. > > Could I have some help with gaining some insight into what I'm missing? > > Thanks! > > -- Yves-Marie LE PORS-CHAUVEL Email Product Manager *T: +33 2 23 45 57 99* (3043) 23, rue du Bignon - 35 135 Chantepie www.ccmbenchmark.com
How to send 10 messages, per second, through my relayhost?
Hi all, I am struggling to understand why my postfix configuration is not allowing me to send 10 messages per second through my configured relayhost. When watching the logs, it is sending 1 message per second. initial_destination_concurrency = 10 default_destination_concurrency_limit = 10 default_destination_rate_delay = 1s smtpinetn - n - - smtpd -o smtpd_sasl_auth_enable=no -o myhostname=mail.example.com To me, this is saying "send 10 messages every 1 second". To Postfix, this doesn't seem to be happening. Could I have some help with gaining some insight into what I'm missing? Thanks!
Re: Mail bypassing relayhost configuration
On Tue, Oct 26, 2021 at 09:05:46PM +, Cooper, Robert A wrote: > Posftinger output: > https://gist.github.com/racooper/a560c84080e2ee6c336d508918344f5a Please avoid paste bins in the future. Also where are the (couple of) requested log entries that show the problem behaviour? compatibility_level = 2 header_checks = pcre:/etc/postfix/header_checks Any FILTER directives in header_checks? relayhost = [smtp-relay.site.com]:25 This applies to all remote destinations where the transport table does not set an explicit nexthop. smtp_connection_reuse_count_limit = 1 This is needlessly tight. smtpd_sender_restrictions = hash:/etc/postfix/reject_sender Any FILTER directives there? smtpd_tls_CApath = /etc/ssl/certs/ not useful unless you're using "smtpd_tls_ask_ccert". smtpd_tls_eecdh_grade = strong This is now obsolete, better to use "auto". smtpd_tls_exclude_ciphers = aNULL, DES, MD5, 3DES, RC4, eNULL, DES+MD5 With the cipher grade set to "high", you don't need to worry about DES (LOW) or RC4 (medium). And with OpenSSL newer than 1.0.2, even 3DES is no longer "high", and 3DES TLS ciphers may even be disabled at compile-time by default. smtpd_tls_fingerprint_digest = sha1 if you don't have tables with explicitly trusted sha1 hashes of client certs, "sha256" would be a better choice, this is the default in Postfix 3.6, provided you set the compatibility level to 3.6, see: http://www.postfix.org/COMPATIBILITY_README.html smtpd_tls_mandatory_protocols = TLSv1, !SSLv2, !SSLv3 This is very much not a good idea: http://www.postfix.org/postconf.5.html#smtpd_tls_protocols[ With Postfix < 3.6 there is no support for a minimum or maximum version, and the protocol range is configured via protocol exclusions. To require at least TLS 1.0, set "smtpd_tls_protocols = !SSLv2, !SSLv3". Listing the protocols to include, rather than protocols to exclude, is supported, but not recommended. The exclusion form more accurately matches the underlying OpenSSL interface. instead (given you have Postfix 3.6) use (no whitespace after ">="): smtpd_tls_protocols = >=TLSv1 smtpd_tls_mandatory_protocols = >=TLSv1.2 Session tickets have largely obsoleted server side session caches: smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache just leave this empty. smtp_host_lookup = dns, native You really should avoid "native". transport_maps = hash:/etc/postfix/error_transport What's in the "compiled" file, run "postmap -s hash:error_transport" to be sure. --master.cf-- xerox unix - - n - - smtp -o relayhost= -o content_filter= Setting relayhost and content_filter here has no effect. > I am not finding anywhere in our configuration where email.site.com is > set to use an alternate transport. This is where your logs are key to further understanding what happened. -- Viktor.
Re: Mail bypassing relayhost configuration
(sorry for top-posting. OWA is evil in that way.) Posftinger output: https://gist.github.com/racooper/a560c84080e2ee6c336d508918344f5a Contents of error_transport (the only defined transport_map): fxgfd.com error:undeliverable yahoo.es.comerror:undeliverable site.co error:undeliverable I am not finding anywhere in our configuration where email.site.com is set to use an alternate transport. This is a grep through the postfix config for any entry of our domain. Nothing there stands out as a transport config. # cd /etc/postfix # grep -i site * main.cf:mydomain = syse.site.com main.cf:relayhost = [smtp-relay.site.com]:25 main.cf:virtual_alias_maps = ldap:/etc/postfix/site.ldap main.cf:smtpd_sasl_local_domain = site.com main.cf:smtp_helo_name = relay.site.com main.cf:smtpd_banner = relay.site.com ESMTP ($myhostname) main.cf:smtpd_tls_cert_file = /etc/letsencrypt/live/mail-1p-out-t1.syse.site.com/fullchain.pem main.cf:smtpd_tls_key_file = /etc/letsencrypt/live/mail-1p-out-t1.syse.site.com/privkey.pem smtp_header_checks:/^Received: from .*? \(.+? \[([\.\d:a-f]+)\]\).+\(Authenticated sender: (\w.+)@.*site.com\).+by mail-1p-out-[tw][12].syse.site.com \(Postfix\) .*/m REPLACE X-site-Auth: $2 ($1) smtp_header_checks:/^Received: from .*? \(.+? \[([\.\d:a-f]+)\]\).+\(Authenticated sender: (\w.+)@.*site.com\).+by mail-1p-out-[tw][12].syse.site.com \(Postfix\) .*/m INFO site.ldap:server_host=ldap://mailroute.site.com:389 site.ldap:search_base=ou=mail,dc=sites,dc=com site.ldap:domain=site.com I would appreciate any other insights; I've been over this many times today and have not found any reason that relayhost is being bypassed. RobertC From: owner-postfix-us...@postfix.org on behalf of Viktor Dukhovni Sent: Tuesday, October 26, 2021 12:22 To: postfix-users@postfix.org Subject: Re: Mail bypassing relayhost configuration This message is from an External Sender This message came from outside your organization -- On Tue, Oct 26, 2021 at 04:22:53PM +, Cooper, Robert A wrote: > Howdy! We have noticed that certain email going through our outbound > relay are ignoring the "relayhost = [smtp-relay.site.com]:25". Sorry, that's not possible. The delivery of messages for *all* recipients uses the same transport resolution logic, which defaults remote destinations to relayhost, barring explicit transport table overrides, sender-dependent settings, ... > The condition seems to be when a message has an envelope rewrite based > on LDAP lookup (specifically, from site.com to email.site.com, which > goes to gmail). Then clearly you have explicit transport settings for "email.site.com". > After the lookup and rewrite, Postfix appears to do an MX lookup to > try and send directly to google and ignores the specified relayhost. Because you have a transport entry for the recipient domain. > Is there something else I'm missing? I've verified that there are no > transports designated for mail.site.com that would override the > relayhost. Is it "mail.site.com" or "email.site.com"? In either case, you clearly do have such transport settings, so look harder. https://urldefense.com/v3/__http://www.postfix.org/DEBUG_README.html*mail__;Iw!!KwNVnqRv!VLTy5aV89Fx-Lf1_nhFoiVwAnjprN7L6Ui06_pAx8fsZ5z1CPDebLngjOKuakVW_$ For more detailed help include "postconf -nf" output in your reply (without any rewrapping of lines). Also include one or two log entries for relevant messages, with at most the localparts of email addresses obfuscated. Do not change the domain names, if they are sufficiently sensitive to not posted here, you'll need to find help elsewhere on a commercial basis. -- Viktor.
Re: Mail bypassing relayhost configuration
On Tue, Oct 26, 2021 at 04:22:53PM +, Cooper, Robert A wrote: > Howdy! We have noticed that certain email going through our outbound > relay are ignoring the "relayhost = [smtp-relay.site.com]:25". Sorry, that's not possible. The delivery of messages for *all* recipients uses the same transport resolution logic, which defaults remote destinations to relayhost, barring explicit transport table overrides, sender-dependent settings, ... > The condition seems to be when a message has an envelope rewrite based > on LDAP lookup (specifically, from site.com to email.site.com, which > goes to gmail). Then clearly you have explicit transport settings for "email.site.com". > After the lookup and rewrite, Postfix appears to do an MX lookup to > try and send directly to google and ignores the specified relayhost. Because you have a transport entry for the recipient domain. > Is there something else I'm missing? I've verified that there are no > transports designated for mail.site.com that would override the > relayhost. Is it "mail.site.com" or "email.site.com"? In either case, you clearly do have such transport settings, so look harder. http://www.postfix.org/DEBUG_README.html#mail For more detailed help include "postconf -nf" output in your reply (without any rewrapping of lines). Also include one or two log entries for relevant messages, with at most the localparts of email addresses obfuscated. Do not change the domain names, if they are sufficiently sensitive to not posted here, you'll need to find help elsewhere on a commercial basis. -- Viktor.
Mail bypassing relayhost configuration
Howdy! We have noticed that certain email going through our outbound relay are ignoring the "relayhost = [smtp-relay.site.com]:25". The condition seems to be when a message has an envelope rewrite based on LDAP lookup (specifically, from site.com to email.site.com, which goes to gmail). After the lookup and rewrite, postfix appears to do an MX lookup to try and send directly to google and ignores the specified relayhost. Is there something else I'm missing? I've verified that there are no transports designated for mail.site.com that would override the relayhost. Postfix version 3.6.2 from ghettoforge repo on CentOS 7. Thanks, RobertC
Re: Override relayhost by MX
Dnia 6.05.2021 o godz. 16:37:29 Vytenis Adm pisze: > > Indeed. We were thinking about this as well. I was secretly hoping > there's a built-in solution, avoiding any development. I would say your case is very unusual, so it's unlikely that there would be a built-in solution. You must create something for yourself. Builtin solutions exist for typical cases. Usually people who use relayhost do know which domains are their local domains (so they should not be handled via relayhost), and have control over this. On the other hand, if you are serving multiple domains that users have full control over, you usually send mail directly and not via relayhost. In both cases there's no issue. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: Override relayhost by MX
On 2021-05-06 15:56, Jaroslaw Rafa wrote: Dnia 6.05.2021 o godz. 14:07:55 Vytenis Adm pisze: Yes, we did look into it, and it's not an option. "transport_maps" looks into a DB, and we can't rely on it. Clients can point MX to their own servers, and "transport_maps" will route to our MX regardless of what is set in customer's DNS. "transport_maps" looks into a *map*, and a map in Postfix is more than just DB. For example it can be a *TCP table*, which means Postfix is asking some program that listens on a specific port for the key, and gets a value in return. It is described here: http://www.postfix.org/tcp_table.5.html Seems like this can be a solution for you. You have of course to write the appropriate program that replies with the correct server address depending on recipient's email adress. Indeed. We were thinking about this as well. I was secretly hoping there's a built-in solution, avoiding any development. "check_recipient_mx_access " with "FILTER" is 100% what we needed, but unfortunately it has some gotchas. -- Vytenis
Re: Override relayhost by MX
Thanks Matus for taking time to respond. Appreciated. On 2021-05-06 14:34, Matus UHLAR - fantomas wrote: On 06.05.21 10:37, Vytenis Adm wrote: We have a postfix server, which forwards all customer's outbound emails to a "relayhost". Our "relayhost" is somewhat costly, so our goal is to minimize it's usage. MX is served by separate Postfix instance. Our goal is to deliver local emails to our MX directly, bypassing "relayhost". Several clients are sharing the infrastructure, so querying DB to see whether the domain is local is tricky: this may lead to abuse when the domain changes ownership, or emails delivered locally when MX is remote, as some customers have their own NS. "check_recipient_mx_access" option looked promising. On 2021-05-06 12:42, Matus UHLAR - fantomas wrote: this applies for incoming mail, not outgoing. On 06.05.21 14:07, Vytenis Adm wrote: Outbound (SMTP-AUTH) Postfix instance receives mail from our users, so it's inbound email from Postfix perspective. "check_recipient_mx_access" can override relay based on DNS MX record, but it has issues I mentioned in my original posting. Looked promising though. check_recipient_mx_access will allow your server to accept mail for a domain but has completele no effect on how mail for that domain is to be delivered. That's what I mean it applies for incoming mail. Maybe I wasn't too specific about "check_recipient_mx_access". What we tried (and it was working in most cases), is set it like this: smtpd_recipient_restrictions = <...> check_recipient_mx_access hash:/etc/postfix/smtpd_recipient_restrictions /etc/postfix/smtpd_recipient_restrictions: ourmx1.example.com FILTER smtp:[ourmx1.example.com] That way all outbound emails containing "ourmx1.example.com" DNS MX would use transport "smtp:[ourmx1.example.com]", and fallback to "relayhost". Unfortunately, if client had their own MX set as a higher priority one, emails were forwarded to "smtp:[ourmx1.example.com]". Also emails containing multiple recipients would be forwarded to "smtp:[ourmx1.example.com]" as well. We had to abandon this idea, as promising as it seemed. Unfortunately, some clients have our MX as a secondary, and "check_recipient_mx_access" ignores the fact that primary MX is remote. Also, it ignores the fact that emails contain remote addresses in CC Option we're considering is using a DNS response rewriting. If the MX is not matching as a local one - rewrite it to "relayhost". This sounds like a dirty hack however. Maybe there are other options or ideas? tried looking at transport_maps ? http://www.postfix.org/postconf.5.html#transport_maps you should be able to configure where to send mail to different domains, and "relayhost" would only be applied for default mail Yes, we did look into it, and it's not an option. "transport_maps" looks into a DB, and we can't rely on it. Clients can point MX to their own servers, and "transport_maps" will route to our MX regardless of what is set in customer's DNS. the "DB" can be local file or even inline in postfix configuration. you can configure domain to go through its MX server, see: http://www.postfix.org/transport.5.html TL;DR: we don't know which domain's emails should be forwarded via DNS MX to our inbound Postfix, and which to "relayhost" - that's the issue. The only source of truth is DNS MX records themselves. Here's an example : Two our clients are using our mail system, have the following domains: "client1domain.tld" and "client2domain.tld" If we set "relayhost" (as it is set now), all (local or not) emails are sent via "relayhost": al...@client1domain.tld -> our-outbound-SMTP->relayhost -> ourmx1.example.com ->b...@client1domain.tld al...@client1domain.tld -> our-outbound-SMTP->relayhost -> mx.gmail.com ->b...@gmail.com We can follow your suggestion and define a "transport_map" that forwards all "client1domain.tld" bound emails to "ourmx1.example.com" directly, bypassing DNS - that's easy and doable: client1domain.tld smtp:[ourmx1.example.com] Then all is working nicely: al...@client1domain.tld -> our-outbound-SMTP -> ourmx1.example.com ->b...@client1domain.tld Now imagine "client1domain.tld" owner changes their MX to "competitormx1.example.com", and our second client is sending an email to b...@client1domain.tld How it should be relayed: al...@client2domain.tld -> our-outbound-SMTP ->relayhost -> competitormx1.example.com ->b...@client1domain.tld How it it would be relayed: al...@client2domain.tld -> our-outbound-SMTP -> ourmx1.example.com ->b...@client1domain.tld (Email does NOT reach it's destination on "competitormx1.example.com" !!) Hope this makes sense :) -- Vytenis
Re: Override relayhost by MX
> On May 6, 2021, at 8:56 AM, Jaroslaw Rafa wrote: > > "transport_maps" looks into a *map*, and a map in Postfix is more than just > DB. For example it can be a *TCP table*, which means Postfix is asking some > program that listens on a specific port for the key, and gets a value in > return. It is described here: http://www.postfix.org/tcp_table.5.html > > Seems like this can be a solution for you. You have of course to write the > appropriate program that replies with the correct server address depending > on recipient's email adress. The socketmap table driver makes it possible to handle multiple logical tables at a single server endpoint: http://www.postfix.org/socketmap_table.5.html It is otherwise very similar to tcp_table(5). See http://cr.yp.to/proto/netstrings.txt for the encoding details. -- Viktor.
Re: Override relayhost by MX
Dnia 6.05.2021 o godz. 14:07:55 Vytenis Adm pisze: > > Yes, we did look into it, and it's not an option. "transport_maps" > looks into a DB, and we can't rely on it. Clients can point MX to > their own servers, and "transport_maps" will route to our MX > regardless of what is set in customer's DNS. "transport_maps" looks into a *map*, and a map in Postfix is more than just DB. For example it can be a *TCP table*, which means Postfix is asking some program that listens on a specific port for the key, and gets a value in return. It is described here: http://www.postfix.org/tcp_table.5.html Seems like this can be a solution for you. You have of course to write the appropriate program that replies with the correct server address depending on recipient's email adress. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: Override relayhost by MX
On 06.05.21 10:37, Vytenis Adm wrote: We have a postfix server, which forwards all customer's outbound emails to a "relayhost". Our "relayhost" is somewhat costly, so our goal is to minimize it's usage. MX is served by separate Postfix instance. Our goal is to deliver local emails to our MX directly, bypassing "relayhost". Several clients are sharing the infrastructure, so querying DB to see whether the domain is local is tricky: this may lead to abuse when the domain changes ownership, or emails delivered locally when MX is remote, as some customers have their own NS. "check_recipient_mx_access" option looked promising. On 2021-05-06 12:42, Matus UHLAR - fantomas wrote: this applies for incoming mail, not outgoing. On 06.05.21 14:07, Vytenis Adm wrote: Outbound (SMTP-AUTH) Postfix instance receives mail from our users, so it's inbound email from Postfix perspective. "check_recipient_mx_access" can override relay based on DNS MX record, but it has issues I mentioned in my original posting. Looked promising though. check_recipient_mx_access will allow your server to accept mail for a domain but has completele no effect on how mail for that domain is to be delivered. That's what I mean it applies for incoming mail. Unfortunately, some clients have our MX as a secondary, and "check_recipient_mx_access" ignores the fact that primary MX is remote. Also, it ignores the fact that emails contain remote addresses in CC Option we're considering is using a DNS response rewriting. If the MX is not matching as a local one - rewrite it to "relayhost". This sounds like a dirty hack however. Maybe there are other options or ideas? tried looking at transport_maps ? http://www.postfix.org/postconf.5.html#transport_maps you should be able to configure where to send mail to different domains, and "relayhost" would only be applied for default mail Yes, we did look into it, and it's not an option. "transport_maps" looks into a DB, and we can't rely on it. Clients can point MX to their own servers, and "transport_maps" will route to our MX regardless of what is set in customer's DNS. the "DB" can be local file or even inline in postfix configuration. you can configure domain to go through its MX server, see: http://www.postfix.org/transport.5.html -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The early bird may get the worm, but the second mouse gets the cheese.
Re: Override relayhost by MX
On 2021-05-06 12:42, Matus UHLAR - fantomas wrote: On 06.05.21 10:37, Vytenis Adm wrote: We have a postfix server, which forwards all customer's outbound emails to a "relayhost". Our "relayhost" is somewhat costly, so our goal is to minimize it's usage. MX is served by separate Postfix instance. Our goal is to deliver local emails to our MX directly, bypassing "relayhost". Several clients are sharing the infrastructure, so querying DB to see whether the domain is local is tricky: this may lead to abuse when the domain changes ownership, or emails delivered locally when MX is remote, as some customers have their own NS. "check_recipient_mx_access" option looked promising. this applies for incoming mail, not outgoing. Outbound (SMTP-AUTH) Postfix instance receives mail from our users, so it's inbound email from Postfix perspective. "check_recipient_mx_access" can override relay based on DNS MX record, but it has issues I mentioned in my original posting. Looked promising though. Unfortunately, some clients have our MX as a secondary, and "check_recipient_mx_access" ignores the fact that primary MX is remote. Also, it ignores the fact that emails contain remote addresses in CC Option we're considering is using a DNS response rewriting. If the MX is not matching as a local one - rewrite it to "relayhost". This sounds like a dirty hack however. Maybe there are other options or ideas? tried looking at transport_maps ? http://www.postfix.org/postconf.5.html#transport_maps you should be able to configure where to send mail to different domains, and "relayhost" would only be applied for default mail Yes, we did look into it, and it's not an option. "transport_maps" looks into a DB, and we can't rely on it. Clients can point MX to their own servers, and "transport_maps" will route to our MX regardless of what is set in customer's DNS.
Re: Override relayhost by MX
On 06.05.21 10:37, Vytenis Adm wrote: We have a postfix server, which forwards all customer's outbound emails to a "relayhost". Our "relayhost" is somewhat costly, so our goal is to minimize it's usage. MX is served by separate Postfix instance. Our goal is to deliver local emails to our MX directly, bypassing "relayhost". Several clients are sharing the infrastructure, so querying DB to see whether the domain is local is tricky: this may lead to abuse when the domain changes ownership, or emails delivered locally when MX is remote, as some customers have their own NS. "check_recipient_mx_access" option looked promising. this applies for incoming mail, not outgoing. Unfortunately, some clients have our MX as a secondary, and "check_recipient_mx_access" ignores the fact that primary MX is remote. Also, it ignores the fact that emails contain remote addresses in CC Option we're considering is using a DNS response rewriting. If the MX is not matching as a local one - rewrite it to "relayhost". This sounds like a dirty hack however. Maybe there are other options or ideas? tried looking at transport_maps ? http://www.postfix.org/postconf.5.html#transport_maps you should be able to configure where to send mail to different domains, and "relayhost" would only be applied for default mail -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Saving Private Ryan... Private Ryan exists. Overwrite? (Y/N)
Override relayhost by MX
Hi list, We have a postfix server, which forwards all customer's outbound emails to a "relayhost". Our "relayhost" is somewhat costly, so our goal is to minimize it's usage. MX is served by separate Postfix instance. Our goal is to deliver local emails to our MX directly, bypassing "relayhost". Several clients are sharing the infrastructure, so querying DB to see whether the domain is local is tricky: this may lead to abuse when the domain changes ownership, or emails delivered locally when MX is remote, as some customers have their own NS. "check_recipient_mx_access" option looked promising. Unfortunately, some clients have our MX as a secondary, and "check_recipient_mx_access" ignores the fact that primary MX is remote. Also, it ignores the fact that emails contain remote addresses in CC Option we're considering is using a DNS response rewriting. If the MX is not matching as a local one - rewrite it to "relayhost". This sounds like a dirty hack however. Maybe there are other options or ideas? Thanks in advance! -- Vytenis
Re: "default_transport = smtp:relay" vs "relayhost = relay"
IL Ka: > > > > Yes, "relayhost" also affects the routing of mail to "relay_domains". > > > > Thank you, Viktor. > > I see: "relay_domains" -> "relay_transport". > "relayhost" affects both: default_transport and relay_transport Indeed. The interactions between these parameters are documented in the postconf(5) manpage. That includes descriptions of how one parameter can override other parameters. http://www.postfix.org/postconf.5.html#relayhost http://www.postfix.org/postconf.5.html#default_transport http://www.postfix.org/postconf.5.html#relay_transport ... and more. Wietse
Re: "default_transport = smtp:relay" vs "relayhost = relay"
> > Yes, "relayhost" also affects the routing of mail to "relay_domains". > > Thank you, Viktor. I see: "relay_domains" -> "relay_transport". "relayhost" affects both: default_transport and relay_transport
Re: "default_transport = smtp:relay" vs "relayhost = relay"
On Wed, May 05, 2021 at 02:20:30AM +0300, IL Ka wrote: > Does there any difference between setting "relayhost" and > default_transport smtp with explicit next hop? Yes, "relayhost" also affects the routing of mail to "relay_domains". -- Viktor.
"default_transport = smtp:relay" vs "relayhost = relay"
Hello, Does there any difference between setting "relayhost" and default_transport smtp with explicit next hop? Ilya.
Re: Deliver mail of a local subnet only to the virtual mailbox but prevent relay via relayhost
On Mon, Mar 01, 2021 at 11:14:57AM +0100, Jaap Gordijn wrote: > relayhost = aaa.bbb.ccc:25 > virtual_mailbox_domains = xxx.yyy.zzz > virtual_transport = lmtp:unix:private/dovecot-lmtp > > I would like to achieve the following > - mail of all subnets in my LAN is relayed if nesessary (so not for the > virtual domain). To accomplish this, I have listed all my subnets under > mynetworks. This works > - restrict the delivery of a particular subnet, 192.168.80.0/24 only to the > virtual domain so forbid further relay via the relayhost > > How to accomplish this? I can not remove the 192.168.80.0/24 from mynetworks > because then the email is not delivered to the virtual domain too. Postfix *by default* allows delivery to your domains from any source, *without* listing that source in mynetworks. # This denies access to send outbound mail to remote domains # unless the client is in mynetworks. # It does not deny inbound mail to your own domains! # smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks, # # The default setting is a cautious "defer_unauth_destination", # but a production configuration should promptly change this to # the below: # reject_unauth_destionation If not listing a subnet in mynetworks blocks delivery to a domain listed in any of: - mydestination - virtual_alias_doamins - virtual_mailbox_domains - relay_domains then you have a configuration error. -- Viktor.
Re: Deliver mail of a local subnet only to the virtual mailbox but prevent relay via relayhost
On 1 Mar 2021, at 5:14, Jaap Gordijn wrote: For my local mailserver with postfix/dovecot and virtual domains set up as follows: relayhost = aaa.bbb.ccc:25 virtual_mailbox_domains = xxx.yyy.zzz virtual_transport = lmtp:unix:private/dovecot-lmtp I would like to achieve the following - mail of all subnets in my LAN is relayed if nesessary (so not for the virtual domain). To accomplish this, I have listed all my subnets under mynetworks. This works - restrict the delivery of a particular subnet, 192.168.80.0/24 only to the virtual domain so forbid further relay via the relayhost How to accomplish this? I can not remove the 192.168.80.0/24 from mynetworks because then the email is not delivered to the virtual domain too. One approach would be to put a restriction to block that subnet into smtpd_relay_restrictions BEFORE permit_mynetworks. Another possibility would be to remove that subnet from mynetworks and use a restriction class to allow clients on that subnet to send mail to the virtual domain. Saying which of those would be a better fit for your config would require you to provide more information, as described at http://www.postfix.org/DEBUG_README.html#mail -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Deliver mail of a local subnet only to the virtual mailbox but prevent relay via relayhost
For my local mailserver with postfix/dovecot and virtual domains set up as follows: relayhost = aaa.bbb.ccc:25 virtual_mailbox_domains = xxx.yyy.zzz virtual_transport = lmtp:unix:private/dovecot-lmtp I would like to achieve the following - mail of all subnets in my LAN is relayed if nesessary (so not for the virtual domain). To accomplish this, I have listed all my subnets under mynetworks. This works - restrict the delivery of a particular subnet, 192.168.80.0/24 only to the virtual domain so forbid further relay via the relayhost How to accomplish this? I can not remove the 192.168.80.0/24 from mynetworks because then the email is not delivered to the virtual domain too. Thanks. -- Jaap
Re: Conditional relayhost based on message size
Demi M. Obenour: > >> I am not sure whether adding such a feature motivated by just the > >> presented use-case is warranted. > > > > My take: not if it only solves only one problem. > > I agree. In particular, we should avoid a pile of features with very > narrow use-cases. I think that this narrow problem can/should be solved with a combination of smtp_delivery_status_filter that changes 5XX message size errors into 4XX, plus an smtp_fallback_relay with more generous size limits. Or just use that fallback relay all the time. Wuetse
Re: Conditional relayhost based on message size
On 1/16/21 5:12 PM, Wietse Venema wrote: > Viktor Dukhovni: >> On Sat, Jan 16, 2021 at 04:48:22AM -0500, Viktor Dukhovni wrote: >> >>> On Sat, Jan 16, 2021 at 08:14:34AM +, Alexander wrote: >>> >>>> My goal is to conditionally select the relayhost based on the total size >>>> of the outgoing message. The rationale is that I'm using Amazon AWS SES >>>> for the most part. Alas, SES only accepts messages up to 10 MB in size >>>> (this includes images and attachments that are part of the message), and >>>> when the outgoing message exceeds that size, it will be bounced. >>>> >>>> Any tips for filters or tools that would help me define another >>>> relayhost based on the outgoing message size would be greatly >>>> appreciated! >>> >>> Since the queue manager has no mechanism for size-dependent selection of >>> a default transport (with the help of trivial-rewrite), the only way >>> handle this deterministically in Postfix is to shunt large messages into >>> a separate instance, which can be done in a number of ways, but is not >>> particularly simple or elegant. >> >> For this to be naturally supported in Postfix, we'd need a new feature, >> namely a variant of "FILTER" that overrides *just* the default_transport, >> making it possible to use more general criteria than "sender-dependent" >> for default_transport selection. >> >> Possible design: >> >> 1. New access(5) verb taking an associated transport value that >> triggers such an override. >> 2. New queue-file record type holding the default-transport >> override. >> 3. Queue manager loads this record into memory in the same way >> as "FILTER". If both are present, "FILTER" wins. >> 4. Queue manager sends its value along with all trivial-rewrite >> "resolve" requests. >> 5. trivial-rewrite uses this default transport rather than >> $default_transport when the destination domain is not >> in any of the more specific address classes, and there >> is no explicit transport(5) mapping for the recipient. >> >> This would be primarily useful only when using a relayhost, subject to >> secondary criteria to divert some messages to a different transport >> and/or nexthop based on ad-hoc message features detected during >> message reception. The difference from "FILTER" is that messages >> to local recipients are not affected. >> >> I am not sure whether adding such a feature motivated by just the >> presented use-case is warranted. > > My take: not if it only solves only one problem. I agree. In particular, we should avoid a pile of features with very narrow use-cases. > For example, I have several notes on making the scheduling (within > a delivery transport) dependent on a concept of 'cost', which could > be one "number of delivery requests with similar sender or domain", > "message size", "number of delivery requests with similar receiver > or domain", or some weighted combination. Just compute a cost and > schedule as appropriate for that cost bucket. > > If we make routing dependent on message properties, we could take > a page from trivial-rewrite which has two flavors of routing, one > for probes and one for non-probes. We could have N flavors of > routing and select the flavor based on the weighted computation of > something. > > Wietse Personally, I would like to be able to control this via a plugin of some sort. Declarative configuration is awesome, but it eventually reaches its limits. Would the existing milter system be a good fit for this? If not, I wonder if an embedded Lua interpreter would be a good idea. Lua is *tiny* (much smaller than Postfix itself), extremely portable, and reasonably fast for an interpreted language. There is also LuaJIT, which is extremely fast, while still being smaller than Postfix. Embedding an interpreter would allow users to express their business rules in a full programming language, rather than being limited to what Postfix supports natively. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: Conditional relayhost based on message size
On 16 Jan 2021, at 02:48, Viktor Dukhovni wrote: > Since the queue manager has no mechanism for size-dependent selection of > a default transport Postfix does, however, know the size of the message based if it is over or under the message_size_limit, and it must know that before the message hits the question manager, right? Mightn't it be possible to hook into that size check pre-queue without. Great deal of faff? -- C code. C code run. Run, code, run.
Re: Conditional relayhost based on message size
Viktor Dukhovni: > On Sat, Jan 16, 2021 at 04:48:22AM -0500, Viktor Dukhovni wrote: > > > On Sat, Jan 16, 2021 at 08:14:34AM +, Alexander wrote: > > > > > My goal is to conditionally select the relayhost based on the total size > > > of the outgoing message. The rationale is that I'm using Amazon AWS SES > > > for the most part. Alas, SES only accepts messages up to 10 MB in size > > > (this includes images and attachments that are part of the message), and > > > when the outgoing message exceeds that size, it will be bounced. > > > > > > Any tips for filters or tools that would help me define another > > > relayhost based on the outgoing message size would be greatly > > > appreciated! > > > > Since the queue manager has no mechanism for size-dependent selection of > > a default transport (with the help of trivial-rewrite), the only way > > handle this deterministically in Postfix is to shunt large messages into > > a separate instance, which can be done in a number of ways, but is not > > particularly simple or elegant. > > For this to be naturally supported in Postfix, we'd need a new feature, > namely a variant of "FILTER" that overrides *just* the default_transport, > making it possible to use more general criteria than "sender-dependent" > for default_transport selection. > > Possible design: > > 1. New access(5) verb taking an associated transport value that > triggers such an override. > 2. New queue-file record type holding the default-transport > override. > 3. Queue manager loads this record into memory in the same way > as "FILTER". If both are present, "FILTER" wins. > 4. Queue manager sends its value along with all trivial-rewrite > "resolve" requests. > 5. trivial-rewrite uses this default transport rather than > $default_transport when the destination domain is not > in any of the more specific address classes, and there > is no explicit transport(5) mapping for the recipient. > > This would be primarily useful only when using a relayhost, subject to > secondary criteria to divert some messages to a different transport > and/or nexthop based on ad-hoc message features detected during > message reception. The difference from "FILTER" is that messages > to local recipients are not affected. > > I am not sure whether adding such a feature motivated by just the > presented use-case is warranted. My take: not if it only solves only one problem. For example, I have several notes on making the scheduling (within a delivery transport) dependent on a concept of 'cost', which could be one "number of delivery requests with similar sender or domain", "message size", "number of delivery requests with similar receiver or domain", or some weighted combination. Just compute a cost and schedule as appropriate for that cost bucket. If we make routing dependent on message properties, we could take a page from trivial-rewrite which has two flavors of routing, one for probes and one for non-probes. We could have N flavors of routing and select the flavor based on the weighted computation of something. Wietse
Re: Conditional relayhost based on message size
On Sat, Jan 16, 2021 at 04:48:22AM -0500, Viktor Dukhovni wrote: > On Sat, Jan 16, 2021 at 08:14:34AM +, Alexander wrote: > > > My goal is to conditionally select the relayhost based on the total size > > of the outgoing message. The rationale is that I'm using Amazon AWS SES > > for the most part. Alas, SES only accepts messages up to 10 MB in size > > (this includes images and attachments that are part of the message), and > > when the outgoing message exceeds that size, it will be bounced. > > > > Any tips for filters or tools that would help me define another > > relayhost based on the outgoing message size would be greatly > > appreciated! > > Since the queue manager has no mechanism for size-dependent selection of > a default transport (with the help of trivial-rewrite), the only way > handle this deterministically in Postfix is to shunt large messages into > a separate instance, which can be done in a number of ways, but is not > particularly simple or elegant. For this to be naturally supported in Postfix, we'd need a new feature, namely a variant of "FILTER" that overrides *just* the default_transport, making it possible to use more general criteria than "sender-dependent" for default_transport selection. Possible design: 1. New access(5) verb taking an associated transport value that triggers such an override. 2. New queue-file record type holding the default-transport override. 3. Queue manager loads this record into memory in the same way as "FILTER". If both are present, "FILTER" wins. 4. Queue manager sends its value along with all trivial-rewrite "resolve" requests. 5. trivial-rewrite uses this default transport rather than $default_transport when the destination domain is not in any of the more specific address classes, and there is no explicit transport(5) mapping for the recipient. This would be primarily useful only when using a relayhost, subject to secondary criteria to divert some messages to a different transport and/or nexthop based on ad-hoc message features detected during message reception. The difference from "FILTER" is that messages to local recipients are not affected. I am not sure whether adding such a feature motivated by just the presented use-case is warranted. -- Viktor.
Re: Conditional relayhost based on message size
On Sat, Jan 16, 2021 at 08:14:34AM +, Alexander wrote: > My goal is to conditionally select the relayhost based on the total size > of the outgoing message. The rationale is that I'm using Amazon AWS SES > for the most part. Alas, SES only accepts messages up to 10 MB in size > (this includes images and attachments that are part of the message), and > when the outgoing message exceeds that size, it will be bounced. > > Any tips for filters or tools that would help me define another > relayhost based on the outgoing message size would be greatly > appreciated! Since the queue manager has no mechanism for size-dependent selection of a default transport (with the help of trivial-rewrite), the only way handle this deterministically in Postfix is to shunt large messages into a separate instance, which can be done in a number of ways, but is not particularly simple or elegant. The simplest is perhaps to allow the message to route to AWS, where it would typically rejected in response to "MAIL FROM" when Postfix announces the message size, and to map that response to a tempfail, at which point the message would go the SMTP fallback relay for the transport, but this can be complex if amazon publishes many IP addresses for their submission service, since Postfix would try those first and may give up after a small number of connections. You'd therefore need to also ensure that the AWS relay resolves to just 1 IP address. That could be done with Python hooks in unbound, or a static IP (bypassing live DNS) that's updated out of band. If you want to take the second instance route, then it may be simplest to place large messages on hold, and within the same filesystem, move messages from the hold queue to the incoming queue of the second instance. Alternatively, an SMTP content_filter could dynamically choose the reinjection port based on message size, but you'd need to implement such an SMTP proxy. Finally, you could always try Exim. For sufficiently exotic requirements, though I'm generally loathe to recomment a complex monolithic MTA with a spotty security track record, it does offer a lot more conditional logic in its mail processing pipeline. You might even use Exim as a content_filter for Postfix, and have Postfix ultimately deliver the outbound message, with Exim routing the message to one of two Postfix instances. Though it is rather overkill if all you want is a size-dependent SMTP switch. -- Viktor.
Conditional relayhost based on message size
Hello, My goal is to conditionally select the relayhost based on the total size of the outgoing message. The rationale is that I'm using Amazon AWS SES for the most part. Alas, SES only accepts messages up to 10 MB in size (this includes images and attachments that are part of the message), and when the outgoing message exceeds that size, it will be bounced. Any tips for filters or tools that would help me define another relayhost based on the outgoing message size would be greatly appreciated! Alex
Re: "relayhost configuration problem" / "unable to look up host" when I can, in fact, look up the host
On Thu, Dec 10, 2020 at 02:56:17PM -0500, Viktor Dukhovni wrote: > On Thu, Dec 10, 2020 at 05:33:46AM -0800, Jon Leech wrote: > > > The only meaningful messages in the mail logs were > > > > Dec 10 00:01:58 celly postfix/smtp[21050]: warning: relayhost configuration > > problem > > Dec 10 00:01:58 celly postfix/smtp[21050]: send attr reason = unable to > > look up host mail.sonic.net: Name or service not known > > Is the "smtp" transport using "chroot" in master.cf? It is. > > I can nslookup, dig (either A or MX records), telnet to port > > 587, etc. on mail.sonic.net, so it's not a general system DNS issue. > > Are your tests performed as "root" or as an unprivileged user? As an unprivileged user. > The chroot is always the Postfix queue directory, typically > /var/spool/postfix. And its use is specified in the "chroot" column of > the master.cf service definition. Aha, it is. NetworkManager thoughtfully erased everything from /var/spool/postfix/etc/resolv.conf shortly before these problems began, which almost certainly explains the problem. I despise NM. > A Debian update? No. But IIRC, Comcast went down for a while and I switched to tethering via my phone for data around that time, and did have to restore /etc/resolv.conf. I had no idea about the chroot resolv.conf. Thanks very much! Jon P.S. I despise NM.
Re: "relayhost configuration problem" / "unable to look up host" when I can, in fact, look up the host
On Thu, Dec 10, 2020 at 05:33:46AM -0800, Jon Leech wrote: > The only meaningful messages in the mail logs were > > Dec 10 00:01:58 celly postfix/smtp[21050]: warning: relayhost configuration > problem > Dec 10 00:01:58 celly postfix/smtp[21050]: send attr reason = unable to look > up host mail.sonic.net: Name or service not known Is the "smtp" transport using "chroot" in master.cf? > I can nslookup, dig (either A or MX records), telnet to port > 587, etc. on mail.sonic.net, so it's not a general system DNS issue. Are your tests performed as "root" or as an unprivileged user? > The postfix FAQ sort of touches on this scenario in FAQs 52 and 53, > but about all I can make of that is that it might be running in a chroot > without the right resolv.conf or other resource to do a name lookup. If > that's true, any ideas on how I can figure out where the chroot is? The chroot is always the Postfix queue directory, typically /var/spool/postfix. And its use is specified in the "chroot" column of the master.cf service definition. > And why this behavior would have suddenly started happening, without > any changes in my local configuration (that I initiated, at least, and > I don't have any auto-updates configured)? A Debian update? > I also have a query in to Sonic as to whether anything might have > changed on their end - they are Linux-friendly, and even the front-line > support people tend to be clueful. Upstream is unlikely to be at issue. Not DNSSEC-signed, but no issues otherwise: https://dnsviz.net/d/mail.sonic.net/dnssec/ Best to not nag them with local issues on your end. -- Viktor.
Re: "relayhost configuration problem" / "unable to look up host" when I can, in fact, look up the host
DNS lookups are done by SYSTEM LIBRARY functions, and these log nothing no matter how you twiddle Postfix options. Postfix is the messenger of bad news; don't blame the messenger. Consider using strace (see http://www.postfix.org/DEBUG_README.html) and find out what if you have a 'missing file' or 'filer permission' permission problem. Wietse
"relayhost configuration problem" / "unable to look up host" when I can, in fact, look up the host
I'm using postfix 3.4.14-0+deb10u1 as the MTA on my Debian machine, with disable_dns_lookups = yes relayhost [mail.sonic.net]:587 This has worked fine for many years until on 12/3, without any changes in my local OS / postfix configuration, it started failing to deliver mail to the relayhost - which I only found out about 5 days later when the default maximal_queue_lifetime expired. The only meaningful messages in the mail logs were Dec 10 00:01:58 celly postfix/smtp[21050]: warning: relayhost configuration problem Dec 10 00:01:58 celly postfix/smtp[21050]: send attr reason = unable to look up host mail.sonic.net: Name or service not known I cranked the debug level in master.cf up to 3 '-v's resulting in lots of log messages, but no more details of *why* it was "unable to look up". I can nslookup, dig (either A or MX records), telnet to port 587, etc. on mail.sonic.net, so it's not a general system DNS issue. The postfix FAQ sort of touches on this scenario in FAQs 52 and 53, but about all I can make of that is that it might be running in a chroot without the right resolv.conf or other resource to do a name lookup. If that's true, any ideas on how I can figure out where the chroot is? And why this behavior would have suddenly started happening, without any changes in my local configuration (that I initiated, at least, and I don't have any auto-updates configured)? Finally, is there any way to crank postfix's verbosity up to a level where it would actually explain why and/or where it's getting these errors? It would be nice if it would tell me something about *why* there is a "relayhost configuration problem", in particular. I also have a query in to Sonic as to whether anything might have changed on their end - they are Linux-friendly, and even the front-line support people tend to be clueful. Thanks, Jon Leech oddh...@sonic.net
Re: how do I pass thru incomplete destination email addr to relayhost for 'To' rewrite?
Matthew Patton wrote: > > Why send mail as user@myhostname, when the named host will never > > ever receive email? > > Because I need to retain FROM what host it originated. If I see an > email from root@domain I have no idea which host it came from. In my mailer I would immediately look at the Received: header trail of the message. And also the Message-Id: of the message. Both of those would tell me the server that originated the message. > The emails are cron scripts and the like, not user-generated email. In the spirit of sharing... I think I have a very similar environment. I have many machines. Cron sends emails with the output of cronjobs. Emails are sent by cron using mailx. It's a very traditional Unix environment. I read mail from within that environment and there is no site hiding for mail from these servers to my mailbox. I see the full unique hostname. Such as r...@misery.proulx.com or some such. It is being transported directly from the server to my mailbox. Since I am not reading mail at Gmail or elsewhere. For servers within my main environment but sending mail outside of it I have a relay host where outgoing mail from there to the world will be masqueraded as the domain. However I exclude root mail from that masquerading. (masquerade_exceptions = root) Therefore when these automated messages come through from root I get the full hostname on the message such as r...@torment.proulx.com or some such. Depending upon the destination this will either be allowed (inbound mail) or most often it will be blocked (outbound mail) due to not having a global public DNS for that name. That's okay. If it is blocked it is because it was a mistake and I didn't mean to send outbound mail. But I sometimes forget when a buddy and I are both sharing work on a system. For servers randomly placed on the Internet but sending mail back to my main mailbox (inbound mail) I typically connect a VPN back from there to my main mail relay. Therefore mail from a remote VM enters my mail relay via a permitted network. mynetworks = ... smtpd_recipient_restrictions = permit_mynetworks, ... Therefore the mail is allowed through due to using the VPN for transport. Also the mail is always encrypted over the VPN. Also all of the authentication and authorization is handled by the VPN and not needed to be worried about on the SMTP email side. For me this is a simpler strategy. I am not sending mail back to r...@despair.proulx.com or wherever. Those random servers will be configured to listen on the loopback device only. (inet_interfaces = loopback-only) They only originate mail but never receive it. For a VPN this could be a full OpenVPN setup. Or an ssh+autossh port forwarded tunnel. Or other such as an stunnel. I prefer one of the first two. Whatever is simplest. This works well for me. Something like this might be a good strategy to use. It's a good strategy for me. If I were reading mail offsite at a 3rd party such as Gmail then I would need to modify this so that I did not exclude root mail from site hiding masquerading. This would mean that all outgoing mail from root would have a From address as originating from the domain not the specific host. In which case to identify the mail I would need to look at the message headers (Show original message...) in the mailer. That would show me the Received: and Message-id: headers and I would use that to identify the system. Hope this helps! Bob
Re: how do I pass thru incomplete destination email addr to relayhost for 'To' rewrite?
Patton, Matthew [Contractor]:
> > Why send mail as user@myhostname, when the named host will never
> > ever receive email?
>
> Because I need to retain FROM what host it originated. If I see
> an email from root@domain I have no idea which host it came from.
> The emails are cron scripts and the like, not user-generated email.
> If 'origin' only affected the FROM and left the TO naked as was
> specified on the command-line, I'd be happy as a clam.
Postfix does not support 'bare' addresses, because they are ambiguous,
especially when folks like you want them to mean different things
for a sender or recipent. Not gonna happen.
You could however do this on the end systems:
/etc/postfix/main.cf:
myorigin = $myhostname
virtual_alias_maps = inline:{@$myhostname=@example.com}
/etc/postfix/main.cf:
myorigin = $myhostname
recipient_canonical_maps = inline:{@$myhostname=@example.com}
Both will use bare-sen...@host.example.com as sender, and
bare-recipi...@example.com as recipient.
The second form will also rewrite recipients in the message header.
Wietse
Re: how do I pass thru incomplete destination email addr to relayhost for 'To' rewrite?
On Sun, Aug 16, 2020 at 01:58:16AM +, Patton, Matthew [Contractor] wrote: > > Why send mail as user@myhostname, when the named host will never > > ever receive email? > > Because I need to retain FROM what host it originated. If I see an email from > root@domain I have no idea which host it came from. The emails are cron > scripts and the like, not user-generated email. > If 'origin' only affected the FROM and left the TO naked as was specified on > the command-line, I'd be happy as a clam. See: http://www.postfix.org/MULTI_INSTANCE_README.html#quick -- Viktor.
RE: how do I pass thru incomplete destination email addr to relayhost for 'To' rewrite?
> Why send mail as user@myhostname, when the named host will never > ever receive email? Because I need to retain FROM what host it originated. If I see an email from root@domain I have no idea which host it came from. The emails are cron scripts and the like, not user-generated email. If 'origin' only affected the FROM and left the TO naked as was specified on the command-line, I'd be happy as a clam.
Re: how do I pass thru incomplete destination email addr to relayhost for 'To' rewrite?
Wietse Venema: > >Patton, Matthew [Contractor]: > > On a regular sending host I have set 'myhostname' (because logical > > hostname differs from the system-level nee AWS autogenerated > > hostname), 'myorigin=$myhostname' (Postfix default) and > > Why send mail as user@myhostname, when the named host will never > ever receive email? You can avoid a lot of complication by using a > myorigin setting that specifies a domain name, and MX records for > that domain that point to a suitable mailhub. > > myorigin = example.com > > And perhaps even > > relayhost = example.com I did not respond to the remainder of $SUBJECT because it suggests attempt to solve the wrong problem. Wietse
Re: how do I pass thru incomplete destination email addr to relayhost for 'To' rewrite?
>Patton, Matthew [Contractor]: > On a regular sending host I have set 'myhostname' (because logical > hostname differs from the system-level nee AWS autogenerated > hostname), 'myorigin=$myhostname' (Postfix default) and Why send mail as user@myhostname, when the named host will never ever receive email? You can avoid a lot of complication by using a myorigin setting that specifies a domain name, and MX records for that domain that point to a suitable mailhub. myorigin = example.com And perhaps even relayhost = example.com Wietse
how do I pass thru incomplete destination email addr to relayhost for 'To' rewrite?
On a regular sending host I have set 'myhostname' (because logical hostname differs from the system-level nee AWS autogenerated hostname), 'myorigin=$myhostname' (Postfix default) and 'relayhost=[1.2.3.4]' but 'mydestination' does NOT include $myhostname. I want the relayhost to be the sole repository of rewrite rules. When I use the mailx tool on a regular host and compose a message to 'root' both the FROM and TO are written as 'root@$myorigin'. This means that at the relayhost I have to include every known host in the 'mydestination' list so that it will then consult /etc/aliases (or Cononical maps) and change the TO value of 'root | root@domain | root@source_hostname' to 'realaccount@someother_domain'. For a handful of machines this is not a problem. 1. What to do when it's a dynamic set or many hosts? 2. I would like the 'TO' to either remain a naked/incomplete 'root' or at worst 'root@mydomain' when it leaves the source machines, but I can't lose the FROM address being fully qualified as 'root@myhostname.mydomain'. In other words, "don't attempt local delivery ever, and if FROM is incomplete, tack on '@$origin'. What combination of settings permits that? The configuration on the source host needs to be as trivial as possible. 3. At the relayhost should I use 'remote_header_rewrite = mydomain.com' or is that dangerous? Should I instead use 'local_header_rewrite_clients = permit_mynetworks' which will convert incomplete TO addresses (eg. 'root') to 'root@myorigin'? Are the results then fed to the Canonical maps? 4. instead of using /etc/aliases on the relayhost (local delivery is not intended) I should probably use something more efficient like Cononical maps. 5. Should there be no Cononical mapping at the relayhost, it looks like I need to set 'local_recipient_maps =' and 'luser_relay = bounce+$user@localhost' so the relayhost squelches returns and bounces for supposedly local destination. Does that sound correct?
Re: LMTP Relayhost
relay_transport is not for smarthosts. It is for domains that match $relay_domains, i.e. the relay class. WQietse Viktor Dukhovni: > Or FWIW, either or both of: > > default_transport = lmtp:mail.example.com > relay_transport = lmtp:mail.example.com > > depending on whether the messages to delivered via LMTP are just the > inbound traffic, or truly "all mail", even bounces to the original > sender, ... > > > On Jul 25, 2019, at 4:32 PM, Wietse Venema wrote: > > > > default_transport = lmtp > > relayhost = [mail.example.com] > > -- > Viktor. > >
Re: LMTP Relayhost
Or FWIW, either or both of: default_transport = lmtp:mail.example.com relay_transport = lmtp:mail.example.com depending on whether the messages to delivered via LMTP are just the inbound traffic, or truly "all mail", even bounces to the original sender, ... > On Jul 25, 2019, at 4:32 PM, Wietse Venema wrote: > > default_transport = lmtp > relayhost = [mail.example.com] -- Viktor.
Re: LMTP Relayhost
Matthias Schneider: > Hi, > > is it possible to configure a LMTP only server as relayhost= in postfix? > > I'd like to relay all mails to my local lmtp server Yes. default_transport = lmtp relayhost = [mail.example.com] Wietse
LMTP Relayhost
Hi, is it possible to configure a LMTP only server as relayhost= in postfix? I'd like to relay all mails to my local lmtp server Best Regards, MS
Re: Sending bounce notification via a relayhost
I?ve also tried sender_dependent_relayhost_maps, it didn?t work. Bounces have the EMPTY envelope sender address, not MAILER-DAEMON. Instead you need to match on <>: empty_address_relayhost_maps_lookup_key (default: <>) The sender_dependent_relayhost_maps search string that will be used instead of the null sender address. Thanks a lot, it works like a charm... Nico
