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.