this post was submitted on 02 Nov 2024
23 points (100.0% liked)
No Stupid Questions
2315 readers
2 users here now
There is no such thing as a Stupid Question!
Don't be embarrassed of your curiosity; everyone has questions that they may feel uncomfortable asking certain people, so this place gives you a nice area not to be judged about asking it. Everyone here is willing to help.
- ex. How do I change oil
- ex. How to tie shoes
- ex. Can you cry underwater?
Reminder that the rules for lemmy.ca still apply!
Thanks for reading all of this, even if you didn't read all of this, and your eye started somewhere else, have a watermelon slice ๐.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
E-Mail is old. So old that when it was invented, "hacking" and "security" was not really something anybody thought about.
To send an email you connect to the recipients mail server and type in all the data of the mail. Including recipient, subject, mail body and importantly the address displayed in the "from" and "reply to" fields. They are all defined by the sender. The Email protocol has no way to verify if this information is correct and the sender is actually part of the aledged domain.
Today, when you send a mail, most of the time you will not connect to the recipient mail server directly, but to a "sending" mail server, which then sends the mail to the recipient. For example if you log in to gmail, you write the mail on a google Mailserver which sends it to the recipient. Or you connect to your companies exchange through outlook.
There is a modern extension to the mail protocol, which allows a domain owner to define the sending mail server which is allowed to send mails on behalf of this domain. But it is in the responsibility of the receiver to check. (Its called sender policy framework SPF)
So most likely intuit didn't do anything and the scamer just send mail without a sending mail server. And your receiving mail server did not verify the SPF correctly. Or intuit did not define an SPF. Or they did but it allows sources that do actually not belong to intuit but might be controllable by the scammers. This can happen if they want to send mails from cloud hostet systems and include them in their SPF, which may include systems by other customers of the cloud hoster.
If you want to verify mail yourself, look in the mail headers (often called: view source) and look at the "received" headers. They deta the full path the mail has taken including which system initially wrote the mail. They are ordered bottom to top, so the (chronologically) first entry is the lowest. Check if the ip adress/hostnames for the first few hops belong to intuit and if they don't, its most likely spam.
TLDR: what is necessary to send mails from somebody else's domain? Nothing. You can just do that. Mail is insecure by design and should be abolished.
Very good answer. It's really complicated since it's an old protocol and lots of different mechanisms have been added on top. I found one small error: You can't rely on the "received" headers either. Just the line from your mailserver and the IP and hostname right before. The rest of the path (before) can be fake, too. (And this regularly happens.)
Even if you do have DKIM, DMARC, and SPF someone can still spoof your domain and the admin will still get an email about it. After that, instructions are unclear since the receiving domain is rejecting it properly.
Ask me how I know
Yeah, it has to be both sides cooperating. You can set a recommendation what to do with mails that failed the checks. Including dropping the mail altogether. But it's open to the receiver to honor that request, or not do any checks at all.
What this person said... I keep telling my dad over and over that I can literally send him an email and say I am anyone and it will show up in his email box. I feel like the urge to make everything "user friendly" has put us in this situation. The mail headers are so hidden now, it's almost a chore to find them in most email programs, which is unfortunate.