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:


    Code
    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:



    Code
    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.

    • Offizieller Beitrag

    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.

  • 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.

    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?

  • My experience is that OMV email notification is broken and only works with Gmail. Any other email provider that I've tried will reject the email with the error that the OP mentioned.

  • 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:


    Code
    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:


    Code
    127.0.0.1       localhost
    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:



    Code
    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:


    Code
    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.

    • Offizieller Beitrag

    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 https://github.com/openmediava…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.

  • 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.

    • Offizieller Beitrag

    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 https://github.com/openmediava…91c6cabdae1b7f2ec8dd090a3.


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


    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.

  • 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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!