Re: off-topic mta-sts/office.com question
On Mon, May 02, 2022 at 12:04:13PM +1000, raf wrote: > The test email bounced with the following report: > > > Diagnostic information for administrators: > > > > Generating server: ME3PR01MB8390.ausprd01.prod.outlook.com > > Receiving server: ME3PR01MB8390.ausprd01.prod.outlook.com > > > > r...@libslack.org > > 5/1/2022 12:09:32 AM - Server at ME3PR01MB8390.ausprd01.prod.outlook.com > > returned '550 5.4.317 Message expired, cannot connect to remote > > server(451 4.7.5 Remote certificate MUST have a subject alternative name > > matching the hostname (MTA-STS))' > > 4/30/2022 11:59:28 PM - Server at libslack.org (82.134.31.111) > > returned '450 4.4.317 Cannot connect to remote server [Message=451 > > 4.7.5 Remote certificate MUST have a subject alternative name matching > > the hostname (MTA-STS)] [LastAttemptedServerName=libslack.org] > > [LastAttemptedIP=82.134.31.111:25] > > [SY4AUS01FT024.eop-AUS01.prod.protection.outlook.com](451 4.7.5 Remote > > certificate MUST have a subject alternative name matching the hostname > > (MTA-STS))' > > The test email was sent to r...@libslack.org. > libslack.org's MX record points to smtp10.infotech.no. > smtp10.infotech.no's IP address is 82.134.31.111. > https://mta-sts.libslack.org/.well-known/mta-sts.txt > contains "mx: smtp10.infotech.no". That MX host has a self-signed certificate with a name of "elrond10.infotech.no", which is rather at odds of the promised support for MTA-STS, which requires a Web-PKI trusted certificate with a DNS subject alternative name matching the MX hostname. The details of the error message may be variously misleading, but that does not change the fact that this domain should not promise what it does not deliver. -- Viktor.
off-topic mta-sts/office.com question
Hi, Has anyone else seen this? Apologies in advance for this not being directly postfix-related, but I'm hoping someone here can explain some wierd behaviour I'm seeing from Outlook's mail servers. I'm setting up a new postfix server for someone. It mainly does virus/spam checking and relaying for a bunch of domains. For testing, I've made it the only MX server for one of my spare domains, and sent an email to there from an account at outlook.office.com. For this test, I remembered to add the new server to the list of mx records that MTA-STS knows about. I probably should have removed MTA-STS completely for this test. The test email bounced with the following report: > Diagnostic information for administrators: > > Generating server: ME3PR01MB8390.ausprd01.prod.outlook.com > Receiving server: ME3PR01MB8390.ausprd01.prod.outlook.com > > r...@libslack.org > 5/1/2022 12:09:32 AM - Server at ME3PR01MB8390.ausprd01.prod.outlook.com > returned '550 5.4.317 Message expired, cannot connect to remote > server(451 4.7.5 Remote certificate MUST have a subject alternative name > matching the hostname (MTA-STS))' > 4/30/2022 11:59:28 PM - Server at libslack.org (82.134.31.111) > returned '450 4.4.317 Cannot connect to remote server [Message=451 > 4.7.5 Remote certificate MUST have a subject alternative name matching > the hostname (MTA-STS)] [LastAttemptedServerName=libslack.org] > [LastAttemptedIP=82.134.31.111:25] > [SY4AUS01FT024.eop-AUS01.prod.protection.outlook.com](451 4.7.5 Remote > certificate MUST have a subject alternative name matching the hostname > (MTA-STS))' The test email was sent to r...@libslack.org. libslack.org's MX record points to smtp10.infotech.no. smtp10.infotech.no's IP address is 82.134.31.111. https://mta-sts.libslack.org/.well-known/mta-sts.txt contains "mx: smtp10.infotech.no". $ host -t mx libslack.org libslack.org mail is handled by 10 smtp10.infotech.no. $ host smtp10.infotech.no smtp10.infotech.no has address 82.134.31.111 $ curl https://mta-sts.libslack.org/.well-known/mta-sts.txt [...] mx: smtp10.infotech.no [...] The above report seems to indicate that Outlook's servers think that the MX server they are sending to is called libslack.org and that its address is 82.134.31.111. The address is right, but the name isn't. libslack.org is just the recipient domain, not the MX server name. It also seems to indicate that the TLS certificate at that server should have libslack.org as one of its subject alternative names. Am I reading that right? It seems very badly wrong. What am I missing? I don't remember reading that a requirement of MTA-STS is that MX server TLS certificates need to certify all the domains that they server as MX for. But it seems hard to believe that the Outlook servers could mistake the recipient domain for the MX server domain, but that's what it looks like. For my next test, I'll just turn off MTA-STS (using yet another spare domain so I don't have to wait a week). cheers, raf
Re: Inconsistency between postconf(5) and IPV6_README
On 2022-05-01 18:14, Wietse Venema wrote: Pau Amma: Still, there is room for making the link text shorter than I suggested while still providing enough context. For example, "tips how to port Postfix IPv6 support" or "how to port Postfix IPv6 support" may be enough context. I don't know the audience for this document well enough to say. I just found that there is a heading "IPv6 Support for unsupported platforms", so I'll use that in the link text. Thanks. That should work as well. -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila)
Re: header_checks and regexes
On Sun, May 01, 2022 at 03:54:16PM -0400, Alex wrote: > > Conditional header checks require a milter or content filter that > > can make such fine distinctions. Postfix built-in header checks > > are global. > > I need to find a way to have different policies for different domains > on the same IP address, such as to be able to reject mail from one > sender to one domain but accept that sender to another. If by different domains, you mean different envelope recipients grouped by recipient domain, then you don't need or want "header_checks" for that. If the number of recipient domains is modest, you can use restriction classes. http://www.postfix.org/RESTRICTION_CLASS_README.html -- Viktor.
Re: header_checks and regexes
Hi, On Thu, Mar 10, 2022 at 5:23 PM Viktor Dukhovni wrote: > > > On 10 Mar 2022, at 3:48 pm, Alex wrote: > > > > Can I use sender_checks to bypass a host like mail.coupahost.com? The > > client IP will constantly change, but I can rely on the sending domain > > to remain the same. > > Conditional header checks require a milter or content filter that > can make such fine distinctions. Postfix built-in header checks > are global. I need to find a way to have different policies for different domains on the same IP address, such as to be able to reject mail from one sender to one domain but accept that sender to another. Are there existing content filters that can do this, or is the process explained somewhere? I've looked at a few examples but these distinctions don't seem to be made. Building a milter from scratch to do this sounds like a daunting process. The milter docs mention it's possible to analyze headers, but don't appear to provide any details on how this would even be done.
Re: Inconsistency between postconf(5) and IPV6_README
Pau Amma: > >> Revised patch per above. While in proto/IPV6_README.html, I tweaked > >> the > >> link text in one spot for better screenreader accessibility per > >> https://webaim.org/techniques/hypertext/#alpha_links. (Other links > >> there > >> or elsewhere in the documentation may need similar changes. Let me > >> know > >> if you & WV want to do that yourselves.) > > > > Thank you. I'm not familiar with 'screen reader tweaks'. Is this > > for people with limited eye sight? I generally avoid many-word > > links except in case of links to a heading. > > People with vision impairment are indeed the main users of screenreading > software, but I hear they also help some people as a workaround for > dyslexia. And I suggested a longer link text because screenreaders > sometimes (at the user's options) list links separately from running > text, and a link that just says "below" would be hard to interpret in > that case. Still, there is room for making the link text shorter than I > suggested while still providing enough context. For example, "tips how > to port Postfix IPv6 support" or "how to port Postfix IPv6 support" may > be enough context. I don't know the audience for this document well > enough to say. I just found that there is a heading "IPv6 Support for unsupported platforms", so I'll use that in the link text. Wietse
Re: Inconsistency between postconf(5) and IPV6_README
On 2022-05-01 00:09, Wietse Venema wrote: Pau Amma: On 2022-04-30 05:06, Viktor Dukhovni wrote: > On Sat, Apr 30, 2022 at 12:49:30AM +, Pau Amma wrote: > >> I finally got around to this, or rather to the half that didn't have a >> mention of NO_IPV6. While there, I noticed a stray uppercase letter >> elsewhere (2x) and fixed that as well. Patch (generated from >> postfix-3.8-20220421) attached. > > The source file for IPV6_README is: proto/IPV6_README.html > >> +++ postfix-tmp/README_FILES/IPV6_README 2022-04-30 02:35:27.514645000 >> +0200 > > This is a derived file, and the patch should be against the "proto" > file. > >> +++ postfix-tmp/proto/INSTALL.html 2022-04-30 02:40:25.455297000 +0200 > > THis is the only "INSTALL" file to edit. Revised patch per above. While in proto/IPV6_README.html, I tweaked the link text in one spot for better screenreader accessibility per https://webaim.org/techniques/hypertext/#alpha_links. (Other links there or elsewhere in the documentation may need similar changes. Let me know if you & WV want to do that yourselves.) Thank you. I'm not familiar with 'screen reader tweaks'. Is this for people with limited eye sight? I generally avoid many-word links except in case of links to a heading. People with vision impairment are indeed the main users of screenreading software, but I hear they also help some people as a workaround for dyslexia. And I suggested a longer link text because screenreaders sometimes (at the user's options) list links separately from running text, and a link that just says "below" would be hard to interpret in that case. Still, there is room for making the link text shorter than I suggested while still providing enough context. For example, "tips how to port Postfix IPv6 support" or "how to port Postfix IPv6 support" may be enough context. I don't know the audience for this document well enough to say. -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila)
