How to keep your mailbox outside yunohost

Discuss Tutorials
1

This tuto is here to help you to configure your yunohost to be able to keep your mailbox @YOURDOMAIN.TLD on your registrar and to be able to send email to all adresses even the yours in @YOURDOMAIN.TLD.

The problem

Yunohost configure postfix, your server mail, to work as a mailbox manager. But in your case you just want send mail but not receive them.

So when you try to send a mail from your yunohost server to your mail address with the same domain name, your yunohost try to send the mail to itself and say something as

Recipient address rejected: User unknown in virtual mailbox table;

The solution

So we need to configure the system to avoid to manage mailbox. Here are the step I have done:

Stop managing mailbox for this domain

Replace

query_filter = (&(objectClass=mailDomain)(virtualdomain=%s))

by

query_filter = (&(objectClass=mailDomain)(!(virtualdomain=YOURDOMAIN.TLD))(virtualdomain=%s))

in /etc/postfix/ldap-domains.cf

And restart postfix

service postfix restart

Change dnsmasq specific rules

dnsmasq is used in YunoHost to change some DNS answer to allow some apps to setup correctly even if the yunohost admin hasn’t configure properly the DNS on the registrar interface.

In our case, it’s quite embarassing, cause of the MX is forced to be the yunohost server !

To change that, edit /etc/dnsmasq.d/YOURDOMAIN.conf and fill with the correct MX server:

address=/YOURDOMAIN.TLD/AA.BB.CC.DD
mx-host=YOURDOMAIN.TLD,THECORRECTMX.TLD,5
srv-host=_xmpp-client._tcp.YOURDOMAIN.TLD,YOURDOMAIN.TLD,5222,0,5
srv-host=_xmpp-server._tcp.YOURDOMAIN.TLD,YOURDOMAIN.TLD,5269,0,5

To get the correct MX server, use dig :

dig MX YOURDOMAIN.TLD @9.9.9.9
2

Thanks, that’s very useful.

I think there should be an option in Yonohost to have email managed by an external provider on the main domain. I’m happy to host my own apps (Nextcloud, Rainloop, Dokuwiki…), but hosting my own email feels like too much responsibility for me.

3

This can be achieved by any web application that support IMAP. I think there is one plugin IMAP to connect to any other email provider. You all together don’t need any settings for this.

4

Well, I’m not talking about client configuration but server configuration. Let’s pretend my email is hosted by OVH on mydomain.com. I’m happy to have yunohost manage apps hosted at mydomain.com, but want to leave email management to OVH.

I might end up using this solution, with my apps hosted on a subdomain.

5

Its possible
Leave the DNS as is (the MX) for the emails to be managed by OVH. Redirect domain.com to your server IP with a A field.
Add domain.com to yunohost. Create your users and give them email@domain.com corresponding to the OVH emails.
Install rainloop. In the admin interface, change the IMAP/SMTP of domain.com to correspond to the OVH settings.
Done

6

@scith, I’m sorry your solution does not fit my need.
I need my yunohost server to be able to send email to my OVH email (basically all mail addressed to root, admin, and my user). Adding my OVH domain to Yunohost automatically creates a MX record for that domain, and thus creates a dead loop.

@ljf’s solution against that dead loop works fine.

7

does the proposed solution still works with yunohost 3.7.1.1 settings ?
I’m ending up with ‘loops back to myself’ when proceeding as described.

9

Hello,
I have Yunohost 4.3.6.2. installed on a small Kimsufi server.
I have turn off services Dovecot, Metronome, Postfix, rspamd because I don’t want my Yunohost server to manage Email and XMPP.
Email is managed by my registar / DNS provider. And I do as @scith said with an A field targetted to Yunohost server in my Zone DNS.

But so I can’t receive any Yunohost system Email alert.
I am in the same situation as @djib where I would like to receive the email sent to root, admin and my users, even if these Email address are not managed by Yunohost.

Do you know if this is possible ? What I should do to achieve this?
(sorry to revive this old unsolved topic…)

10

I want tot do the same : I want my yunohost server to be able to send email (to an external server) bot not receive them.

Instead of modifying the config files, what if I disable postfix?

   service postfix stop
   service postfix disable

and dovecot ?

I have already commented the “mx-host” line in /etc/dnsmasq.d/DOMAINS.conf instead of changing them and I get the correct MX servers with dig :slight_smile:

11

Disabling postfix/dovecot would also break all email notifications etc. sent from and within Yunohost. (Not good.)

I think it’s now really only a tiny change in the current implementation to actually allow emails to go to external MX servers as configured in the public DNS (simply remove or comment-out the MX and SPF overrides yunohost generates in /etc/dnsmasq.d/* files).

That small change could also help a lot to get a clearer view on cases with other bugs lurking (Issues to fix email breakages caused by upgrades (regression) - #2 by tmb).

12

I just checked:
In case one really wants a permanent local-only email override (independent from the public DNS settings), it’s now possible to configure a local MX together with properly adjusted SPF, DKIM, DMARC, etc. in /etc/dnsmasq.d/ and the modified files won’t get overwritten.

But I don’t understand why the local override was chosen as default. It’s hardly possible to generate correctly in accordance to external DNS settigs, and a authoritatve DNS can’t always be assumed. Is there some benefit I don’t see?

The local override would always seem to need some expert configuration to make it work with the external DNS config. While the yunohost diagnosis makes suggestons for the global DNS config (and local overrides might even disturb the diagnosis).

13

Hello,

I have a dilemma…

Since it’s an old topic, I need know if it is still a possible add a domain with an external mail server provider… The file `/etc/postfix/ldap-domains.cf` does no more exist. In place there is 3 files

grep -ir query /etc/postfix/*
/etc/postfix/ldap-accounts.cf:query_filter = (&(objectClass=mailAccount)(mail=%s)(permission=cn=mail.main,ou=permission,dc=yunohost,dc=org))
/etc/postfix/ldap-aliases.cf:query_filter = (&(objectClass=mailAccount)(mail=%s)(permission=cn=mail.main,ou=permission,dc=yunohost,dc=org))
/etc/postfix/ldap-groups.cf:query_filter = (&(objectClass=groupOfNamesYnh)(mail=%s))

In fact I have a some questions.

If I add a domain ( a Top domain, not a Main domain ) on the server, but I don’t want him to use postfix and dovecot, can I just the domain config disable sent mails and receive mails ?

Is it a problem ? Could I then send a mail to a mail adress from this server and it will see in the zone dns it use another MX ( the domain provider mx ) ?

This top domain will point to a site with an SMTP extension to send mails where you can choose the SMTP provider. I imagine it will still works.

And then what happens if I add yunohost users to this domain ? They just should not be available to send and/or receive mails ??

Or can I still edit the `/etc/dnsmasq.d/DOMAIN.TLD` with

address=/YOURDOMAIN.TLD/AA.BB.CC.DD
mx-host=YOURDOMAIN.TLD,THECORRECTMX.TLD,5
srv-host=_xmpp-client._tcp.YOURDOMAIN.TLD,YOURDOMAIN.TLD,5222,0,5
srv-host=_xmpp-server._tcp.YOURDOMAIN.TLD,YOURDOMAIN.TLD,5269,0,5

as suggested by @ljf ? The files here are also changed I could see something like (for a sub.domain), but I imagine I need just change mx-host=

interface-name=foo.domain.tld,lo

interface-name=foo.domain.tld,eth0

interface-name=foo.domain.tld,eth1


txt-record=foo.domain.tld,"v=spf1 mx a -all"

mx-host=foo.domain.tld,foo.domain.tld.org,5
14

I think you don’t need to edit the /etc/postfix/ldap-domains.cf anymore. That setting, it seems, is now changed through disabling the mail_in setting of the domain, which now changes the managed file /etc/postfix/virtual-mailbox-domains.

However, there seem to be remaining issues, e.g. the local MX override is bound to mail_in enabled/disabled instead of DNS diagnosis results, and thus even removed if the public SPF etc. for sending is not set up properly yet (risk to get own IP blacklisted e.g. by status/notification emails), and further bugs/issues can also still be experienced in email transport/delivery/reception after disabling mail_in/out settings, see: Issues to fix email breakages caused by upgrades (regression) - #3 by tmb