This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[8.201] RDNS missing

I saw the other thread but it is locked currently.

I have been noticing a large increase of 'RDNS missing' entries in the Mail Log.

Typically a user sends me a message that they have not been getting mail (often the client sends it from a gmail or such to inform them).  Verify the log and see the RDNS entries.  Pop over to MXToolbox and run their checks and see it labeled as OK on the RDNS check.

So I am at a loss as to why it is occurring.

For example: seagullscientific.invisionzone.com - this is a support forum for label software, it got a RDNS missing despite it appears to be all correct (unless i'm missing something).  Astaro logged it as coming from 208.67.212.34


This thread was automatically locked due to age.
Parents
  • 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...
  • 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......
Reply
  • 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......
Children
No Data