[pfx] E-mail delivery problem
Good day to all! So I have just had another look at my e-mail server regarding my situation, and I found something very odd. Postfix seems to be unable to send e-mail to IPv4 addresses, but it can send e-mail to IPv6 addresses. This is odd because Postfix is configured to use an IPv4 interface only, and its even more odd that the interface is a PPTP VPN tunnel which PPTP doesn't even support IPv6! What the ?!?!?!?! Here is an extract of my mail log, demonstrating what I mean: Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: warning: hostname generalpurpose does not resolve to address 192.168.2.2 Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: connect from unknown[192.168.2.2] Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: 2616D80098: client=unknown[192.168.2.2] Apr 12 23:05:39 generalpurpose postfix/cleanup[3568]: 2616D80098: message-id=<13a7d177-u778-3a84-3egd-19283c859...@example.com> Apr 12 23:05:39 generalpurpose postfix/qmgr[2241]: 2616D80098: from=, size=1966, nrcpt=1 (queue active) Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: disconnect from unknown[192.168.2.2] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 Apr 12 23:06:16 generalpurpose postfix/smtp[3569]: connect to pechora1.icann.org[192.0.33.71]:25: Connection timed out Apr 12 23:06:42 generalpurpose postfix/smtp[3569]: 2616D80098: to=, relay=pechora3.icann.org[2620:0:2830:201::1:73]:25, delay=64, delays=0.04/0.04/62/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 0463C7002623) Apr 12 23:06:42 generalpurpose postfix/qmgr[2241]: 2616D80098: removed I have also attached my 'main.cf' configuration file. Sincerely, Kolusion main.cf Description: Binary data ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: E-mail delivery problem
Good day, On mar, 2023-05-02 at 09:19 +0200, Kolusion K via Postfix-users wrote: > > Postfix seems to be unable to send e-mail to IPv4 addresses, but it > can send e-mail to IPv6 addresses. So, your machine running Postfix *has* a global IPv6 address. > This is odd because Postfix is configured to use an IPv4 interface > only, Wrong! The las line in your attachment (very uncomfortable way for sharing information that need quoting), states: inet_protocols = all You need to have a thorugh read of Postfix documentation. > and its even more odd that the interface is a PPTP VPN tunnel which > PPTP doesn't even support IPv6! You are reaching the IPv6 host *directly*. Many ISPs are now offering IPv6 because of the IPv4 exhaustion and all the problems associated with Carrier Grade NAT. > Here is an extract of my mail log, demonstrating what I mean: > > Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: warning: hostname > generalpurpose does not resolve to address 192.168.2.2 > Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: connect from > unknown[192.168.2.2] > Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: 2616D80098: > client=unknown[192.168.2.2] > Apr 12 23:05:39 generalpurpose postfix/cleanup[3568]: 2616D80098: > message-id=<13a7d177-u778-3a84-3egd-19283c859...@example.com> > Apr 12 23:05:39 generalpurpose postfix/qmgr[2241]: 2616D80098: > from=, size=1966, nrcpt=1 (queue active) > Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: disconnect from > unknown[192.168.2.2] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 > commands=7 > Apr 12 23:06:16 generalpurpose postfix/smtp[3569]: connect to > pechora1.icann.org[192.0.33.71]:25: Connection timed out > Apr 12 23:06:42 generalpurpose postfix/smtp[3569]: 2616D80098: > to=, > relay=pechora3.icann.org[2620:0:2830:201::1:73]:25, delay=64, > delays=0.04/0.04/62/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued > as 0463C7002623) > Apr 12 23:06:42 generalpurpose postfix/qmgr[2241]: 2616D80098: > removed This is clear proof that your exit route over IPv4 has port 25 blocked, at leas to pechora1.icann.org[192.0.33.71] > I have also attached my 'main.cf' configuration file. Why don't you simply cut and paste the text, like you have done with the log, reducing the time others have to spend helping you? Just show/check the output of "ip a" if you are on Linux, please, you will be surprised. Have a good day. -- Victoriano Giralt Innovation Director Digital Transformation Vicerectorate University of Malaga +34952131415 SPAIN == Note: signature.asc is the electronic signature of present message A: Yes. > Q: Are you sure ? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email ? signature.asc Description: This is a digitally signed message part ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: E-mail delivery problem
On Tue, 2 May 2023, Victoriano Giralt via Postfix-users wrote: [very good information and advice] Just show/check the output of "ip a" if you are on Linux, please, you will be surprised. Maybe also add "ip r", as this would clarify whether the default route is the VPN or not (and apparently, it isn't). Cheers. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: E-mail delivery problem
"Wrong! The las line in your attachment (very uncomfortable way for sharing information that need quoting), states: inet_protocols = all You need to have a thorugh read of Postfix documentation." Why is it uncomfortable? No I don't need to read the documentation. There is a problem with Postfix. Postfix is configured to use one interface 192.168.2.2. Why is it not binding to '192.168.2.2'? "You are reaching the IPv6 host *directly*. Many ISPs are now offering IPv6 because of the IPv4 exhaustion and all the problems associated with Carrier Grade NAT." YOU ARE RIGHT! YOU ARE NOT GOING TO BELIEVE THIS! IPv6 port 25 is NOT blocked! I always assume that because my ISP blocks IPv4 port 25, then IPv6 port 25 would be blocked as well! But it is not blocked! Is this customary for ISP's to block IPv4 port 25 but not IPv6 port 25? > Here is an extract of my mail log, demonstrating what I mean: > > Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: warning: hostname > generalpurpose does not resolve to address 192.168.2.2 > Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: connect from > unknown[192.168.2.2] > Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: 2616D80098: > client=unknown[192.168.2.2] > Apr 12 23:05:39 generalpurpose postfix/cleanup[3568]: 2616D80098: > message-id=<13a7d177-u778-3a84-3egd-19283c859...@example.com> > Apr 12 23:05:39 generalpurpose postfix/qmgr[2241]: 2616D80098: > from=, size=1966, nrcpt=1 (queue active) > Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: disconnect from > unknown[192.168.2.2] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 > commands=7 > Apr 12 23:06:16 generalpurpose postfix/smtp[3569]: connect to > pechora1.icann.org[192.0.33.71]:25: Connection timed out > Apr 12 23:06:42 generalpurpose postfix/smtp[3569]: 2616D80098: > to=, > relay=pechora3.icann.org[2620:0:2830:201::1:73]:25, delay=64, > delays=0.04/0.04/62/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued > as 0463C7002623) > Apr 12 23:06:42 generalpurpose postfix/qmgr[2241]: 2616D80098: > removed This is clear proof that your exit route over IPv4 has port 25 blocked, at leas to pechora1.icann.org[192.0.33.71] This I already know. This is why I use a VPN (192.168.2.2). My home server connects to my VPS via VPN, and the VPS forwards my traffic and vise versa. "Why don't you simply cut and paste the text, like you have done with the log, reducing the time others have to spend helping you?" Because some people don't like it. Why do you complain a lot? Never mind. So, why is Postfix not using the network interface 192.168.2.2? Thank you. You have lead me to also discovering my MX record is incorrect. I tried to find the IPv6 MX record to test my IPv6 port 25, and learnt there is no such thing. MX records point to a domain, and then it gets either a A or record. I have my server IP address as the MX record! This will be why some people have problems delivering mail to me! Sincerely, Kolusion ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Njal.la
Hi, my hosting Njal.la don't permit send email from my postfix server port number 25 to prevent spam. But they say that i can use this setup https://njal.la/docs/postfix-smarthost/ with; relayhost = [emailserver.tld]:submission in /etc/postfix/main.cf My log say bad configuration in relayhost and that don't find record. Somebody can i help me? Thanks, Cheers ¡ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Njal.la
May 2, 2023 at 4:42 PM, "pripercat--- via Postfix-users" wrote: > > Hi, my hosting Njal.la don't permit send email from my postfix server port > number 25 to prevent spam. > > But they say that i can use this setup > https://njal.la/docs/postfix-smarthost/ > > with; > relayhost = [emailserver.tld]:submission > in /etc/postfix/main.cf > > Hi You can use the following configuration for sending mail with external smtp relay. # sending options with external smtp relay smtp_sasl_auth_enable = yes smtp_sasl_password_maps = static:u...@domain.com:yourPasswd smtp_sasl_security_options = noanonymous header_size_limit = 4096000 relayhost = [mail.domain.com]:587 Replace creditials and relay hostname with yours. -- https://kenpeng.pages.dev/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Postfix is not using a specified interface
Hello I have specified Postfix to use a certain interface in 'main.cf': inet_interfaces = 192.168.2.2 http://www.postfix.org/postconf.5.html#inet_interfaces The problem is, Postfix is not using this interface and is instead using another interface to send e-mail. Is this a bug? Sincerely, Kolusion ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix is not using a specified interface
On mar, 2023-05-02 at 11:18 +0200, Kolusion K via Postfix-users wrote: > Hello hi, > I have specified Postfix to use a certain interface in 'main.cf': > > inet_interfaces = 192.168.2.2 > > > http://www.postfix.org/postconf.5.html#inet_interfaces > > The problem is, Postfix is not using this interface and is instead > using another interface to send e-mail. > > Is this a bug? No, it is that you *MUST* (RFC2119) do a thorough read of the documentation. Read just bellow what you have linked above and understand the effects of "intet_protocols = all" that you have also set in your main.cf email is a complex beast that requires good understanding of all the layers in the ISO networking stack and a whole bunch of Internet protocols. Reading The Book of Postfix by Ralf Hildebrandt and Patrick Koetter from cover to cover is an exercise I strongly recommend. Regards, ... -- Victoriano Giralt Innovation Director Digital Transformation Vicerectorate University of Malaga +34952131415 SPAIN == Note: signature.asc is the electronic signature of present message A: Yes. > Q: Are you sure ? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email ? signature.asc Description: This is a digitally signed message part ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix is not using a specified interface
Dnia 2.05.2023 o godz. 11:18:26 Kolusion K via Postfix-users pisze: > > I have specified Postfix to use a certain interface in 'main.cf': > > inet_interfaces = 192.168.2.2 > > > http://www.postfix.org/postconf.5.html#inet_interfaces > > The problem is, Postfix is not using this interface and is instead using > another interface to send e-mail. > > Is this a bug? As far as I understand, "inet_interfaces" defines the interfaces Postfix *listens on* when *receiving* mail. For sending, it uses (like pretty much any network application) whatever the TCP stack in your OS chooses. -- 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." ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix is not using a specified interface
For sending, it uses (like pretty much any network application) whatever the TCP stack in your OS chooses. this may be useful https://www.postfix.org/postconf.5.html#smtp_bind_address "An optional numerical network address that the Postfix SMTP client should bind to when making an IPv4 connection." works nicely on multi-homed setups ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Njal.la
Thanks, but it still doesn't work for me with those parameters. The relayhost value is an email server of my hosting. And I don't have that information. The njal.la admin refers me to this forum. :( Cheers ¡ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Njal.la
On mar, 2023-05-02 at 07:14 -0400, pripercat--- via Postfix-users wrote: > Thanks, but it still doesn't work for me with those parameters. The > relayhost value is an email server of my hosting. And I don't have > that information. Then, your hosting has to provide you with the username and password information for their systems. > The njal.la admin refers me to this forum. :( This forum can help you with setting up Postfix but we cannot help you with finding out settings that your email provider needs to give you. Do you have an account with them (njal.la)? Most probaly that's the one you have to use in your postfix configuration with mx.njal.la on port 587. But this may be absolutely wrong ... > Cheers ¡ Cheers! -- Victoriano Giralt Innovation Director Digital Transformation Vicerectorate University of Malaga +34952131415 SPAIN == Note: signature.asc is the electronic signature of present message A: Yes. > Q: Are you sure ? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email ? signature.asc Description: This is a digitally signed message part ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Njal.la
On 02-05-2023 13:14, pripercat--- via Postfix-users wrote: Thanks, but it still doesn't work for me with those parameters. The relayhost value is an email server of my hosting. And I don't have that information. The njal.la admin refers me to this forum. :( If njal.la provides documentation on how to setup an authenticated relay server, but without credentials, and then they point you here, my simple conclusion would be that don't provide this service. Probably you'll have to use an e-mail relay service from a different provider (which might be your home ISP, domain provider etc). My 2 cents, Tom ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] stop bulk messages
Hello list, Some clients abuse the outgoing smtp server for sending bulk messages. The messages have the same content of business promotion letter. Do you know how to stop this behavior? Thank you. corey ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postscreen and checking proper operation
Alex via Postfix-users: > Hi, > > I have postscreen implemented on postfix-3.7.3 on fedora37, and not sure I > understand if it's working properly. Sometimes I see the postscreen/dnsblog > combination ending with a simple DISCONNECT. In this case, it met the > 8-point threshold to be rejected, but appears to only received a DISCONNECT: > > May 1 20:57:53 petra postfix-226/postscreen[1104961]: CONNECT from > [95.214.27.139]:50021 to [5.196.7.226]:25 > May 1 20:57:53 petra postfix-226/postscreen[1104961]: PREGREET 11 after > 0.01 from [95.214.27.139]:50021: EHLO User\r\n > May 1 20:57:53 petra postfix-226/dnsblog[1105023]: addr 95.214.27.139 > listed by domain bl.mailspike.net as 127.0.0.2 > May 1 20:57:53 petra postfix-226/dnsblog[1105041]: addr 95.214.27.139 > listed by domain mykey.zen.dq.spamhaus.net as 127.0.0.4 > May 1 20:57:53 petra postfix-226/dnsblog[1105041]: addr 95.214.27.139 > listed by domain mykey.zen.dq.spamhaus.net as 127.0.0.2 > May 1 20:57:53 petra postfix-226/dnsblog[1105041]: addr 95.214.27.139 > listed by domain mykey.zen.dq.spamhaus.net as 127.0.0.9 > May 1 20:57:53 petra postfix-226/dnsblog[1105024]: addr 95.214.27.139 > listed by domain score.senderscore.com as 127.0.4.6 > May 1 20:57:53 petra postfix-226/dnsblog[1105025]: addr 95.214.27.139 > listed by domain sip-sip24.mykey.invaluement.com as 127.0.0.2 > May 1 20:57:53 petra postfix-226/postscreen[1104961]: DNSBL rank 23 for > [95.214.27.139]:50021 > May 1 20:57:54 petra postfix-226/postscreen[1104961]: DISCONNECT > [95.214.27.139]:50021 With postscreen_greet_action = enforce: server: 220-myhostname ESMTP client: EHLO User server: 550 5.5.1 Protocol error client disconnects immediately > while other times I do see there is a NOQUEUE/reject involved: > May 1 20:13:15 petra postfix-226/postscreen[1095132]: CONNECT from > [185.146.23.43]:46126 to [5.196.7.226]:25 > May 1 20:13:15 petra postfix-226/dnsblog[1095229]: addr 185.146.23.43 > listed by domain score.senderscore.com as 127.0.4.89 > May 1 20:13:15 petra postfix-226/dnsblog[1095233]: addr 185.146.23.43 > listed by domain bb.barracudacentral.org as 127.0.0.2 > May 1 20:13:15 petra postfix-226/dnsblog[1095232]: addr 185.146.23.43 > listed by domain sip-sip24.mykey.invaluement.com as 127.0.0.2 > May 1 20:13:21 petra postfix-226/postscreen[1095132]: DNSBL rank 13 for > [185.146.23.43]:46124 > May 1 20:13:21 petra postfix-226/postscreen[1095132]: NOQUEUE: reject: > RCPT from [185.146.23.43]:46124: 550 5.7.1 Service unavailable; client > [185.146.23.43] blocked using DNS Blocklist (invaluement); from=< > simon...@server.sito-wp.com>, to=, proto=ESMTP, > helo= Here, the client passed the PREGREET test, but failed the DNSBL check, and with "postscreen_dnsbl_action = enforce" was redirected to the dummy SMTP engine. It's working exactly as promised. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: stop bulk messages
Corey Hickman via Postfix-users writes: > Hello list, > > Some clients abuse the outgoing smtp server for sending bulk messages. > The messages have the same content of business promotion letter. > Do you know how to stop this behavior? > You can not stop it if he/she is paid user. Instead, you can redirect him/her to another relay server. Use <<>>. There are so many examples on the INTERNET blogs/forums. Also Amazon SES is proper relay service for bulk messages. Sincerely, -- ^고맙습니다 _布德天下_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: stop bulk messages
Corey Hickman via Postfix-users: > Hello list, > > Some clients abuse the outgoing smtp server for sending bulk messages. > The messages have the same content of business promotion letter. > Do you know how to stop this behavior? Perhaps you can use postfwd (www.postfwd.org) to limit the number of messages that a customer can send in some time interval. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Future Date:
On 01.05.23 15:41, Jon LaBadie via Postfix-users wrote: I've been getting a lot of spam with Date: headers containing future dates, typically 1 year. I don't find any header checks that would look for this type of message. Have I over looked it? In the meantime I've implemented a script and procmail rule to examine my messages. But that is post-delivery and per-user. perhaps you would want to set up spam filter? spamassassin has check for date in future and also many other for spammy signs. -- 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. 42.7 percent of all statistics are made up on the spot. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Njal.la
May 2, 2023 at 4:42 PM, "pripercat--- via Postfix-users" wrote: Hi, my hosting Njal.la don't permit send email from my postfix server port number 25 to prevent spam. But they say that i can use this setup https://njal.la/docs/postfix-smarthost/ with; relayhost = [emailserver.tld]:submission in /etc/postfix/main.cf On 02.05.23 09:01, Ken Peng via Postfix-users wrote: You can use the following configuration for sending mail with external smtp relay. smtp_sasl_password_maps = static:u...@domain.com:yourPasswd I recommend using external file nobody can read instead of putting password to main.cf. -- 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] inbound failures only from outbound.protection.outlook.com. Cert issue in this log?
a server that i don't have shell access to atm has, today, started seeing undelivered mail from only one domain -- *outbound.protection.outlook.com. apparently, everything else inbound is flowing. and, i'm told, inbound from outlook.com was working yesterday. all i've got so far is this log snip sent from the admin: 2023-05-02T08:23:10.490862-04:00 karma postfix/postscreen[17882]: CONNECT from [40.107.220.41]:40449 to [xx.xx.xx.xx]:25 2023-05-02T08:23:10.554083-04:00 karma postfix/dnsblog[17878]: addr 40.107.220.41 listed by domain list.dnswl.org as 127.0.0.255 2023-05-02T08:23:16.577189-04:00 karma postfix/postscreen[17882]: PASS NEW [40.107.220.41]:40449 2023-05-02T08:23:16.757030-04:00 karma postfix/ps-int/smtpd[17881]: connect from mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41] 2023-05-02T08:23:16.895010-04:00 karma postfix/ps-int/smtpd[17881]: setting up TLS connection from mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41] 2023-05-02T08:23:16.895219-04:00 karma postfix/ps-int/smtpd[17881]: mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:!SEED:!IDEA:!3DES:!RC2:!RC4:!RC5:!kDH:!kECDH:!aDSS:!MD5:+RC4:@STRENGTH:!aNULL" 2023-05-02T08:23:16.895448-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:before SSL initialization 2023-05-02T08:23:16.967083-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:before SSL initialization 2023-05-02T08:23:16.967268-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS read client hello 2023-05-02T08:23:16.967314-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS write server hello 2023-05-02T08:23:16.967344-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS write certificate 2023-05-02T08:23:16.970507-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS write key exchange 2023-05-02T08:23:16.970716-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS write certificate request 2023-05-02T08:23:16.970861-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS write server done 2023-05-02T08:23:17.151918-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS write server done 2023-05-02T08:23:17.152832-04:00 karma postfix/ps-int/smtpd[17881]: mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41]: depth=1 verify=0 subject=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1 2023-05-02T08:23:17.152961-04:00 karma postfix/ps-int/smtpd[17881]: mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41]: depth=0 verify=1 subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=mail.protection.outlook.com 2023-05-02T08:23:17.153066-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS read client certificate 2023-05-02T08:23:17.154966-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS read client key exchange 2023-05-02T08:23:17.155037-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS read certificate verify 2023-05-02T08:23:17.155087-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS read change cipher spec 2023-05-02T08:23:17.155118-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS read finished 2023-05-02T08:23:17.155296-04:00 karma postfix/ps-int/smtpd[17881]: mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41]: Issuing session ticket, key expiration: 1683035140 2023-05-02T08:23:17.155338-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS write session ticket 2023-05-02T08:23:17.155367-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS write change cipher spec 2023-05-02T08:23:17.155430-04:00 karma postfix/ps-int/smtpd[17881]: SSL_accept:SSLv3/TLS write finished 2023-05-02T08:23:17.155459-04:00 karma postfix/ps-int/smtpd[17881]: subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=mail.protection.outlook.com 2023-05-02T08:23:17.155485-04:00 karma postfix/ps-int/smtpd[17881]: issuer=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1 2023-05-02T08:23:17.155509-04:00 karma postfix/ps-int/smtpd[17881]: mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41]: subject_CN=mail.protection.outlook.com, issuer=DigiCert Cloud Services CA-1, fingerprint=1D:51:F5:25:8A:3E:F1:B8:65:1A:8D:D1:4A:5D:9D:16:B5:00:25:8A, pkey_fingerprint=52:BD:30:C7:65:7B:52:B0:B1:6C:7A:A5:97:3F:F7:EF:48:C2:A0:61 2023-05-02T08:23:17.155534-04:00 karma postfix/ps-int/smtpd[17881]: Untrusted TLS connection established from mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) 2023-05-02T08:23:17.225393-04:00 karma postfix/ps-int/smtpd[17881]: disconnect from mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41] ehlo=1 starttls=1 quit=1 commands=3 it appears that connection's made, then simply disconnected, without queueing. i don't recognize the problem, if it's even in ther
[pfx] Re: E-mail delivery problem
On 02.05.23 09:19, Kolusion K via Postfix-users wrote: So I have just had another look at my e-mail server regarding my situation, and I found something very odd. Postfix seems to be unable to send e-mail to IPv4 addresses, but it can send e-mail to IPv6 addresses. This is odd because Postfix is configured to use an IPv4 interface only, and its even more odd that the interface is a PPTP VPN tunnel which PPTP doesn't even support IPv6! What the ?!?!?!?! Here is an extract of my mail log, demonstrating what I mean: Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: warning: hostname generalpurpose does not resolve to address 192.168.2.2 Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: connect from unknown[192.168.2.2] Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: 2616D80098: client=unknown[192.168.2.2] Apr 12 23:05:39 generalpurpose postfix/cleanup[3568]: 2616D80098: message-id=<13a7d177-u778-3a84-3egd-19283c859...@example.com> Apr 12 23:05:39 generalpurpose postfix/qmgr[2241]: 2616D80098: from=, size=1966, nrcpt=1 (queue active) Apr 12 23:05:39 generalpurpose postfix/smtpd[3557]: disconnect from unknown[192.168.2.2] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 Apr 12 23:06:16 generalpurpose postfix/smtp[3569]: connect to pechora1.icann.org[192.0.33.71]:25: Connection timed out Apr 12 23:06:42 generalpurpose postfix/smtp[3569]: 2616D80098: to=, relay=pechora3.icann.org[2620:0:2830:201::1:73]:25, delay=64, delays=0.04/0.04/62/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 0463C7002623) Apr 12 23:06:42 generalpurpose postfix/qmgr[2241]: 2616D80098: removed you have in your main.cf: inet_interfaces = 192.168.2.2 this is private IP address. This address is apparently not properly NATted on your or your ISPs firewall. According to: https://marc.info/?l=postfix-users&m=168294384808797&w=2 E-mail server enp0s3 interface IP address: 192.168.1.2 E-mail server ppp0 interface IP address: 192.168.2.2 VPS enp6s18 interface IP address: 1.2.3.4 these commands don't do what you mean them to do: iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp --dport 25 -j DNAT --to 192.168.2.2 iptables -t nat -A PREROUTING -d 192.168.2.2 -p tcp --dport 25 -j DNAT --to 1.2.3.4 ...your problem is at network/firewall level. -- 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. A day without sunshine is like, night. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Contradicting Postfix documentation
Greetings I have found some contradicting Postfix documentation and I feel that it is my duty to make a revelation of it. https://www.postfix.org/postconf.5.html The inet_interface parameter is described as for receiving connections; The smtp_bind_address parameter is described as for making connections, and note 1 describes the inet_interface parameter as for making connections, contradicting the inet_interface parameter description. My experience with the inet_interface parameter is that it has no effect on making connections. Cheers Sincerely, Kolusion ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?
On Tue, May 02, 2023 at 09:41:50AM -0400, PGNet Dev via Postfix-users wrote: > a server that i don't have shell access to atm has, today, started > seeing undelivered mail from only one domain -- > *outbound.protection.outlook.com. apparently, everything else inbound > is flowing. and, i'm told, inbound from outlook.com was working > yesterday. The logging is much too verbose, pruned to just the expected normal logging: > 2023-05-02T08:23:16.757030-04:00 karma postfix/ps-int/smtpd[17881]: > connect from > mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41] > 2023-05-02T08:23:17.155534-04:00 karma postfix/ps-int/smtpd[17881]: > Untrusted TLS connection established from > mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41]: > TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) > 2023-05-02T08:23:17.225393-04:00 karma postfix/ps-int/smtpd[17881]: > disconnect from > > mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41] > ehlo=1 starttls=1 quit=1 commands=3 Either the client had no intention to send mail (some sort of liveness probe), or perhaps it did not like the presented certificate chain. What are some domains your server accepts mail for? Do you perhaps publish DANE TLSA records and have botched certificate rotation? -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Contradicting Postfix documentation
On Tue, 2 May 2023 at 15:54, Kolusion K via Postfix-users < postfix-users@postfix.org> wrote: > Greetings > > > I have found some contradicting Postfix documentation and I feel that it > is my duty to make a revelation of it. > > https://www.postfix.org/postconf.5.html > > The inet_interface parameter is described as for receiving connections; > > The smtp_bind_address parameter is described as for making connections, > and note 1 describes the inet_interface parameter as for making > connections, contradicting the inet_interface parameter description. > > My experience with the inet_interface parameter is that it has no effect > on making connections. > Have you read the note 1 completely? It says it will use the addr from inet_interfaces by default. But The whole smtp_bind_address is just for IPv4. There is a separate smtp_bind_address6 for IPv6. And your issue was with IPv6. The only thing that is not entirely clear in the Note1 is if the value from inet_interface is used only when smtp_bind_address is not set, or it always overrides its value. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?
On Tue, May 02, 2023 at 09:54:48AM -0400, Viktor Dukhovni via Postfix-users wrote: > What are some domains your server accepts mail for? Do you perhaps > publish DANE TLSA records and have botched certificate rotation? See if dropping the DST cross cert from your certificate chain will help. That root CA has long ago expired. Issuer: C=US, O=Let's Encrypt, CN=R3 Not Before: Apr 12 12:15:32 2023 GMT Not After : Jul 11 12:15:31 2023 GMT Subject: CN=mx1-edge.pgnetwork.net Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1 Not Before: Sep 4 00:00:00 2020 GMT Not After : Sep 15 16:00:00 2025 GMT Subject: C=US, O=Let's Encrypt, CN=R3 Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3 Not Before: Jan 20 19:14:03 2021 GMT Not After : Sep 30 18:14:03 2024 GMT Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1 The "ISRG Root X1" CA no longer needs a cross cert. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Contradicting Postfix documentation
Kolusion K via Postfix-users: Yesterday you sent a tcpdump trace where Postfix fails to make a connection from 192.168.2.2: 23:11:38.333669 IP 192.168.2.2.40415 > 47.246.137.47.smtp: Flags [S], seq 3300139944, win 65280, options [mss 1360,sackOK,TS val 912086021 ecr 0,nop,wscale 7], length 0 Today you claim that Postfix does NOT USE THAT IP ADDRESS. I have specified Postfix to use a certain interface in 'main.cf': inet_interfaces = 192.168.2.2 The problem is, Postfix is not using this interface and is instead using another interface to send e-mail. In fact it does use the IP address, but there is no route from 192.168.2.2 to the remote destination. According to the inet_interfaces manpage, EMPHASIS ADDED FOR CLARITY: When inet_interfaces specifies just one IPv4 and/or IPv6 address that is not a loopback address, the Postfix SMTP client will use this ad? dress as the IP source address for outbound mail. Support for IPv6 is available in Postfix version 2.2 and later. On a multi-homed firewall with separate Postfix instances listening on the "inside" and "outside" interfaces, THIS CAN PREVENT EACH INSTANCE FROM BEING ABLE TO REACH REMOTE SMTP SERVERS ON THE "OTHER SIDE" OF THE FIREWALL. Setting smtp_bind_address to 0.0.0.0 avoids the potential problem for IPv4, and setting smtp_bind_address6 to :: solves the prob- lem for IPv6. A better solution for multi-homed firewalls is to leave inet_interfaces at the default value and instead use explicit IP addresses in the mas- ter.cf SMTP server definitions. This preserves the Postfix SMTP client's loop detection, by ensuring that each side of the firewall knows that the other IP address is still the same host. Setting $inet_interfaces to a single IPv4 and/or IPV6 address is primarily use- ful with virtual hosting of domains on secondary IP addresses, when each IP address serves a different domain (and has a different $myhost- name setting). Your complex network configuration makes it a multi-homed host, and it is subject to the same problems as described above. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix is not using a specified interface
On Tue, May 02, 2023 at 11:18:26AM +0200, Kolusion K via Postfix-users wrote: > I have specified Postfix to use a certain interface in 'main.cf': > > inet_interfaces = 192.168.2.2 > > http://www.postfix.org/postconf.5.html#inet_interfaces > > The problem is, Postfix is not using this interface and is instead > using another interface to send e-mail. > > Is this a bug? When inet_interfaces contains exactly one explicit non-loopback IPv4 address that address becomes the default bind address for outgoing *IPv4* SMTP connections. The same is separately true for IPv6, but setting inet_interfaces to just an IPv4 address while at the same time "inet_protocols = all", will not provide an IPv6 default bind address, so IPv6 will bind dynamically based on your routing table. -- Viktor. A Ukranian commentator (and former army intelligence officer) covering the chronology of the war periodically needs to explain the difference between intelligence and counter-intelligence officers. - Intelligence officers look for friends among enemies. - Counter-intelligence officers look for enemies among friends. Your attitude to Postfix and the advice you get on this list seems to be that of a counter-intelligence officer. This is not especially productive. Postfix is high quality software, and you'll get sound advice here if you're less suspicious (or even disparaging) of both Postfix and the advice given. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Contradicting Postfix documentation
Yes, and I also told you how I didn't know what most of the results from tcpdump meant. K > Sent: Tuesday, May 02, 2023 at 4:21 pm > From: "Wietse Venema via Postfix-users" > To: "Kolusion K" > Cc: postfix-users@postfix.org > Subject: [pfx] Re: Contradicting Postfix documentation > > Kolusion K via Postfix-users: > Yesterday you sent a tcpdump trace where Postfix fails to make a > connection from 192.168.2.2: > > 23:11:38.333669 IP 192.168.2.2.40415 > 47.246.137.47.smtp: Flags > [S], seq 3300139944, win 65280, options [mss 1360,sackOK,TS val > 912086021 ecr 0,nop,wscale 7], length 0 > > Today you claim that Postfix does NOT USE THAT IP ADDRESS. > > I have specified Postfix to use a certain interface in 'main.cf': > > inet_interfaces = 192.168.2.2 > > The problem is, Postfix is not using this interface and is > instead using another interface to send e-mail. > > In fact it does use the IP address, but there is no route from > 192.168.2.2 to the remote destination. > > According to the inet_interfaces manpage, EMPHASIS ADDED FOR CLARITY: > >When inet_interfaces specifies just one IPv4 and/or IPv6 address that >is not a loopback address, the Postfix SMTP client will use this ad? >dress as the IP source address for outbound mail. Support for IPv6 is >available in Postfix version 2.2 and later. > >On a multi-homed firewall with separate Postfix instances listening on >the "inside" and "outside" interfaces, THIS CAN PREVENT EACH INSTANCE >FROM BEING ABLE TO REACH REMOTE SMTP SERVERS ON THE "OTHER SIDE" OF THE >FIREWALL. Setting smtp_bind_address to 0.0.0.0 avoids the potential >problem for IPv4, and setting smtp_bind_address6 to :: solves the prob- >lem for IPv6. > >A better solution for multi-homed firewalls is to leave inet_interfaces >at the default value and instead use explicit IP addresses in the mas- >ter.cf SMTP server definitions. This preserves the Postfix SMTP >client's loop detection, by ensuring that each side of the firewall >knows that the other IP address is still the same host. Setting >$inet_interfaces to a single IPv4 and/or IPV6 address is primarily use- >ful with virtual hosting of domains on secondary IP addresses, when >each IP address serves a different domain (and has a different $myhost- >name setting). > > Your complex network configuration makes it a multi-homed host, and it is > subject to the same problems as described above. > > Wietse > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Fw: Re: Re: Contradicting Postfix documentation
Hang on a second... my Postfix is using a network interface that is not the one set with the inet_interfaces parameter. So, my experience is true- the inet_interfaces parameter has no effect. K > Sent: Tuesday, May 02, 2023 at 4:36 pm > From: "Kolusion K" > To: "Wietse Venema via Postfix-users" > Subject: Re: [pfx] Re: Contradicting Postfix documentation > > Yes, and I also told you how I didn't know what most of the results from > tcpdump meant. > > K > > > > Sent: Tuesday, May 02, 2023 at 4:21 pm > > From: "Wietse Venema via Postfix-users" > > To: "Kolusion K" > > Cc: postfix-users@postfix.org > > Subject: [pfx] Re: Contradicting Postfix documentation > > > > Kolusion K via Postfix-users: > > Yesterday you sent a tcpdump trace where Postfix fails to make a > > connection from 192.168.2.2: > > > > 23:11:38.333669 IP 192.168.2.2.40415 > 47.246.137.47.smtp: Flags > > [S], seq 3300139944, win 65280, options [mss 1360,sackOK,TS val > > 912086021 ecr 0,nop,wscale 7], length 0 > > > > Today you claim that Postfix does NOT USE THAT IP ADDRESS. > > > > I have specified Postfix to use a certain interface in 'main.cf': > > > > inet_interfaces = 192.168.2.2 > > > > The problem is, Postfix is not using this interface and is > > instead using another interface to send e-mail. > > > > In fact it does use the IP address, but there is no route from > > 192.168.2.2 to the remote destination. > > > > According to the inet_interfaces manpage, EMPHASIS ADDED FOR CLARITY: > > > >When inet_interfaces specifies just one IPv4 and/or IPv6 address > > that > >is not a loopback address, the Postfix SMTP client will use this > > ad? > >dress as the IP source address for outbound mail. Support for IPv6 > > is > >available in Postfix version 2.2 and later. > > > >On a multi-homed firewall with separate Postfix instances listening > > on > >the "inside" and "outside" interfaces, THIS CAN PREVENT EACH > > INSTANCE > >FROM BEING ABLE TO REACH REMOTE SMTP SERVERS ON THE "OTHER SIDE" OF > > THE > >FIREWALL. Setting smtp_bind_address to 0.0.0.0 avoids the > > potential > >problem for IPv4, and setting smtp_bind_address6 to :: solves the > > prob- > >lem for IPv6. > > > >A better solution for multi-homed firewalls is to leave > > inet_interfaces > >at the default value and instead use explicit IP addresses in the > > mas- > >ter.cf SMTP server definitions. This preserves the Postfix > > SMTP > >client's loop detection, by ensuring that each side of the > > firewall > >knows that the other IP address is still the same host. > > Setting > >$inet_interfaces to a single IPv4 and/or IPV6 address is primarily > > use- > >ful with virtual hosting of domains on secondary IP addresses, > > when > >each IP address serves a different domain (and has a different > > $myhost- > >name setting). > > > > Your complex network configuration makes it a multi-homed host, and it is > > subject to the same problems as described above. > > > > Wietse > > ___ > > Postfix-users mailing list -- postfix-users@postfix.org > > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Contradicting Postfix documentation
Kolusion K: > Good point. Now that I think about that TCP dump, it did use 192.168.2.2. > > I can't see why there is no route. The firewall on the other side > is set to allow traffic through and it logged blocking traffic > before I allowed it. Maybe there is a problem with routing. One reason could be that IP forwarding is not enabled by default. Additionally, you have a very complex routing configuration. > I will do a traceroute from the Postfix server tomorrow and or > other investigation to see what's up. You will need to do traceroute with a very specific source IP address. traceroute -s 192.168.2.2 ... You may also need to specify "-P tcp", "-p 25" and other options if your routes depend on the protocol or destination port. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?
What are some domains your server accepts mail for? Do you perhaps publish DANE TLSA records and have botched certificate rotation? See if dropping the DST cross cert from your certificate chain will help. That root CA has long ago expired. nothing in that cert chain reports a past date. what root CA expiry are you referring to? The "ISRG Root X1" CA no longer needs a cross cert. it seems that LE still provides them, https://letsencrypt.org/certificates/ need to see if the certbot/acme client has a knob to disable/remove the DST cross. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?
On Tue, May 02, 2023 at 11:09:59AM -0400, PGNet Dev wrote: > what root CA expiry are you referring to? The DST root, that issued the ISRG X1 cross cert. > > The "ISRG Root X1" CA no longer needs a cross cert. > > it seems that LE still provides them, > >https://letsencrypt.org/certificates/ > > need to see if the certbot/acme client has a knob to disable/remove the DST > cross. >From my renewal.conf file: [renewalparams] reuse_key = True preferred_chain = ISRG Root X1 ... -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Future Date:
Matus UHLAR - fantomas via Postfix-users skrev den 2023-05-02 15:28: perhaps you would want to set up spam filter? spamassassin has check for date in future and also many other for spammy signs. Viktor provided a milter that test it before queue, while spamassassin is after queue ? but yes if sa-milter is in use it does not mater if date in future can tempfail mails Viktor would you mind add this milter to fuglu plugin https://gitlab.com/fumail/fuglu/ ? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?
Original Message From: Viktor Dukhovni via Postfix-users [mailto:postfix-users@postfix.org] Sent: Tuesday, May 2, 2023 at 11:32 AM EDT To: postfix-users@postfix.org Subject: [pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log? On Tue, May 02, 2023 at 11:09:59AM -0400, PGNet Dev wrote: what root CA expiry are you referring to? The DST root, that issued the ISRG X1 cross cert. https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ yikes. missed that by a mile! From my renewal.conf file: [renewalparams] reuse_key = True preferred_chain = ISRG Root X1 ... and for acme, https://github.com/acmesh-official/acme.sh/wiki/Preferred-Chain i'll get this in place with the downstream, and see what it cures! thx o/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Fw: Re: Re: Contradicting Postfix documentation
On Tue, May 02, 2023 at 04:45:13PM +0200, Kolusion K via Postfix-users wrote: > Hang on a second... my Postfix is using a network interface that is > not the one set with the inet_interfaces parameter. So, my experience > is true- the inet_interfaces parameter has no effect. No, it has exactly the documented effects, perhaps different from your naïve expectations for your particular use case. This is not the forum to seek "validation", the most you can expect from this list is technical help to configure Postfix to meet your stated requirements. - The IPv4 addresses listed in inet_interfaces have no effect on the choice of outbound IPv6 address when IPv6 is enabled. - When inet_interfaces list no IPv4 addresses other than loopback addresses, or lists multiple non-loopback IPv4 addresses, then inet_interfaces also has no effect on the choice of outbound IPv4 addresses. - To be sure that a particular IPv4 or IPv6 source address is used, configure an explicit "smtp_bind_address" or "smtp_bind_address6". - To be sure that IPv6 is not used, set "inet_protocols = ipv4". - To be sure that IPv4 is not used, set "inet_protocols = ipv6". - If you have just one IPv4 address suitable for both sending and receiving mail, set it as the only IPv4 address in inet_interfaces. You then don't need an explicit "smtp_bind_address", though an explicit setting may be sensible in some cases. - If you have just one IPv6 address suitable for both sending and receiving mail, set it as the only IPv6 address in inet_interfaces. You then don't need an explicit "smtp_bind_address6", though an explicit setting may be sensible in some cases. - In either case disable any protocol that is not at all suitable for receiving or sending email. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?
On Tue, May 02, 2023 at 11:54:00AM -0400, PGNet Dev wrote: > > The DST root, that issued the ISRG X1 cross cert. > > https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ > > yikes. missed that by a mile! > > >>From my renewal.conf file: > > > > [renewalparams] > > reuse_key = True > > preferred_chain = ISRG Root X1 > > ... > > and for acme, > > https://github.com/acmesh-official/acme.sh/wiki/Preferred-Chain > > > i'll get this in place with the downstream, and see what it cures! Also look into other possibilities, the DST Root issue is a bit of a longshot. If you can get an account on Outlook.com, send mail and see if it bounces with usable diagnostics in the bounce. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Future Date:
On Tue, May 02, 2023 at 05:47:03PM +0200, Benny Pedersen via Postfix-users wrote: > Matus UHLAR - fantomas via Postfix-users skrev den 2023-05-02 15:28: > > > perhaps you would want to set up spam filter? > > spamassassin has check for date in future and also many other for > > spammy signs. > > Viktor provided a milter that test it before queue, while spamassassin > is after queue ? > > but yes if sa-milter is in use it does not mater if date in future can > tempfail mails > > Viktor would you mind add this milter to fuglu plugin > https://gitlab.com/fumail/fuglu/ ? I posted a sketch of one function from a milter I am using. I do not intend to make it public. The milter is largely trivial, and highly specific to my use case. Other Python milters can be used as a template to similar ends. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Future Date:
Matus UHLAR - fantomas via Postfix-users skrev den 2023-05-02 15:28: perhaps you would want to set up spam filter? spamassassin has check for date in future and also many other for spammy signs. On 02.05.23 17:47, Benny Pedersen via Postfix-users wrote: Viktor provided a milter that test it before queue, while spamassassin is after queue ? you can use spamassassin within spamass-milter which is pre-queue or through amavis and via amavisd-milter which is also pre-queue. However my point was to use full antispam filter instead of single check for future Date: -- 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. Quantum mechanics: The dreams stuff is made of. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Future Date:
On 2023-05-02 at 11:47:03 UTC-0400 (Tue, 02 May 2023 17:47:03 +0200) Benny Pedersen via Postfix-users is rumored to have said: Viktor provided a milter that test it before queue, while spamassassin is after queue ? SpamAssassin is NOT inherently after-queue. There are at least 4 open source milters that can call SA. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Behaviour change between 3.2.2 and 3.7.4?
Have a couple of FreeBSD VMs running 11.1 and Postfix 3.2.2. Both VMs are used as MX for the domain. Using these two for about 1000 clients for one domain to send/receive. Been working fine for a couple years. Moving to a new set of VM hosts, so spun up a new VM on FBSD 12.4, installed via pkg Postfix 3.7.4. Set the VM up, can send/receive ok, but local mail is failing. FreeBSD has a few scripts that run nightly and send the reports to root or whomever. Since installing this VM, the reports are failing as is sending email from the CLI using mail root or mail user Log for the nightly cron job run: 03:01:09 mail sendmail[10703]: 342A19Wv010703: from=root, size=14672, class=0, nrcpts=1, msgid=<202305021001.342a19wv010...@mail.citytel.net>, relay=root@localhost May 2 03:01:09 mail postfix/postscreen[10718]: CONNECT from [127.0.0.1]:28289 to [127.0.0.1]:25 May 2 03:01:09 mail postfix/postscreen[10718]: ALLOWLISTED [127.0.0.1]:28289 May 2 03:01:09 mail postfix/smtpd[10722]: connect from localhost[127.0.0.1] May 2 03:01:09 mail postfix/smtpd[10722]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table; from= to= proto=ESMTP helo= May 2 03:01:09 mail postfix/smtpd[10722]: too many errors after RCPT from localhost[127.0.0.1] The local recipient table has a list of all valid users in the format u...@citytel.net. This is rebuilt when needed. Postifx is appending mail.citytel.net, not citytel.net. Main.cf on both the new VM and old VM: # myhostname = mail.citytel.net # mydomain = citytel.net # myorigin = $mydomain Current prod postfix server log file for root mail during the nightly cron job: May 2 03:03:08 mail postfix/qmgr[813]: 3BBF88930A: from=, size=13805, nrcpt=1 (queue active) May 2 03:03:08 mail postfix/smtp[15553]: 3BBF88930A: to=, orig_to= Is this a change in behaviour of postfix? Or is this the behaviour of the unix mail program itself? Why does the older FBSD11.1/Postfix 3.2.2 append the domain, but FBSD12.4/Postfix 3.7.4 appends the whole hostname and not the domain? Or have I completely missed a config option somewhere? Thanks. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behaviour change between 3.2.2 and 3.7.4?
kwoody--- via Postfix-users: > The local recipient table has a list of all valid users in the format > u...@citytel.net. This is rebuilt when needed. > > Postifx is appending mail.citytel.net, not citytel.net. Over the last 25+ years, Postfix appends the domain that is configured in the myorigin setting. Typically, that's one of: myorigin = $myhostname (the default) myorigin = $myomain You may want to check the output from this command: postconf -x myorigin myhostname mydomain HOWEVER Postfix will not append a domain if your mail command already provides one. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behaviour change between 3.2.2 and 3.7.4?
> kwoody--- via Postfix-users: > > The local recipient table has a list of all valid users in the format > > u...@citytel.net. This is rebuilt when needed. > > > > Postifx is appending mail.citytel.net, not citytel.net. > > Over the last 25+ years, Postfix appends the domain that is configured in the > myorigin setting. > > Typically, that's one of: > > myorigin = $myhostname (the default) > myorigin = $myomain > > You may want to check the output from this command: > > postconf -x myorigin myhostname mydomain > > HOWEVER Postfix will not append a domain if your mail command already > provides one. That's what I always have done, set the myorigin as $mydomain. # postconf -x myorigin myhostname mydomain myorigin = citytel.net myhostname = mail.citytel.net mydomain = citytel.net I'm just using the stock FBSD /usr/sbin/mail from CLI: # mail root Log file: May 2 14:56:49 mail sendmail[1456]: 342LunsF001456: from=kwoody, size=32, class=0, nrcpts=1, msgid=<202305022156.342lunsf001...@mail.citytel.net>, relay=root@localhost May 2 14:56:49 mail postfix/postscreen[1457]: CONNECT from [127.0.0.1]:44529 to [127.0.0.1]:25 May 2 14:56:49 mail postfix/postscreen[1457]: ALLOWLISTED [127.0.0.1]:44529 May 2 14:56:49 mail postfix/smtpd[1458]: connect from localhost[127.0.0.1] May 2 14:56:49 mail postfix/smtpd[1458]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table; from= to= proto=ESMTP helo= Which then tries to bounce the mail to my local user: kwo...@mail.citytel.net, which fails since the bounce is addressed to mail.citytel.net. The same /usr/sbin/mail root works fine on the older FBSD 11.1/Postfix 3.2.2 system. Not sure where else to look on this one as the main.cf file is practically the same between both installs, save for paths. Thanks. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behaviour change between 3.2.2 and 3.7.4?
On 5/2/2023 4:21 PM, kwoody--- via Postfix-users wrote: Log for the nightly cron job run: 03:01:09 mail sendmail[10703]: 342A19Wv010703: from=root, size=14672, class=0, nrcpts=1, msgid=<202305021001.342a19wv010...@mail.citytel.net>, relay=root@localhost This is sent by Sendmail(TM), not Postfix. You need to run whatever system utility FreeBSD uses to switch the default mailer. Note the mail already is addressed to @mail.citytel.net, so that's happening before postfix ever sees the mail. -- Noel Jones ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?
Also look into other possibilities, the DST Root issue is a bit of a longshot. If you can get an account on Outlook.com, send mail and see if it bounces with usable diagnostics in the bounce. i changed the preferred chain here, and for all my domains (thx o/ !). it certainly didn't hurt. but, i'm increasingly sure that your original speculation was correct -- bad rollover. cleaning up DNS config, and forcing a clean rollover, seems to have done the trick. after the dns cleanup, switching BACK the preferred chain didn't reinit the issue. when i looked at the logs i was given, DNSSEC/dane issues didn't leap out at me -- but you mentioned them. what in those logs suggested DNSSEC/dane to you? anything specific, or just likelihood ? in any case, i want to set up a DNSSEC rollover 'canary' ... tool/script that'll notify me on failures, like "this". b4 i cobble something up from scratch -- is there a recommended/best-practice tool for the job? specifically something that'd play nice with postfix -- and detect/notify the problem? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behaviour change between 3.2.2 and 3.7.4?
> > Log for the nightly cron job run: > > > > 03:01:09 mail sendmail[10703]: 342A19Wv010703: from=root, > size=14672, > > class=0, nrcpts=1, > > msgid=<202305021001.342a19wv010...@mail.citytel.net>, > > relay=root@localhost > > This is sent by Sendmail(TM), not Postfix. You need to run whatever system > utility FreeBSD uses to switch the default mailer. Note the mail already is > addressed to @mail.citytel.net, so that's happening before postfix ever sees > the mail. I caught that too and was unsure of why it was showing sendmail there or if it was relevant. But it is so will go down that path. Always just do a pkg install of postfix on new systems, but in this case it didn't replace sendmail like I thought it did. Thanks. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behaviour change between 3.2.2 and 3.7.4?
> On May 2, 2023, at 16:14, kwoody--- via Postfix-users > wrote: > >>> Log for the nightly cron job run: >>> >>> 03:01:09 mail sendmail[10703]: 342A19Wv010703: from=root, >> size=14672, >>> class=0, nrcpts=1, >>> msgid=<202305021001.342a19wv010...@mail.citytel.net>, >>> relay=root@localhost >> >> This is sent by Sendmail(TM), not Postfix. You need to run whatever system >> utility FreeBSD uses to switch the default mailer. Note the mail already > is >> addressed to @mail.citytel.net, so that's happening before postfix ever > sees >> the mail. > > I caught that too and was unsure of why it was showing sendmail there or if > it was relevant. But it is so will go down that path. > > Always just do a pkg install of postfix on new systems, but in this case it > didn't > replace sendmail like I thought it did. > > Thanks. The FreeBSD handbook has a section that shows how to replace sendmail with postfix, Section 30.4 Changes are needed to /etc/rc.conf and /etc/mail/mailer.conf -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?
On Tue, May 02, 2023 at 07:03:55PM -0400, PGNet Dev via Postfix-users wrote: > > Also look into other possibilities, the DST Root issue is a bit of a > > longshot. If you can get an account on Outlook.com, send mail and > > see if it bounces with usable diagnostics in the bounce. > > I changed the preferred chain here, and for all my domains (thx o/ !). > it certainly didn't hurt. Presumably you then also *force* renewed the certificate chain. > But, i'm increasingly sure that your original speculation was correct > -- bad rollover. cleaning up DNS config, and forcing a clean > rollover, seems to have done the trick. But your original chain did validate as far as posttls-finger was concerned, so perhaps the root CA was the issue? > After the dns cleanup, switching BACK the preferred chain didn't > reinit the issue. Did you *force* renewal at that point? > When I looked at the logs I was given, DNSSEC/dane issues didn't leap > out at me -- but you mentioned them. > > What in those logs suggested DNSSEC/dane to you? Anything specific, > or just likelihood? Microsoft is one of the few *large* email providers (Google, Microsoft, Yahoo) that supports DANE (for now just outbound). But DANE appeared to be fine on your end. > In any case, I want to set up a DNSSEC rollover 'canary' ... > tool/script that'll notify me on failures, like "this". Before I cobble > something up from scratch -- is there a recommended/best-practice tool > for the job? See https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources#221-deployment-and-monitoring Perhaps, specifically: https://github.com/PennockTech/smtpdane but let us know which worked out best for you. However, perhaps simple is best in which case tweak the attached bash shell script to meet your needs. Note this only tests one IP address per probe, a full check would try all IP addresses both IPv4 and IPv6 as well as all permutations of TLS 1.2/1.3 and preferred public key algorithm. Extending the script to do more tests should be easy. Sample output from "danesmtp mx1-edge.pgnetwork.net": === TLS 1.3 with ECDSA preferred: verify depth is 9 CONNECTION ESTABLISHED Protocol version: TLSv1.3 Ciphersuite: TLS_CHACHA20_POLY1305_SHA256 Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1 Peer certificate: CN = mx1-edge.pgnetwork.net Hash used: SHA384 Signature type: ECDSA Verification: OK DANE TLSA 3 1 2 ...18133fc2d94d1260e012bf5a matched EE certificate at depth 0 Server Temp Key: X25519, 253 bits 250 SMTPUTF8 DONE === TLS 1.3 with RSA preferred: verify depth is 9 CONNECTION ESTABLISHED Protocol version: TLSv1.3 Ciphersuite: TLS_CHACHA20_POLY1305_SHA256 Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1 Peer certificate: CN = mx1-edge.pgnetwork.net Hash used: SHA384 Signature type: ECDSA Verification: OK DANE TLSA 3 1 2 ...18133fc2d94d1260e012bf5a matched EE certificate at depth 0 Server Temp Key: X25519, 253 bits 250 SMTPUTF8 DONE === TLS 1.3 with EDDSA preferred: verify depth is 9 CONNECTION ESTABLISHED Protocol version: TLSv1.3 Ciphersuite: TLS_CHACHA20_POLY1305_SHA256 Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1 Peer certificate: CN = mx1-edge.pgnetwork.net Hash used: SHA384 Signature type: ECDSA Verification: OK DANE TLSA 3 1 2 ...18133fc2d94d1260e012bf5a matched EE certificate at depth 0 Server Temp Key: X25519, 253 bits 250 SMTPUTF8 DONE === TLS 1.2 with ECDSA preferred: verify depth is 9 CONNECTION ESTABLISHED Protocol version: TLSv1.2 Ciphersuite: ECDHE-ECDSA-AES256-GCM-SHA384 Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512 Peer certificate: CN = mx1-edge.pgnetwork.net Hash used: SHA256 Signature type: ECDSA Verification: OK DANE TLSA 3 1 2 ...18133fc2d94d1260e012bf5a matched EE certificate at depth 0 Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2 Server Temp Key: X448, 448 bits 250 SMTPUTF8
[pfx] icloud mx ip
Hello iCloud mail has two MX RR: icloud.com. 3600IN MX 10 mx01.mail.icloud.com. icloud.com. 3600IN MX 10 mx02.mail.icloud.com. But these two MX have the same IPs included. mx01: mx01.mail.icloud.com. 300 IN A 17.42.251.62 mx01.mail.icloud.com. 300 IN A 17.56.9.29 mx01.mail.icloud.com. 300 IN A 17.57.152.5 mx01.mail.icloud.com. 300 IN A 17.57.154.33 mx01.mail.icloud.com. 300 IN A 17.57.155.34 mx01.mail.icloud.com. 300 IN A 17.57.156.30 mx02: mx02.mail.icloud.com. 300 IN A 17.42.251.62 mx02.mail.icloud.com. 300 IN A 17.56.9.29 mx02.mail.icloud.com. 300 IN A 17.57.152.5 mx02.mail.icloud.com. 300 IN A 17.57.154.33 mx02.mail.icloud.com. 300 IN A 17.57.155.34 mx02.mail.icloud.com. 300 IN A 17.57.156.30 What's the advantage for this settings? Thanks. regards Ken Peng ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: icloud mx ip
Forgive me if I’m wrong but the advantages I can see: - load balancing / redundancy - failover - geoDNS This would be for handling of incoming connections. I have no knowledge of apples infrastructure whether they are using geo-loadbalancer across multiple datacentres, whether their dcs are layer 3 or later 2 connected or how they operate in general although I suspect some of the points would be valid irrespective of how they have engineered their infrastructure and service. Scenarios: - maybe they want to perform maintenance at the dns level but only impacting one dns endpoint whilst keeping the other one available for client consumption. - maybe they want to perform maintenance on an external IP perspective that may only impact a subset of their internal hosted mail servers whilst keeping majority unaffected etc. - prob others To me it just gives them options to maintain reliability in terms of service uptime and availability. > On 3/05/2023, at 1:07 PM, Ken Peng via Postfix-users > wrote: > > Hello > > iCloud mail has two MX RR: > > icloud.com.3600INMX10 mx01.mail.icloud.com. > icloud.com.3600INMX10 mx02.mail.icloud.com. > > But these two MX have the same IPs included. > > mx01: > mx01.mail.icloud.com.300INA17.42.251.62 > mx01.mail.icloud.com.300INA17.56.9.29 > mx01.mail.icloud.com.300INA17.57.152.5 > mx01.mail.icloud.com.300INA17.57.154.33 > mx01.mail.icloud.com.300INA17.57.155.34 > mx01.mail.icloud.com.300INA17.57.156.30 > > > mx02: > mx02.mail.icloud.com.300INA17.42.251.62 > mx02.mail.icloud.com.300INA17.56.9.29 > mx02.mail.icloud.com.300INA17.57.152.5 > mx02.mail.icloud.com.300INA17.57.154.33 > mx02.mail.icloud.com.300INA17.57.155.34 > mx02.mail.icloud.com.300INA17.57.156.30 > > > What's the advantage for this settings? Thanks. > > regards > Ken Peng > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: icloud mx ip
Ken Peng via Postfix-users: > Hello > > iCloud mail has two MX RR: > > icloud.com. 3600IN MX 10 mx01.mail.icloud.com. > icloud.com. 3600IN MX 10 mx02.mail.icloud.com. > > But these two MX have the same IPs included. > > mx01: > mx01.mail.icloud.com. 300 IN A 17.42.251.62 > mx01.mail.icloud.com. 300 IN A 17.56.9.29 > mx01.mail.icloud.com. 300 IN A 17.57.152.5 > mx01.mail.icloud.com. 300 IN A 17.57.154.33 > mx01.mail.icloud.com. 300 IN A 17.57.155.34 > mx01.mail.icloud.com. 300 IN A 17.57.156.30 > > mx02: > mx02.mail.icloud.com. 300 IN A 17.42.251.62 > mx02.mail.icloud.com. 300 IN A 17.56.9.29 > mx02.mail.icloud.com. 300 IN A 17.57.152.5 > mx02.mail.icloud.com. 300 IN A 17.57.154.33 > mx02.mail.icloud.com. 300 IN A 17.57.155.34 > mx02.mail.icloud.com. 300 IN A 17.57.156.30 > > What's the advantage for this settings? Thanks. Whatever the motivation to do this, it does not matter for Postfix. The Postfix SMTP client will randomly choose up to 5 IP addresses from the combined list(*). Usually, some addresses will be a duplicate, but most will be distinct. (*) By default, smtp_mx_address_limit = 5. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: icloud mx ip
Since mx1 and mx2 have the same IPs included, it's a waste to postfix's chosen space for IP addresses. For example, the 5 MX IPs could have 2 duplicates. So I am not sure why apple has this wasted setup. Thank you. > > Ken Peng via Postfix-users: > > > > > Hello > > > > iCloud mail has two MX RR: > > > > icloud.com. 3600 IN MX 10 mx01.mail.icloud.com. > > icloud.com. 3600 IN MX 10 mx02.mail.icloud.com. > > > > But these two MX have the same IPs included. > > > > mx01: > > mx01.mail.icloud.com. 300 IN A 17.42.251.62 > > mx01.mail.icloud.com. 300 IN A 17.56.9.29 > > mx01.mail.icloud.com. 300 IN A 17.57.152.5 > > mx01.mail.icloud.com. 300 IN A 17.57.154.33 > > mx01.mail.icloud.com. 300 IN A 17.57.155.34 > > mx01.mail.icloud.com. 300 IN A 17.57.156.30 > > > > mx02: > > mx02.mail.icloud.com. 300 IN A 17.42.251.62 > > mx02.mail.icloud.com. 300 IN A 17.56.9.29 > > mx02.mail.icloud.com. 300 IN A 17.57.152.5 > > mx02.mail.icloud.com. 300 IN A 17.57.154.33 > > mx02.mail.icloud.com. 300 IN A 17.57.155.34 > > mx02.mail.icloud.com. 300 IN A 17.57.156.30 > > > > What's the advantage for this settings? Thanks. > > > > Whatever the motivation to do this, it does not matter for Postfix. > The Postfix SMTP client will randomly choose up to 5 IP addresses > from the combined list(*). Usually, some addresses will be a > duplicate, but most will be distinct. > > (*) By default, smtp_mx_address_limit = 5. > > Wietse > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org > -- https://kenpeng.pages.dev/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Fw: Re: Re: Contradicting Postfix documentation
Its not naive, its a fact- Postfix is broken. The inet_interfaces parameter is described in the documentation as making Postfix use only the interfaces listed for the parameter. In reality, Postfix ignores the parameter by using network interfaces that are not listed. There is nothing mentioned in the Postfix documentation under the inet_interfaces parameter section that says the inet_interfaces parameter is for IPv4 only and that it will not have an effect on IPv6 interfaces. That claim is your fairy tale. K > Sent: Tuesday, May 02, 2023 at 5:57 pm > From: "Viktor Dukhovni via Postfix-users" > To: postfix-users@postfix.org > Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation > > On Tue, May 02, 2023 at 04:45:13PM +0200, Kolusion K via Postfix-users wrote: > > > Hang on a second... my Postfix is using a network interface that is > > not the one set with the inet_interfaces parameter. So, my experience > > is true- the inet_interfaces parameter has no effect. > > No, it has exactly the documented effects, perhaps different from your > naïve expectations for your particular use case. This is not the forum > to seek "validation", the most you can expect from this list is > technical help to configure Postfix to meet your stated requirements. > > - The IPv4 addresses listed in inet_interfaces have no effect on > the choice of outbound IPv6 address when IPv6 is enabled. > > - When inet_interfaces list no IPv4 addresses other than loopback > addresses, or lists multiple non-loopback IPv4 addresses, then > inet_interfaces also has no effect on the choice of outbound IPv4 > addresses. > > - To be sure that a particular IPv4 or IPv6 source address is used, > configure an explicit "smtp_bind_address" or "smtp_bind_address6". > - To be sure that IPv6 is not used, set "inet_protocols = ipv4". > - To be sure that IPv4 is not used, set "inet_protocols = ipv6". > > - If you have just one IPv4 address suitable for both sending and > receiving mail, set it as the only IPv4 address in inet_interfaces. > You then don't need an explicit "smtp_bind_address", though an > explicit setting may be sensible in some cases. > - If you have just one IPv6 address suitable for both sending and > receiving mail, set it as the only IPv6 address in inet_interfaces. > You then don't need an explicit "smtp_bind_address6", though an > explicit setting may be sensible in some cases. > - In either case disable any protocol that is not at all suitable for > receiving or sending email. > > -- > Viktor. > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Fw: Re: Fw: Re: Re: Contradicting Postfix documentation
Postfix needs to be patched so that the value of the inet_interfaces parameter is obeyed regardless of whether or not IPv6 (or other IP versions?) is enabled. K > Sent: Wednesday, May 03, 2023 at 4:57 am > From: "Kolusion K via Postfix-users" > To: "Viktor Dukhovni via Postfix-users" > Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation > > Its not naive, its a fact- Postfix is broken. The inet_interfaces parameter > is described in the documentation as making Postfix use only the interfaces > listed for the parameter. In reality, Postfix ignores the parameter by using > network interfaces that are not listed. > > There is nothing mentioned in the Postfix documentation under the > inet_interfaces parameter section that says the inet_interfaces parameter is > for IPv4 only and that it will not have an effect on IPv6 interfaces. That > claim is your fairy tale. > > > K > > > > > Sent: Tuesday, May 02, 2023 at 5:57 pm > > From: "Viktor Dukhovni via Postfix-users" > > To: postfix-users@postfix.org > > Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation > > > > On Tue, May 02, 2023 at 04:45:13PM +0200, Kolusion K via Postfix-users > > wrote: > > > > > Hang on a second... my Postfix is using a network interface that is > > > not the one set with the inet_interfaces parameter. So, my experience > > > is true- the inet_interfaces parameter has no effect. > > > > No, it has exactly the documented effects, perhaps different from your > > naïve expectations for your particular use case. This is not the forum > > to seek "validation", the most you can expect from this list is > > technical help to configure Postfix to meet your stated requirements. > > > > - The IPv4 addresses listed in inet_interfaces have no effect on > > the choice of outbound IPv6 address when IPv6 is enabled. > > > > - When inet_interfaces list no IPv4 addresses other than loopback > > addresses, or lists multiple non-loopback IPv4 addresses, then > > inet_interfaces also has no effect on the choice of outbound IPv4 > > addresses. > > > > - To be sure that a particular IPv4 or IPv6 source address is used, > > configure an explicit "smtp_bind_address" or "smtp_bind_address6". > > - To be sure that IPv6 is not used, set "inet_protocols = ipv4". > > - To be sure that IPv4 is not used, set "inet_protocols = ipv6". > > > > - If you have just one IPv4 address suitable for both sending and > > receiving mail, set it as the only IPv4 address in inet_interfaces. > > You then don't need an explicit "smtp_bind_address", though an > > explicit setting may be sensible in some cases. > > - If you have just one IPv6 address suitable for both sending and > > receiving mail, set it as the only IPv6 address in inet_interfaces. > > You then don't need an explicit "smtp_bind_address6", though an > > explicit setting may be sensible in some cases. > > - In either case disable any protocol that is not at all suitable for > > receiving or sending email. > > > > -- > > Viktor. > > ___ > > Postfix-users mailing list -- postfix-users@postfix.org > > To unsubscribe send an email to postfix-users-le...@postfix.org > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Fw: Re: Fw: Re: Re: Contradicting Postfix documentation
Disabling IPv6 probably isn't an acceptable workaround anyway. What happens if both an IPv4 and IPv6 IP address is listed? Postfix may still use other network interfaces not listed (IP addresses). Changing the parameter name wouldn't be a bad idea either seeing parameter values are actually IP addresses and not interface names, as the parameter name suggests. K > Sent: Wednesday, May 03, 2023 at 5:11 am > From: "Kolusion K via Postfix-users" > To: postfix-users@postfix.org > Subject: [pfx] Fw: Re: Fw: Re: Re: Contradicting Postfix documentation > > Postfix needs to be patched so that the value of the inet_interfaces > parameter is obeyed regardless of whether or not IPv6 (or other IP versions?) > is enabled. > > K > > > > > Sent: Wednesday, May 03, 2023 at 4:57 am > > From: "Kolusion K via Postfix-users" > > To: "Viktor Dukhovni via Postfix-users" > > Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation > > > > Its not naive, its a fact- Postfix is broken. The inet_interfaces parameter > > is described in the documentation as making Postfix use only the interfaces > > listed for the parameter. In reality, Postfix ignores the parameter by > > using network interfaces that are not listed. > > > > There is nothing mentioned in the Postfix documentation under the > > inet_interfaces parameter section that says the inet_interfaces parameter > > is for IPv4 only and that it will not have an effect on IPv6 interfaces. > > That claim is your fairy tale. > > > > > > K > > > > > > > > > Sent: Tuesday, May 02, 2023 at 5:57 pm > > > From: "Viktor Dukhovni via Postfix-users" > > > To: postfix-users@postfix.org > > > Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation > > > > > > On Tue, May 02, 2023 at 04:45:13PM +0200, Kolusion K via Postfix-users > > > wrote: > > > > > > > Hang on a second... my Postfix is using a network interface that is > > > > not the one set with the inet_interfaces parameter. So, my experience > > > > is true- the inet_interfaces parameter has no effect. > > > > > > No, it has exactly the documented effects, perhaps different from your > > > naïve expectations for your particular use case. This is not the forum > > > to seek "validation", the most you can expect from this list is > > > technical help to configure Postfix to meet your stated requirements. > > > > > > - The IPv4 addresses listed in inet_interfaces have no effect on > > > the choice of outbound IPv6 address when IPv6 is enabled. > > > > > > - When inet_interfaces list no IPv4 addresses other than loopback > > > addresses, or lists multiple non-loopback IPv4 addresses, then > > > inet_interfaces also has no effect on the choice of outbound IPv4 > > > addresses. > > > > > > - To be sure that a particular IPv4 or IPv6 source address is used, > > > configure an explicit "smtp_bind_address" or "smtp_bind_address6". > > > - To be sure that IPv6 is not used, set "inet_protocols = ipv4". > > > - To be sure that IPv4 is not used, set "inet_protocols = ipv6". > > > > > > - If you have just one IPv4 address suitable for both sending and > > > receiving mail, set it as the only IPv4 address in inet_interfaces. > > > You then don't need an explicit "smtp_bind_address", though an > > > explicit setting may be sensible in some cases. > > > - If you have just one IPv6 address suitable for both sending and > > > receiving mail, set it as the only IPv6 address in inet_interfaces. > > > You then don't need an explicit "smtp_bind_address6", though an > > > explicit setting may be sensible in some cases. > > > - In either case disable any protocol that is not at all suitable for > > > receiving or sending email. > > > > > > -- > > > Viktor. > > > ___ > > > Postfix-users mailing list -- postfix-users@postfix.org > > > To unsubscribe send an email to postfix-users-le...@postfix.org > > ___ > > Postfix-users mailing list -- postfix-users@postfix.org > > To unsubscribe send an email to postfix-users-le...@postfix.org > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Contradicting Postfix documentation
This looks a network and config issue rather than any defect in PF be that with the code or the docs... I would highly recommend you crawl before you try running so with that in mind, scale back your config to just use v4 and get that working. Also, if you really want help on this mailer, post both your main and master config files so the community understands exactly what your system is cfg’d to do. Otherwise, it is doubtful folks will wanna spend the time especially when your position is that you don’t need to put in the same effort we all have done - i.e. seeing value in RTFM. I can truly say that in the 13+ years I’ve been using PF, all of the config and operational issues I’ve had were covered in the docs… - - - On 2 May 2023, at 20:28, Kolusion K via Postfix-users wrote: Disabling IPv6 probably isn't an acceptable workaround anyway. What happens if both an IPv4 and IPv6 IP address is listed? Postfix may still use other network interfaces not listed (IP addresses). Changing the parameter name wouldn't be a bad idea either seeing parameter values are actually IP addresses and not interface names, as the parameter name suggests. K Sent: Wednesday, May 03, 2023 at 5:11 am From: "Kolusion K via Postfix-users" To: postfix-users@postfix.org Subject: [pfx] Fw: Re: Fw: Re: Re: Contradicting Postfix documentation Postfix needs to be patched so that the value of the inet_interfaces parameter is obeyed regardless of whether or not IPv6 (or other IP versions?) is enabled. K Sent: Wednesday, May 03, 2023 at 4:57 am From: "Kolusion K via Postfix-users" To: "Viktor Dukhovni via Postfix-users" Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation Its not naive, its a fact- Postfix is broken. The inet_interfaces parameter is described in the documentation as making Postfix use only the interfaces listed for the parameter. In reality, Postfix ignores the parameter by using network interfaces that are not listed. There is nothing mentioned in the Postfix documentation under the inet_interfaces parameter section that says the inet_interfaces parameter is for IPv4 only and that it will not have an effect on IPv6 interfaces. That claim is your fairy tale. K Sent: Tuesday, May 02, 2023 at 5:57 pm From: "Viktor Dukhovni via Postfix-users" To: postfix-users@postfix.org Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation On Tue, May 02, 2023 at 04:45:13PM +0200, Kolusion K via Postfix-users wrote: Hang on a second... my Postfix is using a network interface that is not the one set with the inet_interfaces parameter. So, my experience is true- the inet_interfaces parameter has no effect. No, it has exactly the documented effects, perhaps different from your naïve expectations for your particular use case. This is not the forum to seek "validation", the most you can expect from this list is technical help to configure Postfix to meet your stated requirements. - The IPv4 addresses listed in inet_interfaces have no effect on the choice of outbound IPv6 address when IPv6 is enabled. - When inet_interfaces list no IPv4 addresses other than loopback addresses, or lists multiple non-loopback IPv4 addresses, then inet_interfaces also has no effect on the choice of outbound IPv4 addresses. - To be sure that a particular IPv4 or IPv6 source address is used, configure an explicit "smtp_bind_address" or "smtp_bind_address6". - To be sure that IPv6 is not used, set "inet_protocols = ipv4". - To be sure that IPv4 is not used, set "inet_protocols = ipv6". - If you have just one IPv4 address suitable for both sending and receiving mail, set it as the only IPv4 address in inet_interfaces. You then don't need an explicit "smtp_bind_address", though an explicit setting may be sensible in some cases. - If you have just one IPv6 address suitable for both sending and receiving mail, set it as the only IPv6 address in inet_interfaces. You then don't need an explicit "smtp_bind_address6", though an explicit setting may be sensible in some cases. - In either case disable any protocol that is not at all suitable for receiving or sending email. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org___ Postfix-users mai
[pfx] Re: Contradicting Postfix documentation
I've been posting on this mailer for the past 2 days and I have posted my configuration file as we as my mail log which demonstrates a problem with Postix where it is using network interfaces it shouldn't be using, as per the documentation. This is the first time I have seen you here, so, perhaps you should STFU before telling me to crawl before run and RTFM. Also, stop thinking Postfix is flawless. You are living in a fantasy land. Lots of pilots thought their autopilot software was flawless, too, only to end up being killed by it. K > Sent: Wednesday, May 03, 2023 at 5:51 am > From: "Antonio Leding" > To: "Kolusion K" > Cc: "Kolusion K via Postfix-users" > Subject: Re: [pfx] Contradicting Postfix documentation > > This looks a network and config issue rather than any defect in PF be > that with the code or the docs... > > I would highly recommend you crawl before you try running so with that > in mind, scale back your config to just use v4 and get that working. > Also, if you really want help on this mailer, post both your main and > master config files so the community understands exactly what your > system is cfg’d to do. Otherwise, it is doubtful folks will wanna > spend the time especially when your position is that you don’t need to > put in the same effort we all have done - i.e. seeing value in RTFM. > > I can truly say that in the 13+ years I’ve been using PF, all of the > config and operational issues I’ve had were covered in the docs… > > - - - > > On 2 May 2023, at 20:28, Kolusion K via Postfix-users wrote: > > > Disabling IPv6 probably isn't an acceptable workaround anyway. What > > happens if both an IPv4 and IPv6 IP address is listed? Postfix may > > still use other network interfaces not listed (IP addresses). > > > > Changing the parameter name wouldn't be a bad idea either seeing > > parameter values are actually IP addresses and not interface names, as > > the parameter name suggests. > > > > K > > > > > > > >> Sent: Wednesday, May 03, 2023 at 5:11 am > >> From: "Kolusion K via Postfix-users" > >> To: postfix-users@postfix.org > >> Subject: [pfx] Fw: Re: Fw: Re: Re: Contradicting Postfix > >> documentation > >> > >> Postfix needs to be patched so that the value of the inet_interfaces > >> parameter is obeyed regardless of whether or not IPv6 (or other IP > >> versions?) is enabled. > >> > >> K > >> > >> > >> > >>> Sent: Wednesday, May 03, 2023 at 4:57 am > >>> From: "Kolusion K via Postfix-users" > >>> To: "Viktor Dukhovni via Postfix-users" > >>> Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation > >>> > >>> Its not naive, its a fact- Postfix is broken. The inet_interfaces > >>> parameter is described in the documentation as making Postfix use > >>> only the interfaces listed for the parameter. In reality, Postfix > >>> ignores the parameter by using network interfaces that are not > >>> listed. > >>> > >>> There is nothing mentioned in the Postfix documentation under the > >>> inet_interfaces parameter section that says the inet_interfaces > >>> parameter is for IPv4 only and that it will not have an effect on > >>> IPv6 interfaces. That claim is your fairy tale. > >>> > >>> > >>> K > >>> > >>> > >>> > Sent: Tuesday, May 02, 2023 at 5:57 pm > From: "Viktor Dukhovni via Postfix-users" > > To: postfix-users@postfix.org > Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation > > On Tue, May 02, 2023 at 04:45:13PM +0200, Kolusion K via > Postfix-users wrote: > > > Hang on a second... my Postfix is using a network interface that > > is > > not the one set with the inet_interfaces parameter. So, my > > experience > > is true- the inet_interfaces parameter has no effect. > > No, it has exactly the documented effects, perhaps different from > your > naïve expectations for your particular use case. This is not the > forum > to seek "validation", the most you can expect from this list is > technical help to configure Postfix to meet your stated > requirements. > > - The IPv4 addresses listed in inet_interfaces have no effect > on > the choice of outbound IPv6 address when IPv6 is enabled. > > - When inet_interfaces list no IPv4 addresses other than > loopback > addresses, or lists multiple non-loopback IPv4 addresses, > then > inet_interfaces also has no effect on the choice of outbound > IPv4 > addresses. > > - To be sure that a particular IPv4 or IPv6 source address is used, > configure an explicit "smtp_bind_address" or > "smtp_bind_address6". > - To be sure that IPv6 is not used, set "inet_protocols = ipv4". > - To be sure that IPv4 is not used, set "inet_protocols = ipv6". > > - If you have just one IPv4 address suitable for both sending and > receiving mail,
[pfx] Re: Contradicting Postfix documentation
On Wed, May 03, 2023 at 04:57:57AM +0200, Kolusion K via Postfix-users wrote: > Its not naive, its a fact- Postfix is broken. The inet_interfaces > parameter is described in the documentation as making Postfix use only > the interfaces listed for the parameter. In reality, Postfix ignores > the parameter by using network interfaces that are not listed. [ The hubris is grating. If you plan to stick around on the list, it would be best to start cutting back... ] https://www.postfix.org/postconf.5.html#inet_interfaces When inet_interfaces specifies just one IPv4 and/or IPv6 address that is not a loopback address, the Postfix SMTP client will use this address as the IP source address for outbound mail. Support for IPv6 is available in Postfix version 2.2 and later. Note the "and/or", in particular there can be one of each, and each affects only connections made via the associated protocol. Connections made via the either protocol are of course not affected by the choice of primary address for the other. This could be made a bit more explicit, but Postfix is behaving as intended. Not everything you find unintuitive is necessarily a software or even a documentation bug. Though requests (rather than demands) for documentation clarification may, when justified, elicit changes in the text, not just clarifying on-list commentary. > There is nothing mentioned in the Postfix documentation under the > inet_interfaces parameter section that says the inet_interfaces > parameter is for IPv4 only and that it will not have an effect on IPv6 > interfaces. That claim is your fairy tale. It isn't for IPv4 only, it is for either or both protocols. The overloading of inet_interfaces as a default source of "smtp_bind_adress" and/or "smtpd_bind_address6" is a convenience that applies in limited circumstances (exactly one "public" IP address for the associated address family). To be sure to set a bind address use the associated dedicated parameters. > Postfix needs to be patched so that the value of the inet_interfaces > parameter is obeyed regardless of whether or not IPv6 (or other IP > versions?) is enabled. It is obeyed as intended, on a per-address-family basis. If you want just one address family, then you need to explicitly disable the other. Listing only IPv4 or only IPv6 addresses in inet_interfaces leaves the other protocol family unconstrained. This is a feature, not a bug. > Disabling IPv6 probably isn't an acceptable workaround anyway. But that's exactly what you naîvely expected inet_interfaces to do, so clearly it must be acceptable in your use case. > What happens if both an IPv4 and IPv6 IP address is listed? Postfix > may still use other network interfaces not listed (IP addresses). If IPv6 is disabled, then IPv6 elements of inet_interfaces don't apply. I don't recall whether they are then ignored, or a configuration error is reported. > Changing the parameter name wouldn't be a bad idea either seeing > parameter values are actually IP addresses and not interface names, as > the parameter name suggests. That'd be a invalidation of long-standing practice for little gain. In many cases there's just one address per interface and address selection on a multi-homed host amounts to interface selection. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Contradicting Postfix documentation
I feel there are a lot of fanboys here who are in denial about my finding and are sticking their head in the sand about it in the face of what my Postfix is doing, so there is no more point in me talking about it. I will use the work around of switching off off IPv6. And hopefully Wietse will fix this problem in Postfix. K > Sent: Wednesday, May 03, 2023 at 6:12 am > From: "Viktor Dukhovni via Postfix-users" > To: postfix-users@postfix.org > Subject: [pfx] Re: Contradicting Postfix documentation > > On Wed, May 03, 2023 at 04:57:57AM +0200, Kolusion K via Postfix-users wrote: > > > Its not naive, its a fact- Postfix is broken. The inet_interfaces > > parameter is described in the documentation as making Postfix use only > > the interfaces listed for the parameter. In reality, Postfix ignores > > the parameter by using network interfaces that are not listed. > > [ The hubris is grating. If you plan to stick around on the list, it > would be best to start cutting back... ] > > https://www.postfix.org/postconf.5.html#inet_interfaces > > When inet_interfaces specifies just one IPv4 and/or IPv6 address > that is not a loopback address, the Postfix SMTP client will use > this address as the IP source address for outbound mail. Support > for IPv6 is available in Postfix version 2.2 and later. > > Note the "and/or", in particular there can be one of each, and each > affects only connections made via the associated protocol. Connections > made via the either protocol are of course not affected by the choice of > primary address for the other. This could be made a bit more explicit, > but Postfix is behaving as intended. > > Not everything you find unintuitive is necessarily a software or even a > documentation bug. Though requests (rather than demands) for > documentation clarification may, when justified, elicit changes in > the text, not just clarifying on-list commentary. > > > There is nothing mentioned in the Postfix documentation under the > > inet_interfaces parameter section that says the inet_interfaces > > parameter is for IPv4 only and that it will not have an effect on IPv6 > > interfaces. That claim is your fairy tale. > > It isn't for IPv4 only, it is for either or both protocols. The > overloading of inet_interfaces as a default source of "smtp_bind_adress" > and/or "smtpd_bind_address6" is a convenience that applies in limited > circumstances (exactly one "public" IP address for the associated address > family). To be sure to set a bind address use the associated dedicated > parameters. > > > Postfix needs to be patched so that the value of the inet_interfaces > > parameter is obeyed regardless of whether or not IPv6 (or other IP > > versions?) is enabled. > > It is obeyed as intended, on a per-address-family basis. If you want > just one address family, then you need to explicitly disable the other. > > Listing only IPv4 or only IPv6 addresses in inet_interfaces leaves the > other protocol family unconstrained. This is a feature, not a bug. > > > Disabling IPv6 probably isn't an acceptable workaround anyway. > > But that's exactly what you naîvely expected inet_interfaces to do, > so clearly it must be acceptable in your use case. > > > What happens if both an IPv4 and IPv6 IP address is listed? Postfix > > may still use other network interfaces not listed (IP addresses). > > If IPv6 is disabled, then IPv6 elements of inet_interfaces don't apply. > I don't recall whether they are then ignored, or a configuration error > is reported. > > > Changing the parameter name wouldn't be a bad idea either seeing > > parameter values are actually IP addresses and not interface names, as > > the parameter name suggests. > > That'd be a invalidation of long-standing practice for little gain. > In many cases there's just one address per interface and address > selection on a multi-homed host amounts to interface selection. > > -- > Viktor. > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Contradicting Postfix documentation
I am no fanboy of Postfix and have had more than my share of problems wading through the documentation and often fining it quite thin - but on this issue, I have no problem with Postfix's behavior. It is normal and I think desirable for programs to choose sensible defaults when possible. This makes configuration easier in general. Only the "abnormal" or site-specific settings need to be given. In this case, you said you wanted IPv6 and didn't say which addresses to listen on or send from so Postfix chose a sensible value. I have no problem with that. Documentation can always be improved but there is nothing wrong with the program itself in this respect. On 3/05/2023 2:30 pm, Kolusion K via Postfix-users wrote: I feel there are a lot of fanboys here who are in denial about my finding and are sticking their head in the sand about it in the face of what my Postfix is doing, so there is no more point in me talking about it. I will use the work around of switching off off IPv6. And hopefully Wietse will fix this problem in Postfix. K Sent: Wednesday, May 03, 2023 at 6:12 am From: "Viktor Dukhovni via Postfix-users" To: postfix-users@postfix.org Subject: [pfx] Re: Contradicting Postfix documentation On Wed, May 03, 2023 at 04:57:57AM +0200, Kolusion K via Postfix-users wrote: Its not naive, its a fact- Postfix is broken. The inet_interfaces parameter is described in the documentation as making Postfix use only the interfaces listed for the parameter. In reality, Postfix ignores the parameter by using network interfaces that are not listed. [ The hubris is grating. If you plan to stick around on the list, it would be best to start cutting back... ] https://www.postfix.org/postconf.5.html#inet_interfaces When inet_interfaces specifies just one IPv4 and/or IPv6 address that is not a loopback address, the Postfix SMTP client will use this address as the IP source address for outbound mail. Support for IPv6 is available in Postfix version 2.2 and later. Note the "and/or", in particular there can be one of each, and each affects only connections made via the associated protocol. Connections made via the either protocol are of course not affected by the choice of primary address for the other. This could be made a bit more explicit, but Postfix is behaving as intended. Not everything you find unintuitive is necessarily a software or even a documentation bug. Though requests (rather than demands) for documentation clarification may, when justified, elicit changes in the text, not just clarifying on-list commentary. There is nothing mentioned in the Postfix documentation under the inet_interfaces parameter section that says the inet_interfaces parameter is for IPv4 only and that it will not have an effect on IPv6 interfaces. That claim is your fairy tale. It isn't for IPv4 only, it is for either or both protocols. The overloading of inet_interfaces as a default source of "smtp_bind_adress" and/or "smtpd_bind_address6" is a convenience that applies in limited circumstances (exactly one "public" IP address for the associated address family). To be sure to set a bind address use the associated dedicated parameters. Postfix needs to be patched so that the value of the inet_interfaces parameter is obeyed regardless of whether or not IPv6 (or other IP versions?) is enabled. It is obeyed as intended, on a per-address-family basis. If you want just one address family, then you need to explicitly disable the other. Listing only IPv4 or only IPv6 addresses in inet_interfaces leaves the other protocol family unconstrained. This is a feature, not a bug. Disabling IPv6 probably isn't an acceptable workaround anyway. But that's exactly what you naîvely expected inet_interfaces to do, so clearly it must be acceptable in your use case. What happens if both an IPv4 and IPv6 IP address is listed? Postfix may still use other network interfaces not listed (IP addresses). If IPv6 is disabled, then IPv6 elements of inet_interfaces don't apply. I don't recall whether they are then ignored, or a configuration error is reported. Changing the parameter name wouldn't be a bad idea either seeing parameter values are actually IP addresses and not interface names, as the parameter name suggests. That'd be a invalidation of long-standing practice for little gain. In many cases there's just one address per interface and address selection on a multi-homed host amounts to interface selection. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org -- This email has been checked for viruses by AVG antivirus software. www.avg.com ___
[pfx] Re: Contradicting Postfix documentation
OK - not gonna argue any of your ridiculous comments. You’re likely just trolling the mailer for lulz or some such and therefore don’t deserve my or anyone else’s time… Good luck chief - you’re gonna need it… - - - On 2 May 2023, at 21:12, Kolusion K via Postfix-users wrote: I've been posting on this mailer for the past 2 days and I have posted my configuration file as we as my mail log which demonstrates a problem with Postix where it is using network interfaces it shouldn't be using, as per the documentation. This is the first time I have seen you here, so, perhaps you should STFU before telling me to crawl before run and RTFM. Also, stop thinking Postfix is flawless. You are living in a fantasy land. Lots of pilots thought their autopilot software was flawless, too, only to end up being killed by it. K Sent: Wednesday, May 03, 2023 at 5:51 am From: "Antonio Leding" To: "Kolusion K" Cc: "Kolusion K via Postfix-users" Subject: Re: [pfx] Contradicting Postfix documentation This looks a network and config issue rather than any defect in PF be that with the code or the docs... I would highly recommend you crawl before you try running so with that in mind, scale back your config to just use v4 and get that working. Also, if you really want help on this mailer, post both your main and master config files so the community understands exactly what your system is cfg’d to do. Otherwise, it is doubtful folks will wanna spend the time especially when your position is that you don’t need to put in the same effort we all have done - i.e. seeing value in RTFM. I can truly say that in the 13+ years I’ve been using PF, all of the config and operational issues I’ve had were covered in the docs… - - - On 2 May 2023, at 20:28, Kolusion K via Postfix-users wrote: Disabling IPv6 probably isn't an acceptable workaround anyway. What happens if both an IPv4 and IPv6 IP address is listed? Postfix may still use other network interfaces not listed (IP addresses). Changing the parameter name wouldn't be a bad idea either seeing parameter values are actually IP addresses and not interface names, as the parameter name suggests. K Sent: Wednesday, May 03, 2023 at 5:11 am From: "Kolusion K via Postfix-users" To: postfix-users@postfix.org Subject: [pfx] Fw: Re: Fw: Re: Re: Contradicting Postfix documentation Postfix needs to be patched so that the value of the inet_interfaces parameter is obeyed regardless of whether or not IPv6 (or other IP versions?) is enabled. K Sent: Wednesday, May 03, 2023 at 4:57 am From: "Kolusion K via Postfix-users" To: "Viktor Dukhovni via Postfix-users" Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation Its not naive, its a fact- Postfix is broken. The inet_interfaces parameter is described in the documentation as making Postfix use only the interfaces listed for the parameter. In reality, Postfix ignores the parameter by using network interfaces that are not listed. There is nothing mentioned in the Postfix documentation under the inet_interfaces parameter section that says the inet_interfaces parameter is for IPv4 only and that it will not have an effect on IPv6 interfaces. That claim is your fairy tale. K Sent: Tuesday, May 02, 2023 at 5:57 pm From: "Viktor Dukhovni via Postfix-users" To: postfix-users@postfix.org Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation On Tue, May 02, 2023 at 04:45:13PM +0200, Kolusion K via Postfix-users wrote: Hang on a second... my Postfix is using a network interface that is not the one set with the inet_interfaces parameter. So, my experience is true- the inet_interfaces parameter has no effect. No, it has exactly the documented effects, perhaps different from your naïve expectations for your particular use case. This is not the forum to seek "validation", the most you can expect from this list is technical help to configure Postfix to meet your stated requirements. - The IPv4 addresses listed in inet_interfaces have no effect on the choice of outbound IPv6 address when IPv6 is enabled. - When inet_interfaces list no IPv4 addresses other than loopback addresses, or lists multiple non-loopback IPv4 addresses, then inet_interfaces also has no effect on the choice of outbound IPv4 addresses. - To be sure that a particular IPv4 or IPv6 source address is used, configure an explicit "smtp_bind_address" or "smtp_bind_address6". - To be sure that IPv6 is not used, set "inet_protocols = ipv4". - To be sure that IPv4 is not used, set "inet_protocols = ipv6". - If you have just one IPv4 address suitable for both sending and receiving mail, set it as the only IPv4 address in inet_interfaces. You then don't need an explicit "smtp_bind_address", though an explicit setting may be sensible in some cases. - If you have just one IPv6 address suitable for both sending and receiving mail, set it as the only IPv6 address in inet_int
[pfx] THREAD CLOSED: (was: Contradicting Postfix documentation)
On Wed, May 03, 2023 at 02:57:34PM +1000, Sean Gallagher via Postfix-users wrote: > Documentation can always be improved but there is nothing wrong with the > program itself in this respect. We can close this thread. The OP's membership in the list has been terminated for uncivil behaviour. If the OP rejoins, any repeats will be dealt with more promptly. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Contradicting Postfix documentation
On 03.05.23 06:12, Kolusion K via Postfix-users wrote: I've been posting on this mailer for the past 2 days and I have posted my configuration file as we as my mail log which demonstrates a problem with Postix where it is using network interfaces it shouldn't be using, as per the documentation. This is the first time I have seen you here, so, perhaps you should STFU before telling me to crawl before run and RTFM. using ipv4-only address in inet_interfaces if ipv6 is enabled is an error. If you want to disable ipv6, you must configure: inet_protocols = ipv4 If you only enable ipv4 address with ipv6 enabled, postfix will handle ipv6 automatically. I have no idea why you complain about this, since this is the main reason at least part of your e-mail works properly. Your problem is incorrect network setup. Your ipv4 address is not routed/NATted properly and the address you have configured in postfix does not have proper internet connectivity. Also, stop thinking Postfix is flawless. You are living in a fantasy land. Lots of pilots thought their autopilot software was flawless, too, only to end up being killed by it. nobody says postfix is flawless. It just doesn't have the flaws you think. -- 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. Christian Science Programming: "Let God Debug It!". ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: body_checks not catching all backscatter
On 27.04.23 17:59, Sebastian Wiesinger via Postfix-users wrote: I'm not sure if I'm missing something but I can't find out why my body_checks doesn't catch all the backscatter I'm getting right now. I've it configured like this: root@alita:/etc/postfix# postconf -n body_checks body_checks = pcre:$config_directory/body_checks.pcre root@alita:/etc/postfix# cat body_checks.pcre /^[> ]*Message-ID:.*@(fire-world\.de)/ reject SPAM backscatter with forged domain name in Message-ID header One example it doesn't catch seems to match the regex when I test it manually: root@alita:/etc/postfix# postmap -q - regexp:/etc/postfix/body_checks.pcre reject SPAM backscatter with forged domain name in Message-ID header I've got the original message (from my mailbox) here for you: https://www.karotte.org/big/backscatter.txt As I said, Postfix rejects some of the backscatter but not all. Any idea why it didn't reject this? If I tried to block backscatter, I would use spamassassin with VBounce plugin and filter out all mail that hit any of BOUNCE_MESSAGE rules. it just needs to set up proper hostames in welcomelist_bounce_relays. I already use spamassassin as milter, so milter_header_checks should be applicable. -- 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 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: body_checks not catching all backscatter
On 28/04/23 03:59, Sebastian Wiesinger via Postfix-users wrote: Hi everyone, I'm not sure if I'm missing something but I can't find out why my body_checks doesn't catch all the backscatter I'm getting right now. Oh yuck. I've found that the best way to block backscatter is by using the backscatter DNSRBL. Make sure you follow the instructions for setting it up properly: https://www.backscatterer.org/?target=usage If used correctly it will only block DSNs from known backscatter sources. Peter ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: body_checks not catching all backscatter
May 3, 2023 at 1:43 PM, "Peter via Postfix-users" wrote: > > On 28/04/23 03:59, Sebastian Wiesinger via Postfix-users wrote: > > > > > Hi everyone, > > I'm not sure if I'm missing something but I can't find out why my > > body_checks doesn't catch all the backscatter I'm getting right now. > > > > Oh yuck. > > I've found that the best way to block backscatter is by using the backscatter > DNSRBL. Make sure you follow the instructions for setting it up properly: > > https://www.backscatterer.org/?target=usage > > If used correctly it will only block DSNs from known backscatter sources. > Hello But anybody can use our (even setup correctly) mailserver as backscatter source? -- https://kenpeng.pages.dev/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: body_checks not catching all backscatter
On 3/05/23 17:51, Ken Peng via Postfix-users wrote: But anybody can use our (even setup correctly) mailserver as backscatter source? Not if you configure postfix properly. Peter ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
