[8.201] RDNS missing

Hi Guys,

Just to keep you informed, we are planning to revert the default behavior back to the 'old' way, and then offer a 'strict' option for those who wish to perform the more aggressive (and RFC/"correct") check.

We should have this out in the middle of October, if not before.

Thanks Angelo.

Ah, good news. However why do you guys change things like that and don't tell everyone before we have to learn it the hard way.

Apologies Krycek, the intent is of course not to disrupt customers. In this case, the idea of making it "correct" wasn't known to have such an impact on currently configured installations. However we will indeed adjust accordingly to accomodate both the "right" way and the way that currently "works".

The RFC's always demand their lb of flesh it seems...

Don't get me wrong, I'm totally in favor of doing it "right". It's just so easy to let people know "hey, we noticed our rDNS check wasn't doing things how we intended it, so we changed it in v8.***."

Well thanks for the clarification. It mostly works, just some people out there in charge of mailservers don't seem to care much for RFCs and since it is never their fault or they don't have any admin, of course it's our end that has to do something about it, since we "block" them. *sigh* Anyhow, looking forward to the fix and thanks again for letting us know now [:)]

Arrgh!  How about a bit more precision in the documentation delivered with the Astaro?

So, prior to V8, we had:

1. In response to HELO/EHLO, 204.184.214.252 responds "spsmail.org"
2. a. In response to "252.214.184.204.in-addr.arpa" DNS returns "spsmail.org" => Test passes
2. b. In response to "252.214.184.204.in-addr.arpa" DNS returns "204.184.214.252-more.net" => test fails

In V8 up through 8.201, we have:

1. a. In response to "252.214.184.204.in-addr.arpa" DNS returns "spsmail.org"
1. b. In response to "252.214.184.204.in-addr.arpa" DNS returns "204.184.214.252-more.net" => test fails
2. a. In response to "spsmail.org" DNS returns 204.184.214.252 => test passes
2. b. In response to "spsmail.org" DNS returns 204.184.214.253 => test fails

Is that right?  What will the documentation show?

Cheers - Bob

Don't get me wrong, I'm totally in favor of doing it "right". 

There is some question here as to whether this is "right" though.  If I'm not mistaken, the RFC really only says that a mail server must have RDNS configured to be compliant.  There really isn't a requirement to have the PTR match the HELO, etc.  It's become more and more common for mail servers (especially anti-spam systems) to decide that the HELO and PTR match, but that's not what the original intent of a PTR was back in the days where just just wanted mail to be legit.  After ISPs started making PTRs for just about every IP address out there, folks tried to find ways to tighten up the checks.

I too have been bouncing a lot of mail lately that I don't want to bounce, and have to turn this check off until it's fixed!

Apologies Krycek, the intent is of course not to disrupt customers. In this case, the idea of making it "correct" wasn't known to have such an impact on currently configured installations. However we will indeed adjust accordingly to accomodate both the "right" way and the way that currently "works".

The RFC's always demand their lb of flesh it seems...

Well I hate to say it but my customers are demanding a hell of a lot more than a LB of flesh.......  

This RDNS has become a typical Astaro problem. And the problem isn't so much on the technical side, but in the way Astaro handled it the now too common way which is both arrogant and slow.

1) Astaro Programmers made a change for "proper" behavior and failed to document it in the release notes. - Not Acceptable you changed it; you can't release it if you haven't documented how the heck are we suppose to know what changed.

2) Astaro Programmers didn't consider the implications of tightening up a SPAM check that typically accounts for over 50% of the spam blocked. No one bothered to consider what would happen if customers had to turn off RDNS if the tighter check was a problem for them. If it wasn't "known to have such a impact" maybe it should have tested it. All new Behaviors need to be vetted or they shouldn't be done.

3) A ton of us reported the problem both to Support and on the forums. Until recently the only response was "you customers are wrong it's doing the right thing, I'm going to lock this thread cause you are all dumb". Hate to say it but those of us using the units in the field; we do know what we are doing; and blowing off the reports it irresponsible. If tons of people are complaining then you show get the hint that while you might be technically correct; you've likely put your foot into a Logic error that you didn't foresee.

Frankly this is getting absurd.... Astaro has to start forking the code base more. Fix BUGS with your updates; and leave features changes and new features to MAJOR releases. Any Change in behavior needs to continue to support the OLD mode. IF you want to retire old behaviors then do that at MAJOR Releases. This is software development 101.... 

These are security Gateways we REALLY need to patch them to keep them secure but you guys are making it darn impossible to do that because you are blending security fixes and features releases into the same revisions.  8.201 has been a disaster of epic proportion for our firm with 30 firewalls affected. 

Ok would someone help me down from my soap box before I fall over. I have to get back to whitelisting the 30+ email address bounce back complaints that came into the helpdesk line this morning......

While you are at it; if you are going to have a STRICT mode. Then lets consider call it by the right name.  What has cause all the problems is that the system now uses Forward-confirmed Reverse DNS.  Forward-confirmed reverse DNS - Wikipedia, the free encyclopedia


Previously it was just using Reverse_DNS against connected ipAddress Reverse DNS lookup - Wikipedia, the free encyclopedia


Those article gloss over the RFCs' for those that don't want to read the gory stuff. If should be noted that the FCrDNS article goes so far as to warn that it should not be used to reject email by Default as it does violate several of the clauses in RFC2821. RFC 2821 - Simple Mail Transfer Protocol specially load balanced internet connections are going to have problems with FCrDNS.

leave features changes and new features to MAJOR releases

With Astaro's naming system, a change to the first decimal place number is considered a major release.  Examples:

8.100 - major release
8.101 - bugfix
8.200 - major release

Every vendor does their numbering differently.  Better than Mozillas' new plan for Firefox.  6.x released in August, 7.x released in September, etc.  I think they're trying to hit 100.x before the decade ends.