Re: Cannot resolve support@ alias
Hi, eh… OK, that's getting stranger. At least it works now – but I don't know why. Postfix started accepting the mail and correctly resolving the alias some time in the night between 24th and 25th of October. I had a script sitting here sending test mails every hour (because all of this was supposed to become a test/benchmark framework for a support hotline system), and I see the log seitching from reject to accept at 0:29 in that night for no obvious reason. Cheers, Nik signature.asc Description: PGP signature
Re: started getting 550 #5.7.1 SPF unauthorized mail
On 25/08/2022 04:41, li...@sbt.net.au wrote:
I have a simple 'mail list' where an alias 'ct...@sbt.net.au' sends email
to several recipients, that's been in use since long time.
today noticed one of these addresses started bouncing with '5.7.1 SPF
unauthorized mail' since just today:
what am I doing wrong ?
worked:
Aug 23 09:27:25 geko postfix/smtp[12957]: Untrusted TLS connection
established to asav.tpg.com.au[27.32.32.10]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 23 09:27:27 geko postfix/smtp[12957]: 3119E21C52F:
to=, relay=asav.tpg.com.au[27.32.32.10]:25, delay=1.9,
delays=0.03/0/0.73/1.2, dsn=2.0.0, status=sent (250 ok: Message 199653922
accepted)
no longer:
Aug 25 09:22:29 geko postfix/smtp[19538]: Untrusted TLS connection
established to asav.tpg.com.au[27.32.32.10]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 25 09:22:30 geko postfix/smtp[19538]: 61DA820053B:
to=, relay=asav.tpg.com.au[27.32.32.10]:25, delay=1.9,
delays=0.08/0.02/0.74/1, dsn=5.0.0, status=bounced (host
asav.tpg.com.au[27.32.32.10] said: 550 #5.7.1 SPF unauthorized mail is
prohibited. (in reply to DATA command))
Aug 25 09:39:17 geko postfix/smtp[26188]: Untrusted TLS connection
established to asav.tpg.com.au[27.32.32.10]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 25 09:39:18 geko postfix/smtp[26188]: 5C7FE2004D9:
to=, relay=asav.tpg.com.au[27.32.32.10]:25, delay=0.64,
delays=0.05/0.01/0.26/0.33, dsn=5.0.0, status=bounced (host
asav.tpg.com.au[27.32.32.10] said: 550 #5.7.1 SPF unauthorized mail is
prohibited. (in reply to DATA command))
looking at the log is see:
# grep 4678220053B /var/log/maillog
Aug 25 09:38:55 geko postfix/smtpd[21733]: 4678220053B:
client=mail-me3aus01on2049.outbound.protection.outlook.com[40.107.108.49]
Aug 25 09:38:55 geko postfix/cleanup[26173]: 4678220053B:
message-id=
Aug 25 09:38:56 geko opendkim[930]: 4678220053B: failed to parse
authentication-results: header field
Aug 25 09:38:56 geko opendkim[930]: 4678220053B: DKIM verification successful
Aug 25 09:38:56 geko opendmarc[908]: 4678220053B ignoring
Authentication-Results at 1 from geko.sbt.net.au
Aug 25 09:38:56 geko opendmarc[908]: 4678220053B: SPF(mailfrom):
tld.com.au pass
Aug 25 09:38:56 geko opendmarc[908]: 4678220053B: tld.com.au none
Aug 25 09:38:56 geko postfix/qmgr[23312]: 4678220053B:
from=, size=629054, nrcpt=8 (queue active)
Aug 25 09:39:17 geko amavis[23896]: (23896-16) Passed CLEAN
{RelayedOpenRelay}, [40.107.108.49]:3695 [40.107.108.49]
-> , Queue-ID: 4678220053B, Message-ID:
,
mail_id: ecrv8dP6h0oa, Hits: -1.712, size: 629477, queued_as: 5C7FE2004D9,
4939 ms
Aug 25 09:39:17 geko postfix/smtp[26175]: 4678220053B:
to=, orig_to=,
relay=127.0.0.1[127.0.0.1]:10024, delay=22, delays=1.2/16/0.01/4.9,
dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250
2.0.0 Ok: queued as 5C7FE2004D9)
Aug 25 09:44:04 geko postfix/qmgr[23312]: 4678220053B: removed
#
# grep 5C7FE2004D9 /var/log/maillog
Aug 25 09:39:17 geko postfix/smtpd[26177]: 5C7FE2004D9:
client=localhost[127.0.0.1]
Aug 25 09:39:17 geko postfix/cleanup[26173]: 5C7FE2004D9:
message-id=
Aug 25 09:39:17 geko postfix/qmgr[23312]: 5C7FE2004D9:
from=, size=629970, nrcpt=1 (queue active)
Aug 25 09:39:17 geko amavis[23896]: (23896-16) Passed CLEAN
{RelayedOpenRelay}, [40.107.108.49]:3695 [40.107.108.49]
-> , Queue-ID: 4678220053B, Message-ID:
,
mail_id: ecrv8dP6h0oa, Hits: -1.712, size: 629477, queued_as: 5C7FE2004D9,
4939 ms
Aug 25 09:39:17 geko postfix/smtp[26175]: 4678220053B:
to=, orig_to=,
relay=127.0.0.1[127.0.0.1]:10024, delay=22, delays=1.2/16/0.01/4.9,
dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250
2.0.0 Ok: queued as 5C7FE2004D9)
Aug 25 09:39:18 geko postfix/smtp[26188]: 5C7FE2004D9:
to=, relay=asav.tpg.com.au[27.32.32.10]:25, delay=0.64,
delays=0.05/0.01/0.26/0.33, dsn=5.0.0, status=bounced (host
asav.tpg.com.au[27.32.32.10] said: 550 #5.7.1 SPF unauthorized mail is
prohibited. (in reply to DATA command))
Aug 25 09:39:18 geko postfix/bounce[26219]: 5C7FE2004D9: sender
non-delivery notification: 0C96B21C52C
Aug 25 09:39:18 geko postfix/qmgr[23312]: 5C7FE2004D9: removed
mail_version = 3.7.2
SPF works by checking the SPF record for the domain specified in the
mail *envelope*. If the IP from which the email has been received does
not meet the SPF record criteria, it is an SPF fail. My impression is
that a number of email providers (including Gmail) have become much
stickier about refusing emails that fail SPF testing of late, and it
seems that tpg.com.au is one of them.
When you relay an incoming mail out to your mailing list subscribers you
are retaining the original mail return address in the header, but the
mail is coming from your IP, not the original sender's. For this sender
it will result in an SPF failure because their SPF record (tld.com.au)
at the time of writing is 'v=spf1 include:spf.protection.outlook.com -all'.
A workar
Re: Cannot resolve support@ alias
On 26.10.22 12:07, Dominik George wrote: OK, that's getting stranger. At least it works now – but I don't know why. Postfix started accepting the mail and correctly resolving the alias some time in the night between 24th and 25th of October. I had a script sitting here sending test mails every hour (because all of this was supposed to become a test/benchmark framework for a support hotline system), and I see the log seitching from reject to accept at 0:29 in that night for no obvious reason. did you rebuild the file virtual_alias_maps points to (the one you have aliases in)? -- 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.
Re: started getting 550 #5.7.1 SPF unauthorized mail
Dominic Raferd: > On 25/08/2022 04:41, li...@sbt.net.au wrote: > > I have a simple 'mail list' where an alias 'ct...@sbt.net.au' sends email > > to several recipients, that's been in use since long time. > > > > today noticed one of these addresses started bouncing with '5.7.1 SPF > > unauthorized mail' since just today: One or more of the following has changed: - The owner of the envelope sender domain changed their SPF policy in DNS, - The receiving SMTP server uses different SPF enforcement settings. - The sending SMTP client uses a different SMTP client IP address, - The sending SMTP client sends a different ehlo command (default: smtp_helo_name = $myhostname), - The sending SMTP client sends a different envelope sender address (logged by qmgr, but may be changed with smtp_generic_maps). Wietse
Re: Outlook TLS errors after Microsoft Windows Update
> just wanted to let you know that Outlook users might run into problems > submitting mails after Microsoft's latest Windows update. > > Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: connect from > Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: SSL_accept error from > : lost connection > Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: lost connection after > STARTTLS from > > This occurs on submission port 587 (STARTTLS) and smtps port 465 (TLS). > > Since deinstalling the update no submission errors have occured: > > - Update KB5018418 on Windows 11 (verified) > - Update KB5018410 on Windows 10 This issue is resolved by update KB5018496 for Windows 11 22H2 x64: https://support.microsoft.com/en-us/topic/october-25-2022-kb5018496-os-build-22621-755-preview-64040bea-1e02-4b6d-bad1-b036200c2cb3 October 25, 2022—KB5018496 (OS Build 22621.755) Preview [...] It addresses an issue that might affect some types of Secure Sockets Layer (SSL) and Transport Layer Security (TLS) connections. These connections might have handshake failures. For developers, the affected connections are likely to send multiple frames followed by a partial frame with a size of less than 5 bytes within a single input buffer. If the connection fails, your app will receive the error, “SEC_E_ILLEGAL_MESSAGE”. Best regards Gerald
Re: Outlook TLS errors after Microsoft Windows Update
Gerald Galster: > > just wanted to let you know that Outlook users might run into problems > > submitting mails after Microsoft's latest Windows update. > > > > Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: connect from > > Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: SSL_accept error from > > : lost connection > > Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: lost connection after > > STARTTLS from > > > > This occurs on submission port 587 (STARTTLS) and smtps port 465 (TLS). > > > > Since deinstalling the update no submission errors have occured: > > > > - Update KB5018418 on Windows 11 (verified) > > - Update KB5018410 on Windows 10 > > This issue is resolved by update KB5018496 for Windows 11 22H2 x64: Thanks. I am not failiar with Microsoft's processes, is this something that could be deployed globally next patch Tuesday? Wietse
Re: Outlook TLS errors after Microsoft Windows Update
On Wed, Oct 26, 2022 at 03:56:29PM +0200, Gerald Galster wrote: > This issue is resolved by update KB5018496 for Windows 11 22H2 x64: > > https://support.microsoft.com/en-us/topic/october-25-2022-kb5018496-os-build-22621-755-preview-64040bea-1e02-4b6d-bad1-b036200c2cb3 > > October 25, 2022—KB5018496 (OS Build 22621.755) Preview > [...] > It addresses an issue that might affect some types of Secure Sockets > Layer (SSL) and Transport Layer Security (TLS) connections. These > connections might have handshake failures. For developers, the > affected connections are likely to send multiple frames followed by a > partial frame with a size of less than 5 bytes within a single input > buffer. If the connection fails, your app will receive the error, > “SEC_E_ILLEGAL_MESSAGE”. There were perhaps additional resolved issues that were not mentioned, since the PCAP files show no such packets. However, if the immediate issue is no longer reproducible, I guess that's progress. -- Viktor.
Re: [External] Re: Outlook TLS errors after Microsoft Windows Update
On 10/26/2022 10:56 AM, Viktor Dukhovni wrote: RAPTOR REMARK: Alert! Please be careful! This email is from an EXTERNAL sender. Be aware of impersonation and credential theft. On Wed, Oct 26, 2022 at 03:56:29PM +0200, Gerald Galster wrote: This issue is resolved by update KB5018496 for Windows 11 22H2 x64: https://support.microsoft.com/en-us/topic/october-25-2022-kb5018496-os-build-22621-755-preview-64040bea-1e02-4b6d-bad1-b036200c2cb3 October 25, 2022—KB5018496 (OS Build 22621.755) Preview [...] It addresses an issue that might affect some types of Secure Sockets Layer (SSL) and Transport Layer Security (TLS) connections. These connections might have handshake failures. For developers, the affected connections are likely to send multiple frames followed by a partial frame with a size of less than 5 bytes within a single input buffer. If the connection fails, your app will receive the error, “SEC_E_ILLEGAL_MESSAGE”. There were perhaps additional resolved issues that were not mentioned, since the PCAP files show no such packets. However, if the immediate issue is no longer reproducible, I guess that's progress. I wanted to mention that the update also broke some of the older Adobe products we had in use because the DRM comms channels used TLS 1.0 and I believe it disabled everything by TLS 1.2 in Edge by default. Not necessarily saying Microsoft's choice was bad but it points out Adobe's poor infrastructure for their DRM. Regards, KAM
Re: Outlook TLS errors after Microsoft Windows Update
>>> just wanted to let you know that Outlook users might run into problems >>> submitting mails after Microsoft's latest Windows update. >>> >>> Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: connect from >>> Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: SSL_accept error from >>> : lost connection >>> Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: lost connection after >>> STARTTLS from >>> >>> This occurs on submission port 587 (STARTTLS) and smtps port 465 (TLS). >>> >>> Since deinstalling the update no submission errors have occured: >>> >>> - Update KB5018418 on Windows 11 (verified) >>> - Update KB5018410 on Windows 10 >> >> This issue is resolved by update KB5018496 for Windows 11 22H2 x64: > > Thanks. I am not failiar with Microsoft's processes, is this something > that could be deployed globally next patch Tuesday? I'm not familiar with Microsoft's release schedule either, but this update seems to be publicly available since yesterday. I've started Windows 11 today and checked for updates in system settings where it suggested to download and install KB5018496. Afterwards I enabled session tickets for postfix submission again and was able to submit an email. So I can confirm it works with Windows 11 and as Microsoft is aware of the problem it might have been or will be fixed for Windows 10 as well. Best regards Gerald
Re: Outlook TLS errors after Microsoft Windows Update
On 10/26/2022 9:34 AM, Wietse Venema wrote: Gerald Galster: just wanted to let you know that Outlook users might run into problems submitting mails after Microsoft's latest Windows update. Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: connect from Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: SSL_accept error from : lost connection Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: lost connection after STARTTLS from This occurs on submission port 587 (STARTTLS) and smtps port 465 (TLS). Since deinstalling the update no submission errors have occured: - Update KB5018418 on Windows 11 (verified) - Update KB5018410 on Windows 10 This issue is resolved by update KB5018496 for Windows 11 22H2 x64: Thanks. I am not failiar with Microsoft's processes, is this something that could be deployed globally next patch Tuesday? Wietse We've had to deploy this to a bunch of Win10 machines that broke a business voice/video app. We don't use Outlook, but the symptoms were essentially the same; unexpected TLS failures after the previous update. Microsoft lists the fix as a Cumulative Update Preview, so I expect/hope it will be included in the scheduled November update. -- Noel Jones
MX records and relayhost: Am I going this correctly ?
MX Records: mydomain.tld. 33 IN MX 10 relay-1.mydomain.tld. mydomain.tld. 33 IN MX 20 relay-2.mydomain.tld. with relay-1 and relay-2 having appropriate A and PTR records. Then in /etc/postfix/main.cf, I have relayhost = mydomain.tld I have seen this work with relay-1 unavailable. The outgoing message sat in the queue for a brief time, then went out through relay-2. I found a Red Hat solution https://access.redhat.com/solutions/4025391 that suggests using relayhost = [relay-1.mydomain.tld] smtp_fallback_relay = [relay-2.mydomain.tld] Comments ? Suggestions ?
Re: MX records and relayhost: Am I going this correctly ?
White, Daniel E. (GSFC-770.0)[AEGIS]: > MX Records: > > mydomain.tld. 33 IN MX 10 relay-1.mydomain.tld. > mydomain.tld. 33 IN MX 20 relay-2.mydomain.tld. > > with relay-1 and relay-2 having appropriate A and PTR records. > > Then in /etc/postfix/main.cf, I have > >relayhost = mydomain.tld > > I have seen this work with relay-1 unavailable. This is the obvious (to me) approach when the domain has multiple MX hosts. It is also similar to the first relayhost example in the stock main.cf file: relayhost = $mydomain > The outgoing message sat in the queue for a brief time, then went > out through relay-2. > > I found a Red Hat solution https://access.redhat.com/solutions/4025391 > that suggests using > > relayhost = [relay-1.mydomain.tld] > smtp_fallback_relay = [relay-2.mydomain.tld] This also works, but it would be less obvious to me. Wietse
Re: [EXTERNAL] Re: MX records and relayhost: Am I going this correctly ?
Many thanks for the sanity check, Mr. Postfix I am using the explicit domain name rather than $mydomain mainly on client machines because they are not guaranteed to have the same domain as the mail servers. Is there any way to shorten/remove the delay I saw in the MX-failover ? Again, many thanks for the quick response From: on behalf of Wietse Venema Reply-To: Postfix users Date: Wednesday, October 26, 2022 at 14:09 To: Postfix users Subject: [EXTERNAL] Re: MX records and relayhost: Am I going this correctly ? White, Daniel E. (GSFC-770.0)[AEGIS]: MX Records: mydomain.tld. 33 INMX 10 relay-1.mydomain.tld. mydomain.tld. 33 INMX 20 relay-2.mydomain.tld. with relay-1 and relay-2 having appropriate A and PTR records. Then in /etc/postfix/main.cf, I have relayhost = mydomain.tld I have seen this work with relay-1 unavailable. This is the obvious (to me) approach when the domain has multiple MX hosts. It is also similar to the first relayhost example in the stock main.cf file: relayhost = $mydomain The outgoing message sat in the queue for a brief time, then went out through relay-2. I found a Red Hat solution https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F4025391&data=05%7C01%7Cdaniel.e.white%40nasa.gov%7Cec472cf769824ce55a8e08dab77d47f4%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638024045956278652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WFi3rKroF5DsLvomCS5NcG9%2ByCKQOlC3ITI1KFW4oyU%3D&reserved=0 that suggests using relayhost = [relay-1.mydomain.tld] smtp_fallback_relay = [relay-2.mydomain.tld] This also works, but it would be less obvious to me. Wietse
Re: [EXTERNAL] Re: MX records and relayhost: Am I going this correctly ?
White, Daniel E. (GSFC-770.0)[AEGIS]: > Many thanks for the sanity check, Mr. Postfix > > I am using the explicit domain name rather than $mydomain mainly on client > machines because they are not guaranteed to have the same domain as the mail > servers. > > Is there any way to shorten/remove the delay I saw in the MX-failover ? By reducing smtp_connect_timeout from the default 300s to a more reasonable value, maybe 10-30s. Note that Postfix will shuffle the order of equal-preference MX hosts, so that a down server will delay only some of the traffic. Wietse > Again, many thanks for the quick response > > From: on behalf of Wietse Venema > > Reply-To: Postfix users > Date: Wednesday, October 26, 2022 at 14:09 > To: Postfix users > Subject: [EXTERNAL] Re: MX records and relayhost: Am I going this correctly ? > > White, Daniel E. (GSFC-770.0)[AEGIS]: > MX Records: > >mydomain.tld. 33 INMX 10 > relay-1.mydomain.tld. >mydomain.tld. 33 INMX 20 > relay-2.mydomain.tld. > > with relay-1 and relay-2 having appropriate A and PTR records. > > Then in /etc/postfix/main.cf, I have > > relayhost = mydomain.tld > > I have seen this work with relay-1 unavailable. > > This is the obvious (to me) approach when the domain has multiple > MX hosts. It is also similar to the first relayhost example in the > stock main.cf file: > > relayhost = $mydomain > > The outgoing message sat in the queue for a brief time, then went > out through relay-2. > > I found a Red Hat solution > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F4025391&data=05%7C01%7Cdaniel.e.white%40nasa.gov%7Cec472cf769824ce55a8e08dab77d47f4%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638024045956278652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WFi3rKroF5DsLvomCS5NcG9%2ByCKQOlC3ITI1KFW4oyU%3D&reserved=0 > that suggests using > >relayhost = [relay-1.mydomain.tld] >smtp_fallback_relay = [relay-2.mydomain.tld] > > This also works, but it would be less obvious to me. > > Wietse > >
