Postfix error - Sender address rejected: Domain not found (in reply to RCPT TO command))

    • OMV 3.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Postfix error - Sender address rejected: Domain not found (in reply to RCPT TO command))

      Hi,
      I'm currently running OMV 3.0.76 with a made up intranet domain (intranet.lan).
      I just found out that the Notifications configuration doesn't work with non qualified domain as it returns the following error:

      Source Code

      1. Sender address rejected: Domain not found (in reply to RCPT TO command))


      Unfortunately the web interface doesn't provide (or I didn't find it) a way to configure the email domain, but I still managed to solve the issue by editing /etc/postfix/main.cf and by adding:


      Source Code

      1. myorigin = exampledomain.com

      So that all my outgoing email get their address rewritten correctly.
      It would be great to be able to configure such variable directly from the web interface or, even better, to have an "extra configurations" box dedicated to postfix.
    • Such a configuration option will never be included into the WebUI because OMV is no webmin interface. The only possible solutionwould be to implement a logic that checks if it is required to add an 'myorigin' configuration line to the main.cf file. You are welcome to contribute such an improvement.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • votdev wrote:

      Such a configuration option will never be included into the WebUI because OMV is no webmin interface. The only possible solutionwould be to implement a logic that checks if it is required to add an 'myorigin' configuration line to the main.cf file. You are welcome to contribute such an improvement.
      @votdev thank you for your feedback. That's fair enough, but I think it's also reasonable for unexperienced users to expect the Notification section to work out of the box without manual intervention (and without knowledge of the Postfix address rewriting feature).
      Maybe a possible workaround would be to automatically initialize the myorigin value by extracting the domain from the sender email address inserted by the user.
      What do you think?
    • I don't think this is a good idea. Most of the users are using Google Mail or other free email providers.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • votdev wrote:

      I don't think this is a good idea. Most of the users are using Google Mail or other free email providers.
      I'm not sure why that wouldn't be a good idea. Setting the domain in the 'myorigin' would allow people using their own domains to send notifications with no manual intervention needed and free providers users wouldn't get affected by such change.
      What would be the negative outcome of adding such autoconfiguration?
    • I'm no postfix expert, but all howtos about using postfix as a satellite do not mention such setting. There must be something else that will fix this issue the correct way. Please note, if email would not work, then the bugtracker would be filled with errors. But that is not the case, so your problem is not a general one.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • votdev wrote:

      I'm no postfix expert, but all howtos about using postfix as a satellite do not mention such setting. There must be something else that will fix this issue the correct way. Please note, if email would not work, then the bugtracker would be filled with errors. But that is not the case, so your problem is not a general one.

      The reason why it is not mentioned is that, according to the best practice of intranet LAN configurations, people should use a TLD valid domain for their intranet, meaning that give a "nas01" machine, its /etc/hosts will contain:

      Source Code

      1. 127.0.0.1 nas01.valid_domain.com
      As this is very far from the real usage of intranet domains (especially for non enterprise users) the result is that many people end up with intranet unresolvable domains (i.e.: host1.intranet.lan), which are not against any RFC, and their /etc/hosts will be something like:

      Source Code

      1. 127.0.0.1 localhost
      2. 127.0.1.1 nas01.local nas01.intranet.lan

      Based on the best practice, Postfix assumes that your machine domain is a valid TLD domain, so it uses your local domain to present itself to the foreign SMTP server. What happens next is that OMV ends up presenting itself to smtpd processes with a:


      Source Code

      1. MAIL FROM:<root@nas01.local> SIZE=472

      Which is an unresolvable address, therefore it will get rejected by the foreign smtpd with the following error:

      Source Code

      1. 450 4.1.8 <root@nas01.local>: Sender address rejected: Domain not found

      The fact that Gmail allows such "fakemails" for TLS protected and authenticated session it's a totally different matter, which it's Google's exclusive choice which is a pure exception and absolutely NOT the right way to handle this scenario.
      That is why the address rewrite feature should be enabled through the myorigin parameter, so that all OMV installations will present to foreign smtpd servers with resolvable TLD domains.
      All this can be easily checked by snooping the SMTP transactions.
    • But because of that reason the files /etc/postfix/recipient_canonical and /etc/postfix/sender_canonical rewrite the outgoing email adresses to valid ones, see github.com/openmediavault/open…conf/postfix.d/50misc#L84.

      If this is not working in all cases, then we have to fix this THERE. All postfix settings MUST be derived from existing system configurations, no other options will be added to the OMV configuration.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • votdev wrote:

      But because of that reason the files /etc/postfix/recipient_canonical and /etc/postfix/sender_canonical rewrite the outgoing email adresses to valid ones, see github.com/openmediavault/open…conf/postfix.d/50misc#L84.
      If you want to rewrite outgoing addresses, then the two correct ways are either:
      • myorigin implementation
      Or
      • smtp_generic_maps implementation
      The sender/recipient_canonical approach is kind of a "deprecated" approach which can lead to wrong configurations.
      For instance, the /etc/postfix/sender_canonical autoconfigured by OMV on my system will never replace any outgoing address as the used regexps are just totally wrong.
      I would assume that OMV reads the hostname from the /etc/hosts file, as my sender_canonical tries to match the last hostname I have in my 127.0.0.1 record, while it should actually use the hostname generated by the "hostname -f" command.
    • onixid wrote:

      For instance, the /etc/postfix/sender_canonical autoconfigured by OMV on my system will never replace any outgoing address as the used regexps are just totally wrong.
      Fixed with github.com/openmediavault/open…91c6cabdae1b7f2ec8dd090a3.

      Maybe you could suggest improvements next time. As a tip, sender_canonical was no regex map, it was a hash map.

      onixid wrote:

      If you want to rewrite outgoing addresses, then the two correct ways are either:


      myorigin implementation
      Or


      smtp_generic_maps implementation
      The sender/recipient_canonical approach is kind of a "deprecated" approach which can lead to wrong configurations.
      Many roads lead to Rome. Until recipient_canonical is not removed from postfix it will be used because it works.

      If you have better suggestions, feel free to contribute your improvement via pull request on Github.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • votdev wrote:

      Maybe you could suggest improvements next time.
      I believe it is what I've done, I didn't just report a problem, I actually provided a solution along with it so that if other users fall into the same issue they actually have an available solution (I even provided 2 more workarounds for it).
      I don't really understand the harshness of your statement, I didn't come here to blame anyone or to bossy around. I found an issue in OMV, I debugged it and I found a solution on my own, then I came here to share it with the developers and the community. I honestly wasn't expecting this pushback attitude.
      Said that, I do not fully agree that it is correct to keep using the same approach just cause it exists. Softwares evolve and so should the code based on their features, of course no one forces you to do so, it's just a matter of best practice and keeping approaches up to date with the current standards. On the other hand I do fully understand the massive amount of code you guys have to maintain, so it is totally reasonable that you'd rather spend your effort dealing with other stuff.
      If I will ever find enough time to get through the OMV source code and structure I will indeed try to contribute by submitting pull requests, simply, as I'm a very new user I thought this would have been way faster than that.