Is your feature request related to a problem? Please describe.
The configuration templates include this for /etc/postfix/main.cf:
myhostname = mail.$mydomain
and also
mydomain = <SERVERNAME>
I guess this is to guarantee that $myhostname is an FQDN. Like if SERVERNAME would be "example.com", myhostname becomes "mail.example.com".
And yes, I read the froxlor comment above the myhostname line.
So let's say, SERVERNAME is already "myserver.example.com", then myhostname would become "mail.myserver.example.com"
I feel like I should change this and just cut the "mail." if my hostname is already a FQDN.
Because I would specify a reverse DNS so that 12.34.56.78 also resolves to myserver.example.com
Are my assumptions are correct so far? (This would be the "question" part of this post)
Describe the solution you'd like
If my assumptions are correct, I'd like to propose a little change that makes the templates smarter (which would be the FR part). Like do some logic, for example "if SERVERNAME is an FQDN, don't add 'mail.'". Or have a setting to control this and let the user decide.
I mean it's not like there were not already settings from the likes of "don't change unless you know what it means" :)
Describe alternatives you've considered
Changing it manually, however, this is once again a point that you might forget, or you're not even aware that it's something you should look at because the magic is done automatically.
Also changing it manually poses the risk of future updates when it's necessary to change configs again (OS update or feature update of froxlor itself) which you'd have it done automatically because why not and then your manual changes are gone.
Additional context
I did notice that (well rather, I was reminded on that) because the cron was unhappy about something (me being a dingus, what else is new) however it put it into the spam. Because the sender was root@mail.myserver.example.com for which I did not specify any whitelist at all and I guess it even fails the reverse DNS test - so I'd assume it'll look rather fishy to the receiving mail server.
Is your feature request related to a problem? Please describe. The configuration templates include this for /etc/postfix/main.cf:
myhostname = mail.$mydomain
and alsomydomain = <SERVERNAME>
I guess this is to guarantee that $myhostname is an FQDN. Like if SERVERNAME would be "example.com", myhostname becomes "mail.example.com".
And yes, I read the froxlor comment above the myhostname line.
So let's say, SERVERNAME is already "myserver.example.com", then myhostname would become "mail.myserver.example.com"
I feel like I should change this and just cut the "mail." if my hostname is already a FQDN.
Because I would specify a reverse DNS so that 12.34.56.78 also resolves to myserver.example.com
Are my assumptions are correct so far? (This would be the "question" part of this post)
Describe the solution you'd like If my assumptions are correct, I'd like to propose a little change that makes the templates smarter (which would be the FR part). Like do some logic, for example "if SERVERNAME is an FQDN, don't add 'mail.'". Or have a setting to control this and let the user decide. I mean it's not like there were not already settings from the likes of "don't change unless you know what it means" :)
Describe alternatives you've considered Changing it manually, however, this is once again a point that you might forget, or you're not even aware that it's something you should look at because the magic is done automatically. Also changing it manually poses the risk of future updates when it's necessary to change configs again (OS update or feature update of froxlor itself) which you'd have it done automatically because why not and then your manual changes are gone.
Additional context I did notice that (well rather, I was reminded on that) because the cron was unhappy about something (me being a dingus, what else is new) however it put it into the spam. Because the sender was root@mail.myserver.example.com for which I did not specify any whitelist at all and I guess it even fails the reverse DNS test - so I'd assume it'll look rather fishy to the receiving mail server.