LawsHosting
Verified User
What? Please explain this..... It reads as if you have a me @ me . com, you can spoof the from field to whatever @ you . com - unless I'm really dumb.
DirectAdmin 1.680
- Thread starter sewiti
- Start date
You can do this exact thing - if me.com and you.com are on the same server. If you're spoofing some random you.com domain that doesn't exist on the same server as the authenticate me.com email account, then SPF and DKIM won't pass on the recipients server... that's the intended function of SPF and DKIM.
For my purposes I have me.com on the server with one random email account that is used to authenticate SMTP then I can send mail from any number of me.com email addresses. Now if those me.com email addresses I'm sending from aren't email accounts or forwarders on the server, then when someone replies back, I won't get their message. But this keeps me from having to remember ALL email account passwords and I can setup email forwarders to funnel mail into a single email account.
In Thunderbird, you set up one SMTP outgoing mail connection - I generally do this by creating a completely random and long email account on the domain - the purpose of the email account isn't for receiving mail, it's for authenticating to send out mail. Then you can set up Identities in Thunderbird to send out mail from different email addresses.
Now... to be clear... the SMTP authentication email address and the identity email address that would appear as who the email is being sent from, have to be on the same server... for my purposes it's always the same domain name. But technically just being on the same server would work too.
I also use this in Gmail, where I have SMTP credentials (another random email address) that I specify when I want to send out email from another email address in my Gmail account. I think there's a few more hoops you have to go through in Gmail, but the bottom line is, I only have to remember one email account and password to authenticate to send out email from the domain name.
The SMTP authentication data and the envelope-sender (or from header) email address was never intended to be the same thing. SMTP authentication is separate from actually sending email. SMTP authentication just serves as a means to say "Yes, I am supposed to be able to send out mail through this server." Using whatever envelope-sender or from header you want to use has always been left up to the actual SMTP transaction.
What DirectAdmin is doing with this "fix" is saying that they believe SMTP authentication and envelope-sender/from header (I'm not clear which they are referring to... probably envelope-sender) must match. Or at least match within some complex system. I think that's opening a door that doesn't need to be opened. If ALL of SMTP wants to enforce that, then change the protocol. But for one system to arbitrarily decide that they know what is best is a path that I'm not ready to go down just yet.
Again... having said all of this and I've voiced my opinion against this "fix" ... I again will say that at least DirectAdmin provides a means to disable this. So it's not necessarily being "forced" on to anyone. I would prefer if this "fix" was left off by default and only turned on when explicitly understood by the server administrator or license holder, but that's just me. It's not that big of a deal to me, I don't have automatic updates enable - in fact I haven't even upgraded our servers to DirectAdmin 1.680 yet (I always like to see what the forum folks discover that they like or dislike) - so I'll add disabling this feature to my list of post DirectAdmin update duties and Exim and SMTP will function just like it has been.
To add to this a bit more, you can send an email from any email address. This is the deficiency in SMTP. When SMTP was first invented, it was built on the honor code that you are who you say you are. Instead of fixing this, the proliferation of SMTP (email) continued with this deficiency intact.
There is absolutely nothing to stop you from sending an email from [email protected]. This is why spam became so rampant. Instead of fixing the underlying issue with SMTP (or replacing it) the powers that be just kept adding authenticity measures to SMTP - SPF, DKIM, DMARC, ARC, the list goes on. But these all depended on recipient servers actually checking this and and gauging their spam score based on these authenticity measures. It's really only been the last few years where major email providers started utilizing SPF and DKIM as a means to gauge a message's authenticity.
Now you can send a message from [email protected], but odds are you're not sending that message through a server specified in microsoft.com's SPF record or signed with microsoft.com's DKIM key. So when a recipient server sees these, they immediately flag your message as spam.
If what DirectAdmin is doing were to be implemented into SMTP, then it would stop a lot of email spoofing - if not all. BUT... SMTP has been around for so long, doing this is going to break backward compatibility. That's why there are numerous band-aid solution to email authenticity. You don't HAVE to have an SPF record. You don't HAVE to sign your emails with a DKIM key. But recipient servers are probably going to gauge such messages with a bit of skepticism.
There's also a word of caution in this message. It's very difficult to change things once something has been out in the wild for a very long time with many different use cases. I've argued before that it's time for SMTP to be replaced. Build a new protocol that fixes a lot of the spoofing, spam, and phishing issues that have popped up since SMTP's invention. BUT... there are SO many people using SMTP, you just can't flip a switch and change everything. And the fact that there are SO many people using SMTP makes it difficult for any new communication protocol to get any kind of foothold.
Had the original SMTP RFC that was released in 1982 provided some way of insuring that the sender was who they said they were... you wouldn't have a lot of issues with spam and spoofing that has long since pained email. That lack of foresight in 1982 is what created these problems. And it's too late to go fix them now. Bugs and lack of attention in certain areas is always going to plague development - but the quicker you can squash those bugs before it reaches critical mass the better off you are.
Richard G
Verified User
Well... in the old days maybe. Nowadays chances are very big that recipient servers will just bluntly refuse those mails. At least Gmail and Microsoft will refuse e-mails without either SPF or DKIM record.
On our servers we also bluntly refuse mail without SPF record if I remember correctly.
It was also Microsoft always to begin with. They didn't see that as a good measure in the beginning. And at a certain point they started and now they use a very strict rule about SPF and DKIM since start of juni or juli this year. If hey had being more cooperating in the beginning, with several things, we would have a lot less spam these days.
What DA is doing is not a fix but a security measure, like was done with exim and dovecot before already with authenticating.
And I agree that at least certain security measures should not be implemented by default, but should be optional (like now disabling is) so hosting company's won't run into certain issues because some security issue is entered without knowledge. Because loads of DA customers to not visiti the forums.
Some measures would be great, but only if everybody is using them, like the authentication improvement. But other panels should do that too.
SMTP does not really need to be replaced. IMAP and POP also did not get replaced, they got improved and yes indeed that is something which SMTP would need too. I think that is what you ment.
But it must be done with an RFC because you need to get it improved worldwide with all parties changing it, like was done with pop and imap.
mhsolutions
Verified User
Hello!
I have a problem with file manager in the picture. can you know me how to fix it?
I have a problem with file manager in the picture. can you know me how to fix it?
I tried testing it in Goggle Chrome and in FireFox browsers - and I was not able to reproduce such issue. Please provide us all details how to reproduce the issue, including the exact version of browser you use there.
mhsolutions
Verified User
I use centbrowser. I have checked chrome, same as your test, no problem. thanks
I was not sure if I got it all right. How clear was the Exim update explained? I asked gemini flash 2.5 for a better explanation. I am sharing it here, since this A.I. as well thinks that Direct Admin should not have forced this upon the D.A. user(s) and creates havoc for nothing!
When the update is there (I am running on 'stable' which is still on 1.679) I wil add the extra line
AUTH_BLOCK_SENDER_SPOOFING = no to /etc/exim.variables.conf.custom
--> I wonder, can I already add this up front? Or will D.A./Exim complain about an unknown setting?
I really don't want all of the shops I am hosting to have problems with sending email! I am forced to UNDO the 'fix', and don't understand why D.A. works this way. They should let this choice to us, the 'D.A.' user. I REALLY hope D.A. listens and undo this FIX and use
AUTH_BLOCK_SENDER_SPOOFING = no
by default! Why harass the end users in D.A. hosting? This makes no sense. I am sure if I had not seen the 'fix', a lot of customers would have their shop interrupted, and the real problem lies in the fact that it takes several days to learn of this problem. A lot of end users immediately draw a conclusion, and think they need hosting somewhere else, as they loose trust. Why does D.A. want us to loose customers (or trust from customers), who benefits from that?
Here is the explanation by GEMINI FLASH 2.5:
This is the scenario we are now working with:
Here is the new logical flow of the check:
Result: The SMTP server will reject the email with a 550 error. The website's functionality is broken.
Your analysis is correct. The update will break this functionality.
Action: In DirectAdmin, create an email forwarder from [email protected] to [email protected].
Why it's a bad idea: This means any real email a customer sends to [email protected] will be forwarded to the noreply@ box, which is likely not monitored. This will cause your customers to lose incoming mail. While it would fix the outgoing mail problem, it creates a much bigger incoming mail problem. Do not recommend this unless you fully explain the severe side effects.
Action: As root, run the commands to disable the feature server-wide.
Generated bash:
sed -i '/^AUTH_BLOCK_SENDER_SPOOFING /d' /etc/exim.variables.conf.custom
echo AUTH_BLOCK_SENDER_SPOOFING = no >> /etc/exim.variables.conf.custom
da build exim_conf
Your best course of action is to advise your customers to implement Solution 1 option B, as their current method of authenticating as one user to send as another is precisely what this new feature is designed to prevent.
When the update is there (I am running on 'stable' which is still on 1.679) I wil add the extra line
AUTH_BLOCK_SENDER_SPOOFING = no to /etc/exim.variables.conf.custom
--> I wonder, can I already add this up front? Or will D.A./Exim complain about an unknown setting?
I really don't want all of the shops I am hosting to have problems with sending email! I am forced to UNDO the 'fix', and don't understand why D.A. works this way. They should let this choice to us, the 'D.A.' user. I REALLY hope D.A. listens and undo this FIX and use
AUTH_BLOCK_SENDER_SPOOFING = no
by default! Why harass the end users in D.A. hosting? This makes no sense. I am sure if I had not seen the 'fix', a lot of customers would have their shop interrupted, and the real problem lies in the fact that it takes several days to learn of this problem. A lot of end users immediately draw a conclusion, and think they need hosting somewhere else, as they loose trust. Why does D.A. want us to loose customers (or trust from customers), who benefits from that?
Here is the explanation by GEMINI FLASH 2.5:
This is the scenario we are now working with:
- SMTP Authentication: The script logs in using the credentials for the mailbox [email protected].
- SMTP MAIL FROM (Envelope Sender): The script then tells the server it is sending the email as [email protected].
- Email Reply-To Header: Inside the email's content, the script sets the Reply-To: header to [email protected].
The Reply-To Header is Irrelevant Here
The new DirectAdmin check happens at the SMTP protocol level, before the email's content (including headers like From: and Reply-To: ) is even transmitted. The check only looks at two things:- The username used for SMTP authentication ([email protected]).
- The address used in the MAIL FROM command ([email protected]).
So, Does This Corrected Scenario Still Break?
Yes, absolutely. This configuration will also fail and break after the update.Here is the new logical flow of the check:
- A user authenticates with the username [email protected].
- The user tries to send an email with the envelope sender MAIL FROM:<[email protected]>.
- The Exim ACL kicks in and asks the crucial question:
- To answer this, it performs the check described in the changelog:
Result: The SMTP server will reject the email with a 550 error. The website's functionality is broken.
Your analysis is correct. The update will break this functionality.
Solutions for This Specific Scenario
The solutions are similar, but tailored to fix this specific (and frankly, illogical) mail flow.Solution 1: Fix the Sending Logic (Highly Recommended)
This is the most logical and secure approach. The website's sending logic should be corrected. There are two "correct" ways to do this:- Option A (Best Practice):Authenticate as the address you want to send from.
- Change the script to authenticate with the [email protected] credentials.
- Set the MAIL FROM to [email protected].
- This is the simplest setup. The authenticated user and the sender are the same, so the check always passes.
- Option B (If you must use noreply@):Authenticate as noreply@ and send as noreply@.
- Keep the SMTP authentication as [email protected].
- Change the MAIL FROM to [email protected].
- Keep the Reply-To: header set to [email protected].
- This also works perfectly. The authenticated user and the sender are the same. When a recipient replies, it will correctly go to [email protected] because of the Reply-To header.
Solution 2: The "Make it Work" Forwarder (Technically Works, But Illogical)
To make the current broken logic pass the new check, you would need to create a forwarder that makes the check true.Action: In DirectAdmin, create an email forwarder from [email protected] to [email protected].
Why it's a bad idea: This means any real email a customer sends to [email protected] will be forwarded to the noreply@ box, which is likely not monitored. This will cause your customers to lose incoming mail. While it would fix the outgoing mail problem, it creates a much bigger incoming mail problem. Do not recommend this unless you fully explain the severe side effects.
Solution 3: The "Last Resort" - Disable the Protection
As before, this remains the fallback option to prevent immediate service disruption while you coordinate with customers to fix their sending logic (per Solution 1).Action: As root, run the commands to disable the feature server-wide.
Generated bash:
sed -i '/^AUTH_BLOCK_SENDER_SPOOFING /d' /etc/exim.variables.conf.custom
echo AUTH_BLOCK_SENDER_SPOOFING = no >> /etc/exim.variables.conf.custom
da build exim_conf
Conclusion
Thank you again for the correction. Your assessment remains 100% correct. This DirectAdmin update introduces a stricter security model that will break the sending logic you've described.Your best course of action is to advise your customers to implement Solution 1 option B, as their current method of authenticating as one user to send as another is precisely what this new feature is designed to prevent.
Last edited:
- Joined
- Aug 30, 2021
- Messages
- 1,188
@sec-is, please do not post AI generated content in the forums. It is relatively easy to coerce AI to give you the answer you prefer to see.
Yes you can set this up upfront. The option that disables this security check is an Exim macro. Exim allows you to define new macros even if they are not (yet) being used.
This feature is designed to discourage all new DA users for setting up their web applications in a way that uses sender impersonation.
The existing users can disable this feature if they were using sender impersonation over SMTP and are not willing to update the SMTP credentials to match the sender address.
Note, web application can use the native PHP
Yes you can set this up upfront. The option that disables this security check is an Exim macro. Exim allows you to define new macros even if they are not (yet) being used.
This feature is designed to discourage all new DA users for setting up their web applications in a way that uses sender impersonation.
The existing users can disable this feature if they were using sender impersonation over SMTP and are not willing to update the SMTP credentials to match the sender address.
Note, web application can use the native PHP
mail() function for sending emails. It does not require authentication.Thanks for letting me know! I assumed other people (who use Google or who read this forum) might have a better chance of getting this item explained. I did not want to 'keep this info to myself'. Perhaps you can integrate A.I. in the forum (just like X has a grok icon next to each item)? (just kidding).
With regards to setting it upfront, I went ahead and tested this myself just prior to your answer! And yes, that works well. In a previous (exim.conf) update an Exim variable needed to be updated, and it was not available in each version of Exim or named differently. And Exim did not start as it was instructed to use an unknown setting. I could have prevented this if I had done more reading up ahead :-( We never stop learning.
Your option: "the native PHP mail() function for sending emails" is not the best advise. Most important is there is no DKIM support, but there are more drawbacks such as no error handling. And SPF may go wrong if the domani runs on a different I.P. address than the main server.
With regards to the change: I do understand the choice for forcing this 'one mailbox user' via ACL and Exim. You enforced this to prevent rogue SMTP users to 'abuse' this (SMTP - from) option. On the other hand, we do have to explain this to our customers. For example, even I use the 'from' dropdown in Outlook. If I sign up somewhere, then I create a new email address on-the-fly, and in Outlook I add it so I can respond via that email address (and yes, I use the catch-all for this). FROM NOW ON all end users who do the same MUST either set a forward, or use the catch-all option. This is a thing we need to discuss with each and every end user, even if only 3% of all users on a D.A. box use this, and of those only 5% have not set a forward or catch-all (guessing a lot here).
With regards to setting it upfront, I went ahead and tested this myself just prior to your answer! And yes, that works well. In a previous (exim.conf) update an Exim variable needed to be updated, and it was not available in each version of Exim or named differently. And Exim did not start as it was instructed to use an unknown setting. I could have prevented this if I had done more reading up ahead :-( We never stop learning.
Your option: "the native PHP mail() function for sending emails" is not the best advise. Most important is there is no DKIM support, but there are more drawbacks such as no error handling. And SPF may go wrong if the domani runs on a different I.P. address than the main server.
With regards to the change: I do understand the choice for forcing this 'one mailbox user' via ACL and Exim. You enforced this to prevent rogue SMTP users to 'abuse' this (SMTP - from) option. On the other hand, we do have to explain this to our customers. For example, even I use the 'from' dropdown in Outlook. If I sign up somewhere, then I create a new email address on-the-fly, and in Outlook I add it so I can respond via that email address (and yes, I use the catch-all for this). FROM NOW ON all end users who do the same MUST either set a forward, or use the catch-all option. This is a thing we need to discuss with each and every end user, even if only 3% of all users on a D.A. box use this, and of those only 5% have not set a forward or catch-all (guessing a lot here).
error updating ModSecurity
Status code: 404 for https://dl.fedoraproject.org/pub/fe...ackages/y/yajl-devel-2.1.0-23.fc40.x86_64.rpm
But already i have installed this .rpm
===================== Coincidencia exacta en Nombre: yajl-devel ===============================
yajl-devel.x86_64 : Libraries, includes, etc to develop with YAJL
[alex@panel ~]$ sudo dnf install yajl-devel
El paquete yajl-devel-2.1.0-23.fc40.x86_64 ya está instalado.
Status code: 404 for https://dl.fedoraproject.org/pub/fe...ackages/y/yajl-devel-2.1.0-23.fc40.x86_64.rpm
But already i have installed this .rpm
===================== Coincidencia exacta en Nombre: yajl-devel ===============================
yajl-devel.x86_64 : Libraries, includes, etc to develop with YAJL
[alex@panel ~]$ sudo dnf install yajl-devel
El paquete yajl-devel-2.1.0-23.fc40.x86_64 ya está instalado.
staff_nowa
Verified User
We have Debian 13 still support legacy?
Richard G
Verified User
No, last supported Debian version on legacy is Debian 12.
nlaruelle
Verified User
- Joined
- Nov 12, 2023
- Messages
- 30
It was not explicitly stated that 2.4.65 fixes the 421 error issue, so I made the test.
I would like to report that updating Apache from 2.4.63 to 2.4.65 (through DirectAdmin custombuild) still leads to the error **421 Misdirected Request** – The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.
This is at least the case for Cloudflare users… not tested with BunnyCDN.
I do not use nginx_apache, and CloudLinux + Imunify360 are in use.
