开云体育

  1. GroupManagersForum
  2. Topics

Reverse DNS does not match the SMTP Banner on the server

 

Hello, I manage a forum (of 600) and I have a small percentage of members who are??persistently thrown into "bouncing" mode without an obvious reason. I have always suspect spam filters are the issue, but didn't know for sure. It has been a real drag.

Today I get a message from a bouncing member who had their IT tech look into it. Here's the response: "I see where they have a problem…. Their Reverse DNS does not match the SMTP Banner on their server…. So, they made a change that puts them in direct violation of a rule that runs on your email server’s SPAM filter."?

Does anyone have more information on this? Is Groups.io aware of the issue and doing anything about it?

Doug Becker
 

On Tue, May 10, 2022 at 03:53 PM, Doug Becker wrote:
Is Groups.io aware of the issue and doing anything about it?
I don't think it's Groups.io's problem, it appears to be the email receiving service for the member.? This happens pretty regularly with some services.? Things get tweaked or replaced and some of the settings no longer match up.? You can look at the member's Email Delivery History, in the Bounces section at the bottom, for additional details that might help.

Duane
--
Lots of detailed information can be found in the Owners Manual and Members Manual.
 

开云体育

I’ve gotten further data. I think it shows it’s a Groups io problem, but I’m not techie enough to be sure.

image0.jpeg

On May 10, 2022, at 2:51 PM, Duane <txpigeon@...> wrote:

On Tue, May 10, 2022 at 03:53 PM, Doug Becker wrote:
Is aware of the issue and doing anything about it?
I don't think it's 's problem, it appears to be the email receiving service for the member.? This happens pretty regularly with some services.? Things get tweaked or replaced and some of the settings no longer match up.? You can look at the member's Email Delivery History, in the Bounces section at the bottom, for additional details that might help.

Duane
--
Lots of detailed information can be found in the Owners Manual and Members Manual.

 

开云体育

Here is how my member’s IT tech describes the screenshot below:

Mismatch is on their end, not yours….
?
More importantly, they need to check it for themselves…. Both mail servers suffer from the SMTP banner/RDNS mismatch…….
They can test it for themselves:?


image0.jpeg

On May 10, 2022, at 2:51 PM, Duane <txpigeon@...> wrote:

On Tue, May 10, 2022 at 03:53 PM, Doug Becker wrote:
Is aware of the issue and doing anything about it?
I don't think it's 's problem, it appears to be the email receiving service for the member.? This happens pretty regularly with some services.? Things get tweaked or replaced and some of the settings no longer match up.? You can look at the member's Email Delivery History, in the Bounces section at the bottom, for additional details that might help.

Duane
--
Lots of detailed information can be found in the Owners Manual and Members Manual.

 

On Tue, May 10, 2022 at 05:05 PM, Doug Becker wrote:
I think it shows it’s a Groups io problem, but I’m not techie enough to be sure.
The 173.255.221.194 address is for the web site.? The email servers that Groups.io uses are 66.175.222.12 and 66.175.222.108.? Unless it's a recent change that I haven't heard of, there should be no messages sent from the .194 address.? Maybe someone else knows for sure.

Duane
--
Lots of detailed information can be found in the Owners Manual and Members Manual.
 

The tech is not exactly wrong but he's not exactly right, either. This is because GIO is a fairly unique case.
?
I'm not affiliated with GIO but I know (from past Mark messages) that GIO uses separate servers for inbound (lb01 at 45.79.81.153 and lb02 at 173.255.221.194) and outbound (web01 at 66.175.222.12 and mail02 at 66.175.222.108) email. The outbound servers do not allow inbound connections whatsoever (I know because I checked) so there is no way to check the "SMTP Banner" on either of them. This is not uncommon on large-volume providers. As a result, you cannot rely on MxToolBox because it is impossible for them to create a "tool" for this scenario.
?
The inbound email servers indicated by the MX entries in DNS (lb01 at 45.79.81.153 and lb02 at 173.255.221.194) are the same as the IP's for the web sites. (I strongly disagree that GIO should be using the same IP's for the web sites and inbound email servers but that's a separate issue.)
?
The tech is correct that the MX servers do not match the SMTP Banner because both report "groups.io" instead of lb01 and lb02, respectively. However, this has no bearing on the receipt of email and the tech should concentrate only on the email header because, for speed and efficiency, email systems only check information regarding the IP that is connecting to it's system and which is attempting to transmit email for a particular domain.
?
Each outbound server has the correct entries for Reverse DNS and are authorized to transmit on behalf of groups.io according to the SPF record. GIO does not do DMARC due to complexity and the probability that it cannot accommodate GIO's circumstance.
?
So, the other major mitigating factors are reputation (blacklisting) and clamps on volume at various ISP's around the country. This is the bane of GIO's existence and the most major reason for "bouncing" messages. I know that GIO makes every effort to placate those providers but it is really out of the control of GIO. Sadly, most end-users are also at the mercy of these ISP's because they rarely listen to customers when so few are affected but one should still voice their complaints with the ISP. The alternative is to use a separate email provider that works better.
?
--
Jim
 

开云体育

Jim,

Many thanks for taking the time to explain that. It’s super helpful.

Doug

On May 11, 2022, at 7:27 AM, Jim Wilson via <groupsio@...> wrote:

The tech is not exactly wrong but he's not exactly right, either. This is because GIO is a fairly unique case.
?
I'm not affiliated with GIO but I know (from past Mark messages) that GIO uses separate servers for inbound (lb01 at 45.79.81.153 and lb02 at 173.255.221.194) and outbound (web01 at 66.175.222.12 and mail02 at 66.175.222.108) email. The outbound servers do not allow inbound connections whatsoever (I know because I checked) so there is no way to check the "SMTP Banner" on either of them. This is not uncommon on large-volume providers. As a result, you cannot rely on MxToolBox because it is impossible for them to create a "tool" for this scenario.
?
The inbound email servers indicated by the MX entries in DNS (lb01 at 45.79.81.153 and lb02 at 173.255.221.194) are the same as the IP's for the web sites. (I strongly disagree that GIO should be using the same IP's for the web sites and inbound email servers but that's a separate issue.)
?
The tech is correct that the MX servers do not match the SMTP Banner because both report "" instead of lb01 and lb02, respectively. However, this has no bearing on the receipt of email and the tech should concentrate only on the email header because, for speed and efficiency, email systems only check information regarding the IP that is connecting to it's system and which is attempting to transmit email for a particular domain.
?
Each outbound server has the correct entries for Reverse DNS and are authorized to transmit on behalf of according to the SPF record. GIO does not do DMARC due to complexity and the probability that it cannot accommodate GIO's circumstance.
?
So, the other major mitigating factors are reputation (blacklisting) and clamps on volume at various ISP's around the country. This is the bane of GIO's existence and the most major reason for "bouncing" messages. I know that GIO makes every effort to placate those providers but it is really out of the control of GIO. Sadly, most end-users are also at the mercy of these ISP's because they rarely listen to customers when so few are affected but one should still voice their complaints with the ISP. The alternative is to use a separate email provider that works better.
?
--
Jim

1 - 7 of 7