Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sender dependent relay should NOT require RELAY_HOST env #3970

Closed
1 task done
szguoxz opened this issue Apr 5, 2024 · 6 comments
Closed
1 task done

Sender dependent relay should NOT require RELAY_HOST env #3970

szguoxz opened this issue Apr 5, 2024 · 6 comments
Labels
kind/bug/report A report about a bug meta/closed due to age or inactivity This issue / PR has been closed due inactivity meta/needs triage This issue / PR needs checks and verification from maintainers meta/stale This issue / PR has become stale and will be closed if there is no further activity

Comments

@szguoxz
Copy link

szguoxz commented Apr 5, 2024

📝 Preliminary Checks

  • I tried searching for an existing issue and followed the debugging docs advice, but still need assistance.

👀 What Happened?

I hosted a multiple-domain email server. One of the domain: A needs to use AWS relay ses.
So I use setup relay add, to add relay host for domain A, and modify postfix-sasl-password.cf to include the uername password.

Then I try to send out emails, it does not work. Email is not sent.
Then I added the ENV setting for RELAY_HOST, try again it works.

But I don't need relay for other domains. setting RELAY_HOST just seem weird. Right, it seems like just a flag, has value, relay works. no value, relay stopped.
Besides, just don't see the difference between: DEFAULT_RELATY_HOST and RELAY_HOST, the doc is simply not clear.

👟 Reproduction Steps

No response

🐋 DMS Version

V13.3.1

💻 Operating System and Architecture

ubuntu

⚙️ Container configuration files

No response

📜 Relevant log output

No response

Improvements to this form?

No response

@szguoxz szguoxz added kind/bug/report A report about a bug meta/needs triage This issue / PR needs checks and verification from maintainers labels Apr 5, 2024
Copy link

glime-ai bot commented Apr 5, 2024

Please note that this response was created using generative AI, leveraging previously available information from the repository. This information may be helpful. However, it is our strong recommendation that you carefully consider the information before blindly applying it.


Based on the information provided and the documentation available, it seems like you've encountered a common confusion regarding the use of RELAY_HOST and DEFAULT_RELAY_HOST environment variables in Docker Mailserver (DMS) when configuring a relay host for a specific domain.

  1. Difference between RELAY_HOST and DEFAULT_RELAY_HOST: Both environment variables are used to configure a default SMTP relay host for outbound emails. However, DEFAULT_RELAY_HOST is preferable because it is compatible with LDAP, whereas RELAY_HOST is not. The DEFAULT_RELAY_HOST is a newer, more flexible implementation that should be used unless you need support for sender domain opt-out (via setup relay exclude-domain), which is only supported with RELAY_HOST.

  2. Configuring Relay for Specific Domain: When you want to configure a relay host for a specific domain (e.g., domain A using AWS SES), you should use the setup relay add-domain and setup relay add-auth commands to specify the domain and its authentication credentials. This approach allows you to configure relay hosts on a per-domain basis without affecting the relay settings for other domains hosted on the same DMS instance.

  3. Why Setting RELAY_HOST Made it Work: It's possible that setting the RELAY_HOST environment variable globally enabled the relay functionality for your DMS instance, but this is not the recommended approach for a multi-domain setup where only specific domains require relaying. The correct approach is to use the setup relay commands as mentioned above.

  4. Troubleshooting: If emails are not being sent out after configuring the relay for a specific domain, ensure that:

    • The domain-specific relay configuration is correctly set up in postfix-sasl-password.cf and postfix-relaymap.cf.
    • The credentials and relay host details are correct.
    • There are no typos or syntax errors in your configuration files.
    • Review the mail server logs for any errors or messages related to the relay configuration.

For further assistance, please provide more details about the exact commands you used to configure the relay for domain A and any relevant log output that indicates why the emails were not being sent.

This comment was generated by Glime.

@polarathene
Copy link
Member

Besides, just don't see the difference between: DEFAULT_RELAY_HOST and RELAY_HOST, the doc is simply not clear.

It was a legacy issue as these features were contributed by different users in the past AFAIK for their specific needs. We didn't have the same level of quality for reviews back then.

I have refactored it twice since and with edge (should be released as v14 this month sometime), there my 2nd refactor fixes the concern you've raised here with the inconsistency / bugs. I also rewrote the docs (see here for direct links).

On the new doc pages I mentioned, at the bottom of the relay host page is a technical details admonition. This shows relevant Postfix config you could use via postfix-main.cf instead of the existing ENV var feature support.

image

For reference, the page also better documents the two config files that the setup command helps manage:

image

If you're comfortable trying :edge image out to let me know if that is working much better now, I'd appreciate that as I'd like to know if I've missed anything (see the rewritten ENV docs section for additional insights). I also rewrote the AWS SES page which may be relevant to you?


There is still some larger refactoring work planned for this feature in future, if you'd like to subscribe to the tracking issue it is here: #3607

@szguoxz
Copy link
Author

szguoxz commented Apr 6, 2024 via email

@polarathene
Copy link
Member

Did you fix another issue that has been a pain in ass for a while with setup Alias?
Right now, I can’t forward a copy of my email to another account, as setup Alia’s add does not allow me to add a forward for a real email account!

No, the command has logic to prevent having an alias and actual account with the same address. This was due to various issues in the past where users misused the feature IIRC. You can find details and workarounds on a relevant issue here: #3022 (comment)

Wanting to accept mail for a legit account and send a copy to another address is a use-case that several users have wanted since that is valid. I'm not familiar with other solutions instead of using an alias that points to an account of the same name to achieve that same functionality.

For now you can use the workaround with a manual edit of postfix-virtual.cf, or you can wait until someone contributes a PR that maintainers approve. I don't think any of the active maintainers are going to fix one problem to introduce the previous problem though, but they'd probably be open to an option like --force for the setup command to ignore the guard.

Feel free to open a new issue as a feature request for that if you're not comfortable contributing it, someone may come along and tackle it 👍

Copy link
Contributor

This issue has become stale because it has been open for 20 days without activity.
This issue will be closed in 10 days automatically unless:

  • a maintainer removes the meta/stale label or adds the stale-bot/ignore label
  • new activity occurs, such as a new comment

@github-actions github-actions bot added the meta/stale This issue / PR has become stale and will be closed if there is no further activity label Apr 27, 2024
Copy link
Contributor

github-actions bot commented May 7, 2024

This issue was closed due to inactivity.

@github-actions github-actions bot added the meta/closed due to age or inactivity This issue / PR has been closed due inactivity label May 7, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug/report A report about a bug meta/closed due to age or inactivity This issue / PR has been closed due inactivity meta/needs triage This issue / PR needs checks and verification from maintainers meta/stale This issue / PR has become stale and will be closed if there is no further activity
Projects
None yet
Development

No branches or pull requests

2 participants