DirectAdmin 1.53.0 Release Candidate

[DirectAdmin Support]

Update:

1. ​I've removed the SPF -all default, and reverted back to ~all. Good discussions, but as it could cause conflicts, we'll omit it for now.
2. @staff_nowa: I tested on Debian 9, but couldn't find any issues. Please create a ticket if you're still having issues.

Likely pushing the release 1.53.0 as stable tomorrow afternoon, as no major issues have been found.

John

 

[staff_nowa]

Hello, John,

this functionality still does not work.
1. Updated binaries
2. Added options direct_crons=1
3. Added cron into DA
4. Added cron with SSH
5. Added new cron into DA. 4 information does not exists.
6. Removed all existing crons.
7. Step 4 crons gone too.

 

[staff_nowa]

Hello, John,

this functionality still does not work.
1. Updated binaries
2. Added options direct_crons=1
3. Added cron into DA
4. Added cron with SSH
5. Added new cron into DA. 4 information does not exists.
6. Removed all existing crons.
7. Step 4 crons gone too.

I check this issue again.
1. killall directadmin
2. systemctl restart directadmin and it works now.

Another issue

An Error has Occurred

Details

Error Parsing Cron File

If we have something like this

* * * * * /home/cloud/
* * * * * /usr/bin/php -f /home/cloud/domains/cloud.prado.lt/public_html/cron.php >/dev/null 2>&1
* * * * * /usr/bin/php -f /home/cloud/domains/cloud.prado.lt/public_html/cron.php >/dev/null 2>&1

* * * * * /home/cloud/

Maybe we should allow parse those lines if we have enter. Almost people added new empty line if we have 100 lines in terminal + the same lines we should remove from crontab information

 

[Richard G]

Hello John.

Thanks for reverting the SPF change.
Hope it can be put as some directadmin.conf option so admins who like it can use it, or that it can be disabled without the need of template changes for those who don't want to use it.

 

[AppJetty]

Very nice dear ! its with so many new directadmin.conf options (also in previous versions) is it possible to update this page with every directadmin.conf option?

 

[ayeweb]

Today i had try it, all are ok for me.
Hope no error....

 

[zmippie]

In our country lots of customers still use their own ISP's smtp server for mail sent from their domain because ISP's limit outgoing mail to their own smtp server

Well I'm in "our country" as well, and to me what you're describing here is a sign of bad hosting (of which there is a lot, not only here, but worldwide I guess).

It's actually one of the reasons I've learned to manage my own servers, because e-mail communication over TLS should be mandatory, always. And now with LetsEncrypt there's no extra cost so there's no reason to be sloppy.

As an anti-spam measure many ISP's in our country block (or used to block) only port 25, and you're not going to use that with TLS, so there's no reason to use your ISP's outgoing mail server. And in light of the GDPR, I think an ISP has no place in a user's e-mail communication either.

So I'm all for "-all" as the default for SPF. It will definitely hurt some users, and they'll need to be educated ("hey, we're going to make your e-mail more secure, but..."), but at one point we have to move forward, right? SPF with softfail is inneffective, meant as a transitional option, and basically useless for the intended goal of SPF AFAIK. So I'm sorry that it's been turned back already, but I'm aware I can change it on my own servers, and I will.

 

[Richard G]

what you're describing here is a sign of bad hosting

That's a complete pack of nonsense your saying.
Next to that you did not read very well. It's the ISP's blocking or limit outgoing e-mail to their own smtp server. There is nothing we as hosters can do about that policy of them.
So that's not a sign of bad hosting.

We as hosting company's (at least a lot of us, including our company) are not doing bad hosting. We do have the possibility of using port 465 and 587, the use of TLS or SSL is possible. But that still doesn't make a customer wanting to use it. And that was what I was talking about. That's also not a sign of bad hosting.
We as hosters inform our users about this possibility, even have a howto online. But if they don't (want to) change their configuration, it's not up to us to force them to do it. As you say, we don't have a place in their email communication either. We can advise and that's it! Which is a sign of -good- hosting.

Only fairly recently (maybe 2 years), ISP's are understanding the issue and also now are advising and using other ports then 25. Before they did not even communicate about other ports, they did not want their customers to use other ports then their own smtp server on port 25 (because of anti spam). Likewise they did not want customers to run their own mailservers at home.
It's also the reason why for example Ziggo took so very long to give the customers the possibility of imap mail.

I don't agree TLS should be mandatory yet. LetsEncrypt is also really new, like we say in our country "staat nog in de kinderschoenen" and only now hosters and other forums start to trust it enough to implement it not only for web but also for e-mail traffic.
You can't expect everybody and every hosting company to implement something new as soon as possible. I do agree that it should not take too long anymore, but this will only work worldwide. Not if only DA customers are doing it. This should be spoken about making TLS mandatory in RFC's and ways to implement it within let's say 3 or 5 years mandatory.
As you see, this has totally nothing to do with bad hosting, which I find insulting, it only has to do with forcing up users. We already educated and advised them which is imho a better way.

So I very disaggree about your last statement about the "-all".

It will definitely hurt some users, and they'll need to be educated

Nope that won't work, because you totally forget the 2 most important things.
1.) This will only do any good if every MTA in the world would use and check for SPF records. Lots of big ISP's not using or even checking for SPF records, make that mandatory first.
2.) You can educate what you want. 90% of the home users don't even notice when their ip change at home after the ISP had some work, got a new router or whatever. Next to that, they wouldn't even know how to find their ip. And if they can find it, they don't know how to change the DNS records or will make failures with them.

Are you going to teach that all to them? Are you going to change the DNS records for them the correct way every change? I wouldn't believe you if you would say "yes".

So yes, I'm all for safe email and have howto's on how to use TLS on mail and stuff and maybe point to SPF howto's, but I'm glad it's back to ~all because of the reasons mentioned and complaints every time that mail is blocked/refused by a change ip, invalid SPF entry in DNS and so on.
And that has again, nothing to do with bad hosting.

 

[zmippie]

That's a complete pack of nonsense your saying.

Well, I didn't expect you to agree, so I'm not entirely surprised by your answer. I can imagine that you're working for the type of hosting company where I, and a lot of peope I know was/were a customer for many, many years. I understand your problems, but sometimes you just have to educate your users going forward. I can be painful yes, that's why you sugarcoat it as much as possible. It's how Apple forces many of its innovations onto the industry. Painful for its users at times, but in the end everyone wins (well, most of the time...).

Next to that you did not read very well. It's the ISP's blocking or limit outgoing e-mail to their own smtp server.

Why would an ISP block access to their own (the ISP's) SMTP server? How can their users send mail then? The issue is (was in some cases) ISP's blocking only port 25 in order to stop people to send/relay email without any sort of authentication (likely spam, from their own mailserver indeed). You were always able to connect securely to an SMTP server over 465 or 587. I have never heard of anyone who could not connect to their GMail account through an email client because their ISP blocked them.

We as hosting company's (at least a lot of us, including our company) are not doing bad hosting.

Is all email communication mandatory over TLS? Do you require SFTP? Is DirectAdmin behind a TLS connection? Then I totally agree with you, that's indeed not bad hosting in my book.

We do have the possibility of using port 465 and 587, the use of TLS or SSL is possible. But that still doesn't make a customer wanting to use it.

Yes, that's exactly where things go wrong: you let the customer decide about the security on your platform. Anyone serious about their business would not do that. Do you think Google, Microsoft or Apple let users connect to their email services through plaintext-authentication? No, of course not. So tell me, why would you?

Not if only DA customers are doing it.

You don't always have to wait until a feature is implemented by your platform provider. Many of us had LetsEncrypt up and running before it was added to DA natively. A good example of a hosting company that doesn't just sit and wait for the right moment to make a change is DreamHost. They implement new technologies fast, and at large scale too. It can be done, with the right mindset. And LetsEncrypt isn't the only way to enforce TLS, it's only the cheapest way.

it only has to do with forcing up users.

Again, like Google, Microsoft and Apple "forcing" their users to use secure protocols?

Nope that won't work, because you totally forget the 2 most important things.
1.) This will only do any good if every MTA in the world would use and check for SPF records. Lots of big ISP's not using or even checking for SPF records, make that mandatory first.

Wow, so just because not everyone's on board yet, the rest of us can't move forward? That's not how innovation works, I'm sorry. If email doesn't get delivered because of failing SPF checks, then people will complain, and then... things will change. Just make sure it's not you that's to blame for the failure. Make sure that you have your systems configured correctly so you can divert the complaints to the other party.

2.) You can educate what you want. 90% of the home users don't even notice when their ip change at home after the ISP had some work

I'm sorry, but I fail to see what router IP addresses have to do with the SPF issue we're discussing here.

 

[Richard G]

but sometimes you just have to educate your users going forward.

I again suggest you do some better reading of what I write to you. I -do- educate my customers as I explained.

Why would an ISP block access to their own (the ISP's) SMTP server?

That is not what I said. I said -limit- it to their own SMTP server. Limit to means that their customers can use their own ISP's smtp server but no other (on port 25).

Is all email communication mandatory over TLS? Do you require SFTP? Is DirectAdmin behind a TLS connection? Then I totally agree with you, that's indeed not bad hosting in my book.

I'm glad we agree. But as said, Letsencrypt is too young and even renewing still goes wrong too much. So yes this has to be done, but not right now, but when it's stable and that is indeed not bad hosting if you provide customers only things that are well working and stable.
DA behind a TLS connection? You mean behind a SSL connection. We do provide TLS for mail and SFTP for FTP, but we do not force it to our users yet.

So tell me, why would you?

Do you block mail of other hosters without any good reason, without providing them am a good way to get delisted while they are complying to all RFC's and your rules and are not on any spamlist?
Microsoft is doing that, so why don't you?
If you make unstable things mandatory for your users, why would I?
The "They do it so you should" is a nonsense argument.
In my opinion I do it better then you if we're talking LetEncrypt imho. At this moment I provide it as a choice. Later on when it's stable, then it will become mandatory.

You don't always have to wait until a feature is implemented by your platform provider.

I know and it's nice if others implement things earlier, mostly with several problems which appear which DA support might not be able to fix for you. For bigger companies this is a lot easier then for smaller hosting company's.
Wildcard SSL certificates are often too expensive for smaller companies. So yes, now with LetsEncrypt which is a lot cheaper, -and- the support from DA which incsludes SNI and mail-SNI makes it way more possible to go forward.
So no you don't have to wait, but it won't help a lot either if most of the others still won't follow the flow of improvement, which is mostly done if also MTA's and platforms provide support for it.

Again, like Google, Microsoft and Apple "forcing" their users to use secure protocols?

Again "they do it so why shouldn't you" is a nonsense argument. Those are big company's with loads of money, so they can easily buy official certificates, and buy a lot of knowledge to implement it and solve eventual problems when occuring. That's why those company's can implement so early.

Wow, so just because not everyone's on board yet, the rest of us can't move forward.

LoL. Read my comments about agreeing to part of this. Implementing SPF and DKIM records automatically is moving forward. Changing ~all to -all is not.
You know as well as I do that SPF:
a.) Just isn't working that great because there are way lot of MTA's which do not even check for SPF records, including what I already stated a lot of big ISP's. I didn't here you about that. SPF works or dies with the amount of systems using it, you know that as well as I.
b.) When looking around, the times that spammers are faking hostnames which SPF would block, are not a lot anymore, they have lots of other ways to abuse the systems.
Which doesn't mean we can't improve things, but changing that is not that big at this moment.

I'm sorry, but I fail to see what router IP addresses have to do with the SPF issue we're discussing here.

I'm sorry, I was under the impression that you knew how SPF worked. Or you did not read my comment good enough. I suggest you do that. I did not spoke about router ip's.
And I didn't get an answer to my question if you are going to teach your customers how SPF works and how they change DNS records and when their ip change how they can look it up etc.
Unless you're going to use their ISP's domain for mail, which immediatly makes it possible for all other customers of that ISP to send mail in behalve. And then we did not talk about the business customers and some ISP's which do have real static ip's. So which need change. That was what I was talking about. Not routers.

 

[zmippie]

I'm sorry, I was under the impression that you knew how SPF worked. Or you did not read my comment good enough. I suggest you do that. I did not spoke about router ip's.

I read it again, but I'm sorry Richard, if you think that a hosting company and an ISP are the same thing, then I think this discussion isn't going anywhere, ever. We're perhaps talking about completely different concepts here. Let me quote your 2nd point once more (emphasis mine):

90% of the home users don't even notice when their ip change at home after the ISP had some work, got a new router or whatever. Next to that, they wouldn't even know how to find their ip. And if they can find it, they don't know how to change the DNS records or will make failures with them.

I'm puzzled, still am. Who got the new router? Home user or ISP? How is this applicable to SPF?

And I didn't get an answer to my question if you are going to teach your customers how SPF works and how they change DNS records and when their ip change how they can look it up etc.

What is "a customer"? The end user (home user?) that needs to get their email set up and get going, or a person/organization that manages a hosting account? Again, totally different concepts. True, I know companies that (re)sell hosting services that don't even know how to set up SPF and DKIM correctly, so there's a blurry line here. But what I call a "customer" is probably something different than you do. If a "customer" doesn't know how to manage a hosting account through a simplified GUI like DirectAdmin, then they shouldn't touch it. This applies to what I call "end users", but any other person that doesn't know what they're doing. You can't drive a car just because you can buy or rent one. You need some minimal skills. Is this what we're talking about?

Unless you're going to use their ISP's domain for mail, which immediatly makes it possible for all other customers of that ISP to send mail in behalve.

I'm taking you seriously, I do, but I honestly don't have a clue what you're talking about here. These days, ISP's (like Ziggo in NL) will require you to authenticate (password) over TLS to talk to their SMTP server and get email out the door. The same goes for any "end user" on my servers, GMail's servers, Apple's servers etc, because authentication over TLS for outgoing mail is mandatory. So what is the difference? Why is the "use the Ziggo SMTP" the easier option for end users? I don't see it.

 

[Richard G]

Ofcourse I'm well aware of the difference between hosting company and ISP. But home users will send mail via our servers and hosting company's to ISP's, from which a lot don't even use SPF.
There are also a lot of end users, which send mails from their domain via their ISP's SMTP instead of via our servers. And that's the SPF change I mean, I try to explain below again.

I'm puzzled, still am. Who got the new router? Home user or ISP? How is this applicable to SPF?

In SPF when using -all you have to include all systems sending mail. A home user will get an internet IP which changes because in most cases they are dynamic.
If you don't include this internet ip in SPF, they won't be able to send mail via your server because the MTA will block it for not being present in the SPF line. Result, user complaints not being able to send mail.
So you change it. Now the ISP at some time changes the modem, does work on the network, sets the modem from router mode to bridge mode, the customer changes isp or any other thing that will change your customers IP address, you again will have to change that SPF line to include the correct ip.
This will be less work if your customer can do this change himself, or.... how else would you like to prevent this block from your own server?
I hope it's now more clear to you what I mean with thi, I don't know another way to explain this.

To be more clear:
Customer: The home user, either your customer or the customer of the ISP.

These days, ISP's (like Ziggo in NL) will require you to

Indeed. These days.... that is exactly what I stated before. This is fairly recent, just a couple of years. As far as I know, not all ISP's are doing this. Hoever, this is when sending mail via the ISP, and has nothing to do with sending mail via our servers which we are talking about. But before... they didn't like their customers (end users) to send mail via another port, because limiting mail to their own smtp, prevented the ISP smtp servers from getting on spamlists.

The "use the Ziggo SMTP" is easier for end users, because then it's possible to set the Ziggo smtp servers as allowed for sending for that domain in SPF. Their SMTP servers won't change that often.
The backside of this is that all Ziggo customers can send mail in behalve of the customers domain, because they all can make use of the Ziggo smtp server. However, the abuser can be more easily tracked.
As for SPF, I hope you understand my explanation above. I also got German customers (yes end users) which get their ip changed almost every week. So using letting them use the t-online smtp server for their domain is easier for them to configure and saves a lot of work changing the SPF record every time.

Don't understand me wrongly. I do agree that things like implementing TLS and SSL is improvement otherwise I wouldn't have done this too and wrote instructions for my customers.
The only difference in opinion is that you want to implement it directly and I want to wait a little bit until it's more stable. And that is a difference of opinion, not a sign of bad hosting, that's all I'm saying.

Just one question which jumped to my mind a couple of minutes ago.
You find not using -all instead of ~all a question of bad hosting to your opinion. But where you not doing bad hosting yourself in that case? Because changing that to -all is already possible for years?
So why in thase case have you waited until the future if you don't want to wait to implement things which are great improvement in your opinion? That's something which puzzles me.

 

[zmippie]

In SPF when using -all you have to include all systems sending mail. A home user will get an internet IP which changes because in most cases they are dynamic.

Now I get what you're saying. But I couldn't see a use case that applied to what we're talking about here. Until:

The "use the Ziggo SMTP" is easier for end users, because then it's possible to set the Ziggo smtp servers as allowed for sending for that domain in SPF. Their SMTP servers won't change that often.

Whoah! I would never do that. This is exactly why I'd just say: "guys, it's been fun, but from now on you can only use our email service using proper authentication through our servers". I understand that it will probably not make your customers happy for a short while, but it's a one-time hit, and you can announce it months ahead. And you have to provide the certificates of course, but I've seen some hosting companies in NL do creative stuff with that (enforcing email communication over a centralized domain).

But I see your problem, and I agree that it's a mess that we've initially gotten forced into by our local ISP's. But I also see a number of hosting companies that just require good, modern policies.

But where you not doing bad hosting yourself in that case?

Definitely so. But as was made clear in our conversation, things change all the time. What was "good hosting" ten years ago, may be considered "bad hosting" today, because there are technologies available now that weren't ten years ago. SPF will not get real traction when we keep "softfailing" for years and years.

Sometimes things have to change to make it better. And for that, sometimes users may have to make an effort. That's how I see it.

 

[Richard G]

Whoah! I would never do that.

Not? Oke that is a choice. We think the customer is King and if he does not want's to send his domain mail via our servers, in spite of our advise to do that, it's the customers choice. And I don't see any downside of it. Because their providers SMTP mostly also use TLS as you stated.

And it's not a one time hit, because the -all in SPF this does not solve the issue about having to change SPF records every time the end user's ip changed like I described.

But I couldn't see a use case that applied to what we're talking about here.

I have the impression you still don't see what I mean or something is not working correct on my side. Let's use an example.

Suppose I'm your end customer, having hosted space on your server with the mydomain.com domain name.
You force me to use your server for mail. I'm a noob like most of the home users. I've got ip 84.76.12.34 for example. If you use -all in SPF, you have to implement that into my SPF record of mydomain.com which you are hosting for me. So a very simiple one: "v=spf1 mx a ip4:84.76.12.34 -all"
Now I decide to have my provider set my modem to bridge mode, for whatever reason. My ip changes from 84.76.12.34 to 86.76.12.88. I send mail... mail won't be send.
I'm going to call you, because you obliged me to use your server and now it's not working. Why not? Because 86.76.12.88 was not included as allowed system to send mail from mydomain.com, so your MTA refuses my mail.

What's next now. Do you change my SPF, or do you try to instruct me how I have to find my new ip address and how I even chan see when it changed? Or do you explain me how to change it? I don't know all this technical stuff and I'm not interested in it, so you change it for me.
Next week my ISP has to do some work on the network. Oeps... almost all users ip's change. Now I've got 84.76.23.12 and have to call you again.
I'm getting annoyed calling you every time because I can't send mail, I'm a customer so I'm not interested in learning to lookup my ip in www.watismijnip.nl and then have to learn how to change my SPF record, I don't need that with Gmail and Yahoo and Hotmail.Outlook (your examples) either.
Worse... I'm a German customer with a t-online.de ip which change ever week or every couple of days... now what?

Shortly said, how do you prevent that your server blocks me from sending my mail via my domain on your server, when my ip address isn't allowed to send mail by SPF, because my new ip is not in the SPF record and so gets refused by the server?

SPF will not get real traction when we keep "softfailing" for years and years

Which still puzzles me why you did not change this already for example 5 years ago, seen your opinion about this?
And still I don't agree. There are better ways (like forcing authenticated mail for scripts/php, using TLS and DKIM in combination with SPF for mail etc.) to make things better. Imho we can better start forcing these things then a hardfail in SPF which is not much use anymore these days since that kind of spamming is not used very much anymore.
I do agree about educating users about SPF and trying to get them to configure -all lines, if needed with our help. But we will never force this.
Edit: We are going to force TLS in mail, only not right now. Probably end of this year when it's more stable. Improvements are good, but they don't have to be forced in right away imho.

 

[Richard G]

Seems -all also is giving issues when using an external anti-spam system like spamexperts and you almost can't use it then either or need to whitelist too many systems.
Read this. It's in Dutch though.

 

[zmippie]

Not? Oke that is a choice. <snip> And I don't see any downside of it.

No downside? As you said: everyone on that "semi-public" ISP's SMTP server can now spoof email with your users domains. Exactly the thing that SPF is supposed to prevent! How is this even something you thought of?

I've got ip 84.76.12.34 for example. If you use -all in SPF, you have to implement that into my SPF record of mydomain.com which you are hosting for me. So a very simiple one: "v=spf1 mx a ip4:84.76.12.34 -all"

From the rest of your description I'm understanding that 84.76.12.34 is the user's home IP address. So you're adding a user's home IP address to an SPF record? That would be totally insane. You do realize that the SPF check is done at the receiving end, right? Is this user running a mailserver on 84.76.12.34, on his home computer? If not, which mailserver is he using, and why are you adding his home IP address to the SPF record?

This makes no sense.

 

[Richard G]

No downside? As you said: everyone on that "semi-public" ISP's SMTP server can now spoof email with your users domains.

I suggest you read back, this is a complete different example context. There is no downside. What you mention here is only when you would use -all and would then have to include the ISP's smtp. Which is indeed not a good thing which I declared myself indeed, but also in that specific context. But even the ISP's smtp is better then a ~all in that case, correct?

When using the softfail there is no downside to it if the user decides to use the smtp server of the ISP instead of the hosting company.
The only "downside" is that you can't use the -all, but then again, as you could read from my last post, that can neither be used when using for example spamexperts.

So you're adding a user's home IP address to an SPF record? That would be totally insane.

Would it? I just put the reason for it in my example above even twice!

If this does not make sense, how does your Exim "see" that my home ip is allowed to send mail for my domain if it's not included in the SPF record?
I can also go to a friend or family and login there and send mail from my domain, which would provide a different home ip (for example Telfort) and shoud be blocked for not being allowed to send mail from my domain.

You could be right, but this is what happened to me a couple of years ago when I started using -all for my own domains (yes I have that for several years already for my own domains). When not including my own IP address in the SPF record, as stated above twice, my mail would get refused by my mailserver.
So it was either working as designed at that time or.... there was something wrong and then I also understand all the confusion.

 

[nmb]

Richard G,

I think you misunderstand about how SPF works. I have use -all for about 1-2 years already without any problem. All I have to do is to include only one Server IP in SPF. That's it. You can use any email client (Apple Mail, Outlook, Thunderbird, etc.) in any devices with any ISP without having to add any other IP. Make sure your mail client connect to Server as a mail server to send it though.

Regarding your question about how Exim see, If you mean Exim on your Server, it checks only your email together with password. Nothing else. Not your home IP. And with TLS, this is secured. With this setting, I can be anywhere without knowing about IP other than my server IP. I can be in China, Hong Kong, Japan, USA or any Free Wifi Network and can still send an email without having to know their ISP mail server IP. No need to change any mail setting in my email client.

 

[zmippie]

Richard G, I think you misunderstand about how SPF works.

I came to the same conclusion. I'm sorry I spent so much time on this. And I'm sorry that Richard has had an active voice in turning the default for SPF records in DirectAdmin around.

Richard wrote:

If this does not make sense, how does your Exim "see" that my home ip is allowed to send mail for my domain if it's not included in the SPF record?

As nmb tried to explain, and as I said before: your home IP address is not a factor in this entire process. SPF is a check done between sending/relaying and receiving mailservers.

Oh, and as for spamexperts: my advice is to stay clear of that service (believe me, I know what I'm talking about). Fortunately it's not being widely used (only in NL?), and generally only by hosting companies that are... hmmm... how can I put this... "not amongst the most reputable". Just keep sending those user complaints about failed email delivery to the hosting companies deploying spamexperts, and it will hopefully be a thing of the past.

 

[Richard G]

I only heard good news about spamexperts before they were taken over by another company.

nd I'm sorry that Richard has had an active voice in turning the default for SPF records in DirectAdmin around.

Well I was not the only one and my objections were based on both my mail being refused by my mailservers which should'nt have happened then and trapped me into the thought that this was necessary becaus my pc is a sending host, and also shows up as a helo to my hosting server in the headers, like all e-mails do. And external mail things like office 365 and anti-spam servers.

or.... there was something wrong and then I also understand all the confusion.

So unfortunately this was the case and indeed I now understand all the confusion brought up.
However I wasn't the only one against it and even with my mistake about the home ip, my opinion does not change.
The use of external mailservers need adjustment of the SPF record by users, most of them can't do that.
Next to that there are also users who want to use their ISP's smtp or something like SpamExperts (if you don't like it doesn't matter) and Office365. And there are hosters who would like to provide this for their users if they want it.

The only thing which started the discussion was your statement about bad hosting, while you were doing this yourself already for years clearly by not using the -all.
Only that statement irritated me.

If you think I'm against a -all implementation, you're wrong. Like I stated in earlier posts, I'm against it when directly implemented without options. So with the need for creating custom templates for it if you don't want to use it and I'm against this need for custom stuff.

Imho it should be a switchable option for example in directadmin.conf.
Or like BBM's idea when creating a new user default checkbox is ON for "-all". OFF for "~all", which I think this can also be set in directadmin.conf.
So if it's globally switchable, I'm not against it, like stated before.