Comcast Shot Themselves in the Foot with MTA-STS

Re:Comcast Shot Themselves in the Foot with MTA-STS by LinuxBender on Wednesday January 19, 2022 @03:05PM (#29999222)

Wouldn't the simplest work around be to just remove mx2h1.comcast.net and mx1a1.comcast.net from the MX records for at least 2592000 seconds and instead add the IP addresses of those mail servers vips to other existing DNS records that were properly in the STS file?

e.g.

  dig +short mx2h1.comcast.net
  96.102.157.179

  dig +short mx1a1.comcast.net
  96.103.145.165

So just add 96.102.157.179 to mx2c1.comcast.net and add 96.103.145.165 to mx1h1.comcast.net or something along that line? Their MX TTL is only 300 seconds.

[ Parent | on HN ]

Re:Comcast Shot Themselves in the Foot with MTA-STS by agwa on Wednesday January 19, 2022 @03:50PM (#29999926)

Comcast just needs to rotate the ID in the _mta-sts.comcast.net TXT record. That will cause sending mail servers to download the new policy.

[ Parent | on HN ]

Re:Comcast Shot Themselves in the Foot with MTA-STS by LinuxBender on Wednesday January 19, 2022 @04:13PM (#30000227)

Well that's way too easy. I supposed I improperly assumed that the results would be cached longer than the TTL of the TXT record based on the expiration in the well-known text file. In that case they should have only seen a tiny window of time that emails remained in queues. I will have to read up on the RFC for MTA-STS a bit more.

In that case I would suggest they did not really shoot themselves in the feet. Rather they may have stubbed their toe.

[ Parent | on HN ]