Allow updating mailcow without a FQDN in mailcow.conf

[ghost]

This pull request aims to fix #1572.

[fenio]

Please apply this change. Checking FQDN by number of dots is... weird.
My address fully identifies host despite not having nonsense "hostname" part.

[andryyy]

It has nothing to do with the amount of dots. Why do you say it like this?

Let us just call everything a FQDN today. No dot? No problem. 200 dots? It is obviously a TLD. Or mail addresses. How stupid of us to count the @s.

I don't want to support non fqdns as there were problems previously. I think I wrote this like 200 times already. I have not checked if I fixed it a while ago (I actually think I did). I don't want to break anything. I prefer to count dots. Why is this so hard to understand? :( Why should I change it untested?

Yes, some domains like example.co.uk fall thru.

Again!! There were problems with mailcow and domains as hostname. Tell those bugs the dots don't matter.

[andryyy]

example.com is just not a FQDN. Even if it was, why should the bugs (I PROBABLY fixed) care about that at all?

Do you think they vanish when you tell them they are non RFC conform?

Just stick to the requirements. :)

[ghost]

@andryyy This pull request doesn't remove the check for the number of dots, it just prints an explicit warning that using mailcow without a FQDN is not supported and allows users to proceed without one at their own peril.

[fenio]

Seriously it has nothing to do with number of dots?

if [ ${#DOTS} -lt 2 ]; then

I don't agree.

Seriously you don't want to break anything? Why should you change it untested?
You actually submitted that change which broke working setups including mine but I'm not the only one. I guess you submitted it without tests.
The whole thread is like 2 years old but you had to approve those changes recently.

Anyway. That conversation doesn't make sense to me if you simply ignore RFC and you'are proud of it. If you prefer to say that mailcow is not going to be RFC compliant then say so and stop saying that current behaviour of upgrade script is RFC compliant cause it isn't.

It's your right to do so. Just stop lying that you're still RFC compliant. You have stopped being that once you started counting number of dots to figure out whether host is FQDN or not.

[fenio]

And yeah... I can imagine that it fixes a lot of issues for you. The problem is that it causes problems for me. And I'm trying to be RFC compliant. You have fixed issue for people that probably even have no idea what RFC stands for.

[andryyy]

I don't understand. You are trying to be RFC compliant by using domain.tld as FQDN? I seriously don't understand it, I don't want to be offending. :)

I am not - absolutely not - forcing anyone to do something non-RFC compliant by saying "please use an FQDN for your mail server, as long as there might be bugs".

The "2 dot" check is not a good check for an FQDN, I understand it. But it does at least help a bit.
Fixes and changes to this check are very welcome!

Adding the option to ignore it is a hell to support. I cannot do this until I am sure the bugs are fixed. The biggest problem was "MAILCOW_HOSTNAME" == a_domain_on_mailcow (see https://github.com/mailcow/mailcow-dockerized/blob/master/data/web/inc/functions.mailbox.inc.php#L404).

I don't see what you gain by adding an option to enable it anyway, perhaps introduce some nasty bugs only to say "hey, at least I name my server example.org now, yay". :/

[fenio]

Yes I'm trying to be RFC compliant by using domain.tld as FQDN cause using domain.tld as FQDN is simply RFC compliant.

from fqdn import FQDN
domain = 'example.org'
fqdn = FQDN(domain)
fqdn.is_valid
True

I also don't want to be offending but the fact is that that change broke correct and working setups.

[lenovouser]

I've also been using a domain as the FQDN before this change and have continued to do so, so I'd also like to see this removed or at least an option to bypass it if you know what you're doing

[fenio]

I'd like to hear what's the future of this bug/problem.
If you don't want to fix it then please mark this bug as 'wontfix' and at least give us clear sign that FQDNs are not longer supported. I'll start looking for some other solution for my email setup or I simply try to fork your fabulous work and keep modified version in sync with your version.
Right now I'm not sure what exactly am I waiting for here.

[mkuron]

You don‘t have to use update.sh and generate_config.sh. You can manually take care of mailcow.conf and git, many people do that. This won‘t prevent you from using example.com, but you‘re on your own if you encounter Mailcow bugs related to that.

but more importantly: is there any reason why you can‘t just change your server name from example.com to something.example.com? This should only be a matter of changing a few DNS records.

[fenio]

Of course I don't have to use update.sh... nor other scripts. In fact I can simply configure all that stuff myself but I'm using your work to make my life easier :)

And speaking why can't I change the name of my server. Of course I could do it but I see no reason to do so. I'm using FQDN as my server name.

Ok maybe the other way. I WON'T change name of my server cause I think that it won't solve anything. It will just allow you to forget about some problematic setups but at the end we will end up with not RFC compliant set up which will lead to much more problematic problems.

By agreeing that we can skip that part of RFC compliance I would have to agree that we can skip whatever part of whatever RFC. So either you're doing very good mail solution or mail solution that is not RFC compliant and then simply state that in docs.

[andryyy]

I mean ... I have told you this can lead to errors. If you still cannot see it, I am sorry. You can provide some tests, to check wether these errors still exist. Do you want to provide a PR? => https://github.com/mailcow/mailcow-integration-tests

[mkuron]

This is not an issue of RFC compliance. The SMTP RFC allows you to have the same mail server host name and domain name, but it does not require you to. Mailcow strongly discourages this kind of setup because it has caused problems in the past:

Adding the option to ignore it is a hell to support. I cannot do this until I am sure the bugs are fixed. The biggest problem was "MAILCOW_HOSTNAME" == a_domain_on_mailcow (see https://github.com/mailcow/mailcow-dockerized/blob/master/data/web/inc/functions.mailbox.inc.php#L404).

Basically, if you want to use Mailcow, you will need to accept certain simplifications it makes. It does not expose all configuration options through the GUI and is even incompatible with some. This is one of them: assuming that server host name and mail domain names are different makes our lives easier and only requires a very small fraction of our users to make changes to their DNS records.

If you want that requirement to be removed, someone needs to add comprehensive test coverage to https://github.com/mailcow/mailcow-integration-tests/tree/master/roles/mailcow-tests and fix any bugs that are discovered by these tests.