More depressingly...
... it's 2017 and "non-ASCII Text" is somehow still considered the exception.
Penetration tester Sabri Haddouche has reintroduced the world to email source spoofing, bypassing spam filters and protections like Domain-based Message Authentication, Reporting and Conformance (DMARC), thereby posing a risk to anyone running a vulnerable and unpatched mail client. What he's found is that more than 30 mail …
Presumably that's (mostly) large companies sending out marketing garbage as hosted content or images. Surely that's no loss to you?
Nah, I've got a good set up (based around DEA) that means I don't see that kind of junk. It was bills from a couple of companies (Pulse8 possibly one of them) and some kind of customer alert from another.
>I have my clients configured to only show text
Like living dangerously!
My default is to display both, thus aiding spam identification:
Lloyds Bank [secure@lloydsconfidential.com]
Sage Invoice [secure@sage-invoices.com]
PayPal [support@bt.com]
All of the above are spam.
Worse still there's an increasing number of companies whose outgoing mail doesn't include any text. I have my clients configured to only show text and to pull it out of the HTML and sometimes the result is nothing at all :(
Even worse, I get this from a company I use:
Hello Client,
Unfortunately your email client is outdated and does not support HTML emails, our system uses HTML emails as standard. You will NOT be able to read thiis email.
HOW DO I READ THIS EMAIL
...
"non-ASCII Text" is somehow still considered the exception.
Well, seeing as the protocol relies on UUCP I don't really see anyway round this and, although I work with non-ASCII everyday I don't really see this as a problem.
SMTP has far bigger problems, such as no support for content encryption.
Email should have had mutual whitelisting since the start.
By design you can set the from email address to be anything
Often the first server outgoing is whatever ISP you are using even if you have your own custom from <name>@<mydomain>
I appreciate this is about more subtle aspects of "from".
Almost all spam I get is from real companies. The EU ones are breaking EU law.
Almost all malware I get the "From" is irrelevant. I know the attachment shouldn't be opened.
Almost all phishing I get the "From" is irrelevant, hovering on a link shows it doesn't go to the bank / paypal etc, or it's relating to a bank or company I have no contact with.
By default I have remote content off.
Really this vulnerability doesn't sound like a big extra problem. I never use any aspect of "from" to verify source. If in doubt I contact person by phone, or a known different email account.
It's not simple and involves the person that wants to send proving who they are and why they want to communicate.
You need private / public key asymmetric encryption.
It's not possible on the SMTP / POP or IMAP model.
Some systems do have embryonic versions of such a system.
Disadvandage is the sender would know you really exist. Advantage is that done properly with a micropayment to establish trust, spam would be gone. Troublesome senders can be revoked.
You don't expect me to publish a complete description with working code? Unfortunately the present system is hardly different to 1980s (email became established before web sites) or posts and telegraphs. "Spam" started when Telegraphic terminals moved outside post offices in the UK.
""Spam" started when Telegraphic terminals moved outside post offices in the UK."
"spam"[0] started a lot earlier than that. Consider the ancient Egyptian pharaohs plastering their faces all over everything, in a vain attempt at convincing the proles that they were gods on earth. Strangely enough, it worked. Just like today. I guess sheeple haven't changed much in 4,000 years, regardless of technology.
[0] Note CaSe ... "Spam" is a product of the Hormel corporation.
You need private / public key asymmetric encryption.
Which will immediately come up against several things:
1. No central key repository or generation point (or at least, not one trusted one).
2. Most end-users will find it too difficult to use - it's taken 20 years for https to catch on significantly and that's almost entirely server-based.
3. How do you validate that the end-user is who they say they are and that they are a valid user of that certificate? Look at the omnishambles in the SSL certificate space..
Sure, you can do PGP but even experts have increasingly come to find that not fit for purpose (for all of the reasons above and more). Some countires do have the ability to generate (sort-of) secure certificates for their citizens but they are few and far between and (in general) smaller counties with a smaller population.
Can you imagine the US or UK putting in place something to generate secure personal certificates? I can't - and even if they tried, it would end up being outsourced to some scum like Capita or Expedia and all you details would end up being extracted by some cracker and sold for pennies on the dark web. At which point you have to generate new certificates - for everyone involved. And if you outsource the end-user task to ISPs - how are they going to validate that you are who you say you are?
The servers should do MX header analyze lookups and then put a little globe icon to geolocate the IP that sent that garbage to you. This email from bad spam area > trash.
Had good friends visitng that area recently. How'd we share emails in that case?
Ok, I'm tech savy (almost, kinda, if you look at me sideways and don't turn the lights on) - how would his non-savy friends stay in touch?
"Really this vulnerability doesn't sound like a big extra problem. I never use any aspect of "from" to verify source. If in doubt I contact person by phone, or a known different email account."
You sir are a one-percenter. For everyone else who just uses email as a convenient and ubiquitous method of communication it (and the broader SMTP security issues described throughout this forum) is a problem. I'm thinking of my friends, family and colleagues who don't have your insight and guile but who could be one-percenters in other fields such as landing planes, fixing cars, or removing tumours.
In the early days you more or less had to. And that was the whole point of doing it. There were so many useful things you wanted to do that required it. Ideally smtp should have been ditched years ago in favour of something that actually copes with the inherent problems that weren't really problems in the early days, but somehow its never happened.
It's disappointing to see a Register reporter getting things so badly round his neck.
DMARC is a reporting system, not a spam filter. It reports to me, for example, about mail claiming to come from my domains but not sent by my servers. Mailling list servers are the most common culprits.
SPF is an anti-forgery system, not a spam filter. It's used so that recipients of mail can (if they can be ar$ed) check if the mail comes from a legitimate source. It works very well once you can get past all the misconceptions such as those demonstrated by the author of this article.
SPF, by design, and precisely because the 'From:' header is so easily forged, operates only on the SMTP envelope information.
SPF IGNORES the 'From:' header.
> DMARC only reports if your policy is set to "none", it can quarantine and reject mails if you like. or am I missing your point?
DMARC lets you broadcast a policy, that tells the world what *should* be done about messages coming from your domain and that are not authenticated a certain way. DKIM is one of those authentication methods and it can actually protect the domain used "from:" (the one in the message, not the smtp envelope). There are a lot of problems still however:
- Adoption rate is very low at the sender level (only a tiny % of domains have proper spf, dkim and dmarc policies in place)
- Adoption rate is still so-so at the received level. It's a much higher %, but there are still stupid situations like Microsoft still not doing shit about DKIM, and *lots* of self-managed smtp servers don't handle these things properly
And of course none of those policies, and use of those policies in email filtering, will do anything about the fact that most email agents are complete garbage. Take Yahoo for instance, you can mangle the subject line so much that it can alter their webmail GUI, still to this day.
Does anyone use DMARC and/or SPF for anything other than spam (and phishing) filtering?
We use it's presence on incoming mail for spam filtering, and make sure it's present on outgoing mail in order for our mail not to be flagged as spam by other companies. I'm pretty sure this isn't an unusual use case.
SPF is an anti-forgery system
Which the large 'free email' ISPs routinely ignore. Which is why I periodically get deluged with spam rejection bounces because someone on BTInternet thinks they can use my domain in their spam headers and BTInternet thinks that SPF checks are only for professionals..
(Yes - my SPF records are up to date and define exactly which email servers are allowed to send emails that use my domain names. Some ISPs check but a lot of them don't bother..)
...then your email is broken.
Use SPF to suggest where your mail comes from, but not definitive.
Otherwise, imagine this situation:
You send email to an important potential client. Their email address is their own domain that is forwarded onto their 'real' mailbox. Their ISP who they use for mail honours SPF. Your SPF records say mail will only come from your servers, yet the mail has just come from mx.bigdaddy.com (or whatever) . Email is rejected (and silly ISP drops rather than bounces in the mistaken belief that bounce messages are just spam). Potential client never gets your email. You are none the wiser.
This is nothing new and I'm not sure how it can be fixed. SMTP is fundamentally broken - at least from a security point of view. At its root there is a disconnect between how the mail is actually delivered and the message itself. SMTP is not much more than 'FTP with mailboxes' where the difference is that the two servers agree between themselves where to put the data. The format of an email message is defined but nothing in a basic SMTP implementation requires that it be read - it's just a chunk of data that one server uploads and the another copies to one or more storage locations. The 'routing' is handled through the SMTP protocol itself.
There are various frameworks such as SPF that allow a server to perform protocol level checking by at least verifying that the sender's claimed domain has authorised that particular server to send mail on their behalf but they are all opt-in. Receiving servers don't have to check and sending domains don't have to be configured. And making any of this compulsory or improving SMTP is a problem because the system is too widely used and still too important to break.
The evidence is that it's already broken. Is it too important to fix?
Good question. I think one of the issues at present is that because it's all receiver-side it can be a nightmare to set up strictly. Your users will start complaining about not getting emails and it can first-off take ages for anyone to realise where the problem is. Then resolving it is difficult because the error exists on a third party domain.
I only run a personal server but imagine if Tesco screwed up their SPF. it might take a couple of days before I realise what's going on. Then imagine the conversation if I call Tesco's customer support line to complain about it. It's not going to be as smooth and straightforward as it is to complain about a problem with a delivery :-/
Possibly could have a blockchain type system.
Email effectively becomes encrypted and decrypted only by your private email wallet. Your email address is entered as a transaction which includes your public key.
The blockchain holds the encrypted email.
Could cost a token to send a mail and get that token to receive. Works as an offset and Spammers would have to pay. miners get paid a portion of the token.
Spammers would have to pay
And when they crack your credentials (which is going to happen sooner or later) then they can send spam as you and, adding insult to injury, make you pay for it..
There are lots of reasons why 'pay to email' schemes have failed historically.
SMTP is too broken to be properly fixed. We need a new protocol.
>SMTP is too broken to be properly fixed. We need a new protocol.
X.400 ?
Suspect it might need to be dusted down and refreshed in light of experience both with X.400 implementations in the 1990's and with SMTP.
But given where we are in networking compared to 1990, perhaps the real problem is that it is time for the current IPv4 Internet to be replaced; just as it is time for copper to be replaced by fibre.
"By design you can set the from email address to be anything".
So to me, a complete ignoramus when it comes to email systems, all that intricate stuff is trivial compared to that simple fact; an email can arrive appearing to come from a spoofed address, which is commonplace.
And no one is able to fix that.
And no one is able to fix that.
Fixing it, as you put it, would break a lot of things. It's there by design, it's not a bug.
Removing the ability to spoof the from address would stop third party companies handling mail on someone else's behalf; a very common thing in business nowadays.
Removing the ability to spoof the from address would stop third party companies handling mail on someone else's behalf; a very common thing in business nowadays.
If that stops the practice of outsourcing marketing emails to spam houses that play fast and loose with all datasec and ITsec just to send me garbage that I didn't ask to be sent, then bring it on.
@Alister: "...third party companies handling mail on someone else's behalf; a very common thing in business nowadays."
It's been a very common thing in business since forever. The original use case was not about companies though - it was about a secretary or PA handling mail on behalf of her (ues, normally her) boss. That's also why there is a From and a Sender and a Reply-To.
it was about a secretary or PA handling mail on behalf of her
Interesting fact that may interest only me:
In centuries before the 20th, secretaries were almost almost always male. For many reasons - women were expected to work in the home and if they did work it was largely manual work. And secretaries (as the name suggests) were people privy to their employers secrets and the view was that only a man had the intestinal fortitude to cope with that..
All complete rubbish of course. But it was the case for a long, long time.
Really - no. You would just need a mechanism - something like DMARC - which can be interrogated to ask if a sending server is authorized to send messages for that sender - and obviously performing checks on both the SMTP MAIL FROM and what is inside the RFC (2)822 message, and ensure they match.
Nothing would forbid to allow more than one server.
SMTP was designed for very low bandwidth situations and slow links, but the situation is very different today, some more roundtrips won't kill the Internet.
You would just need a mechanism - something like DMARC - which can be interrogated to ask if a sending server is authorized to send messages for that sender
And what's to stop the server from just forging those permissions? After all, how can you prove that you are not a dog on the internet?
(The point I'm trying to make is that it's a little more complicated and identity validation is at the heart of it all..)
Really - no. You would just need a mechanism - something like DMARC - which can be interrogated to ask if a sending server is authorized to send messages for that sender - and obviously performing checks on both the SMTP MAIL FROM and what is inside the RFC (2)822 message, and ensure they match.
I've wondered something about that.
Lets say I send you a message from mike@welltec.edu.nz (using an actual email address) claiming to be that person and perhaps offering you a job position or any number of other things that could seem reasonable out-of-the-blue. What is there that checks any SPF information to see if the chain I've put in there is actually relevant to you, ie how can you check that I haven't spoofed the SPF or other such data, especially if you've never had anything in the chain before.
(not spent a lot of time looking at SPF yet)
an email can arrive appearing to come from a spoofed address, which is commonplace.
And no one is able to fix that.
Pretty much. The various bolt-ons put in place can mitigate some of the risk but, since they are not universally implemented, only some.
The SMTP protocol is broken, but worse than that, the means to have a fully-authenticated validated and unforgable identity does not exist. Until it does, protocols that rely on you being who you say that you are (like SMTP) will fail.
Of course, when that ability does exist, governments will use it as a tool of oppression.
I'm cheerful today eh?
Many folks in this thread keep saying "the SMTP protocol is broken" or similar ... I respectfully submit that this is incorrect. In actual fact, SMTP does exactly what it was designed to do. No more, no less. It''s not SMTP that is broken, rather it is the expectation of the user that is broken.
One doesn't use a ceramic tea pot as a hammer, now does one?
Now THAT's brain-dead ... and probably the real story here.
The "From" line is user settable. Always has been. As a result, it's not a reliable indicator of anything, EXCEPT in the mind of the sender. Trying to change this simple fact would break all kinds of things.
"The "From" line is user settable. Always has been. As a result, it's not a reliable indicator of anything, EXCEPT in the mind of the sender. Trying to change this simple fact would break all kinds of things."
I explain it to non-techies as being like the sender address that you write on a parcel that you are posting. You could write any address there, and the Post Office is not going to check it in any way. I then follow it up by sending them an e-mail that has "From: Father Christmas <SantaClaus@northpole.net>". This has always been sufficient to make the point, even to the least IT-savvy people that I know, and they tend not to ask me again about why a friend of theirs has sent them something peculiar or offensive, seem less likely to take a suspicious e-mail at face value.
The question about whether this kind of thing should be prevented is a different one of course.
There seems to be a view in some comments that being able to spoof From: is a Good Thing.
I challenge that. It facilitates all sorts of crime and what's possibly worse is that business who "legitimately" make use of this are training their correspondents to be phished.
Take a typical phishing email:
- The From: field claims it came from some bank.
- Examination of the headers shows that it came from elsewhere
- It has a link to an image of the bank's logo - probably a genuine link as an image of the bank's logo isn't difficult to find on the bank's website
- One or more links in the body of the email that appear to point to the bank's web site but on closer examination point elsewhere. The object of the email is to get the victim to click on one of these.
Now take a typical outsourced valuable marketing message spam from a bank:
- The From: field claims it came from the bank.
- Examination of the headers shows that it came from elsewhere
- It has a link to an image of the bank's logo
- One or more links in the body of the email that appear to point to the bank's website but on closer examination point elsewhere (this is my experience - they use a sub-domain of the bank but it resolves to the digital marketing spamming company). The object of the email is to get the victim to click on one of these.
The result is that the genuine article authorised spam looks exactly like a booby-trapped phishing spam. The wary will treat the two alike and ignore the bank. The unwary will treat the two alike and get phished. It's time this was stopped. If, as a by-product, it stops banks and other businesses spamming the public nothing of value will be lost.
The real issue isn't so much the "From" line, but what gets displayed and/or made available to the end user to enable them (and their spam filters) to determine the providence of an email.
Remember we are talking here not of anal retentives who check the header details of every email received, but normal users who do use the "From" field to help them determine if a message is worth opening or not.
Thus whilst it is good your server supports SPF etc., have your clients correctly set up their SPF records to include your server? Also we shouldn't forget the "Reply to" address, as I've had legitimate-looking emails with a distinctly dodgy reply to addresses.
The real issue isn't so much the "From" line, but what gets displayed and/or made available to the end user to enable them (and their spam filters) to determine the providence of an email.
Not really. If the spam mails get that far then most idiots won't really care about the from, which in programs like MS Outlook can be further obscured. The filters for good reason don't really care about the from header but you'll find that they do care if it looks like the bcc header is being abused, which used to be a common tactic.
While it would have been nice to have seen extensions to SMTP over time, including the ability to not to downgrade communication, I believe that there are plenty of reasons why these were never rolled out.
Still, for all its problems, SMTP is an open and reliable protocol that guarantees that e-mail can survive providers whims. More and more people are moving to proprietary messenger formats which offer little other than vendor lockin. Brave New World…
you'll find that they do care if it looks like the bcc header is being abused, which used to be a common tactic.
Quite annoying that as well. An example, I had a mechanical question and have a number of mechanics and engineers among my friends and contacts, so I sent a message to myself with a number of these people BCC'd. They're people who don't necessarily know each other and who haven't given me the OK to give their email address to anyone else, so by using BCC they're protected (yes I could use mailmerge but I find BCC much quicker and easier when my limited mental capacity is trying to work around something else). Several of these people use gmail, but only ONE had a message rejected by gmail because I was using BCC, one I'd been exchanging material with for some time.
Using BCC legitimately, nothing spammy in the message or message body (which was plain text as well - maybe that triggers warnings these days?), and most of the messages got through including to the same provider.
I have friends who'll send out a "Christmas news letter" to family and friends (sent to people who want to get it and sent from someone who is able to write about interesting subjects in an interesting manner about the very interesting life he leads and work he does). They generally use the same method, BCC to everyone instead of CC to everyone, or a massive TO header. I'm not sure how this actually shows "spam" since the spam I receive comes from places like LI and FB anyway, and all the other stuff comes from use of tools like mailmerge. I can't recall ever hearing of actual spammers using BCC.
--> Paris coz I'm sure she fully understands "mail merge"
Actually for most email senders that's impossible to control.
Only a percentage of corporate SMTP generate that info and almost no ordinary users utilise it.
Hence links and attachments must be regarded as malicious unless proved otherwise. By default remote content must be blocked and reception acknowledgement requests ignored.
There is no easy instant fix, or we would have had it 30 years ago. The problem was well known then.
Many ISPs only let you use THEIR SMTP.
I have very many domains I pay for.
I have many email addresses, some are @<current isp>, some @<my 1990s ISP>, some @<my own domains>, also gmail, yahoo etc.
They are technically spoofed, simply text in the email client configuration. However anyone using the From: or Reply-To: results in mail that eventually ends up at a server somewhere. Some of these forward to other email accounts & delete. Finally my email client uses POP3 from a much smaller number of email accounts. All of the email gets back to me no matter which spoofed address I used as they are all "real" somewhere, though I might not be doing IMAP, SMTP or POP3 with some of the domains at all ever (the hosting of the domain is forwarding to some-place I have IMAP or POP3 pickup).
Other than useless web mail, using many of my domains directly would be impossible on many ISPs as they only allow SMTP outgoing to their own server. I have a huge list of ISP SMTP in my client for when I visit friends / relatives.
I used to travel a lot. Then I had a VPN server in the attic and logged on to it before doing any email or browsing.
You don't want to use Library or public or College Internet ever for email. We set up the VPN clients to use port 80 to get round University port blocking :) The Router mapped it from port 80 to the port used by the attic server.
Many ISPs only let you use THEIR SMTP.
There is that
Slight correction - most ISPs block port 25 on a domestic line. On a business-class line, generally they don't and you can use your own SMTP server if you like..
(As I've done for many, many years. Qmail/vpopmail/roundcubemail is my friend..)
Some of them will want to probe your SMTP server first to make sure you are not running an open-relay.
@Doctor Syntax
There seems to be a view in some comments that being able to spoof From: is a Good Thing.
I challenge that. It facilitates all sorts of crime and what's possibly worse is that business who "legitimately" make use of this are training their correspondents to be phished.
You seem to be under the impression that this is a technique only used for marketing emails. This is absolutely not the case. Lots and lots of businesses don't want to, or cannot, run their own email server, but do have their own domains which they wish to use.
Like Charlie Clark above, I run SMTP servers providing email services for multiple businesses, on multiple domains. I don't do mass-marketing, or newsletters, just normal everyday emails.
If I was unable to spoof the from address, I would have to set up an individual mail server for each and every domain I host. This is patently not a sustainable solution.
If I was unable to spoof the from address, I would have to set up an individual mail server for each and every domain I host. This is patently not a sustainable solution.
Really? An SMTP server doesn't change on a rapid cycle, therefore it should be possible, albeit difficult, to use virtual machines (perhaps even containers) with automation to set up and, when necessary, tear down those servers. The problems to be addressed are found in the SMTP servers themselves as I recall and I predate e-mail by a few years. There's a rather long list of services that "could not be virtualized" on PC's and I predate that list too. Lord knows I beat my head against the virtualized Domain Controller problem in the first betas of VMware way back when. Eventually, work on the virtualization side and the domain controller software took care of getting rid of that squishy sound here.
Saying "never" usually means that you've boxed yourself inside the problem space. I'm off to do some research. This is tedious, finicky, a real beast from my experience with mail servers.
Let's say Jane Doe has a domain jdoe.org
There is a problem and her domain mail servers are down.
She can use her isp provided email account to send a few important emails (with from spoofed to her proper domain) until her domain host sorts its act out.
A trivial example of why spoofing is useful.
Only a muppet triuts the from address as being authorative
Email is very convenient for a lot of tasks where security and authentication are not that critical. It is also perfectly possible to sign and or encrypt them.
I may be being simplistic but "problems" of this nature seem to me complaints that people want to be sure of the sender but don't want to be bothered with signatures and/or want security of communication but don't want to bother with encryption.
Why are the headers so painful to access in many clients?
I know the great unwashed don't understand them so they must be hidden to keep the illusion that its all simple and magic, but they hold the closest thing to the truth and I want to be able to read them. Not to have to do the computing equivalent to searching in the basement with no stairs, in a filing cabinet, behind a sign saying beware of the leopard. Hurmph
@DwarfPants: Because they hate you. :)
About the only reason why I've not gotten around to setting up DMARC, DKIM, and SPF on the domains I admin is because a) I've never done it, and I don't want to break things; b) I've not had time to properly research and test it using some of the spare domains we have lying around; and c) I usually have more pressing issues to deal with, and breaking a working service is not exactly in my best interests.
a) Ah, the greybeard sysadmin that refuses to learn anything introduced past the 1970s, and uses the 'I don't want to break things' as the main excuse.
b) Aren't you paid to ensure your systems are using the best solutions and practices?
c) better protecting your messages from spoofing is not important?
Lazyness will kill the internet....
a) Ah, the greybeard sysadmin that refuses to learn anything introduced past the 1970s, and uses the 'I don't want to break things' as the main excuse.
And a good one at that. A downed or mis-behaving server can cause all sorts of problems including lost reputation, lost ability to communicate with clients, and of course loss of reputation. If you make a small mistake that means your server isn't sending emails out, or is sending them out with wrong details (and thus emails from your server get treated as spam) you can lose productivity, clients and of course money and sometimes that can be quite high. If your system gets flagged by spamhaus etc as sending spam, then it can take a while to undo the damage to your reputation (it's bloody hard enough getting them to trust a new domain as it is!), and clients don't trust a firm who has their emails constantly going into the spam folder.
If you put your trust into a system that doesn't get widespread adoption then it's a waste of time for the majority of emails sent.
The prudent thing is to wait and watch for a while until the tech is stable and adopted enough to make it worthwhile (of course, there is the problem that if everyone sits and watches...)
b) Aren't you paid to ensure your systems are using the best solutions and practices?
Yes. Keeping things functioning and stopping them from breaking, stopping them from having problems etc - keeping it working efficiently with the minimal fuss, maintenance and downtime is "best practice" - what returns the best overall profit, not necessarily what is the best tool for the job. Remember that an admin's time is often very limited and if you show me a company where the admin has plenty of time to research and play with these things I'll show you a company who can expect to lose an admin in the next downsizing.
c) better protecting your messages from spoofing is not important?
A new system doesn't necessarily work better. I've seen a number of systems come and go over the years designed to better protect email. They didn't get widespread adoption, I guess largely because the cost of installation and administration outweighed the gains from the protection.
Those who installed this stuff also later had to remove it when it failed, perhaps re-train users to use replacement systems. Take the latest and greatest if there is an urgent security need. Use old and stable otherwise.
v=DMARC1,p=none,rua=mailto:<reports@my.domain.com>,ruf=mailto:<forensics@my.domain.com>
can't break anything
SPF Wizard - generates a nice neat SPF record
my.domain.com. IN TXT "v=spf1 mx a ?all" shouldnt break anyting
DKIM is the tricky one, co you have to generate the keys and get your Mail Server to calculate and add the sigs, add them
Thanks for the *helpful* information (unlike the anon cow-ard who was probably the downvote source)
The SPF wizard does appear to work nicely; I just have to go 'round and see what all else decided to bypass our mail gateways (including a handful of external services!) so I can put in something that's 'correct enough'. Same with DMARC.
Our mail gateways have a toggle and setup for DKIM, I just have to review the documentation in my copious free time (which may happen next week, TBH) and make sure I've got all the parts ready for it.
"a) Ah, the greybeard sysadmin that refuses to learn anything introduced past the 1970s, and uses the 'I don't want to break things' as the main excuse."
HAHAHAHAHAHAHAHAHA *Falls out of chair laughing* You verry funny person! (It's more of "we don't have a test environment set up to _properly_ test things before whopping it on production" sort of excuse. Also, the stuff I've been using is a touch more modern than sendmail. (which I've never admin'd, I'll add- postfix (iirc) and exchange, and some really oddball windows smtp server app which I've forgotten the name of)
Also, I have no beard. :P)
"b) Aren't you paid to ensure your systems are using the best solutions and practices?"
Yes, but that's job number.... well, not job #1. or #2. Maybe job #7 or 9, but it's in the top 20, I assure you. (I like using standards and best practices; less documentation for me to write, and if I get hit by a bus, whoever steps in can get up to speed a bit quicker.)
"c) better protecting your messages from spoofing is not important?"
Lately, we've been more concerned with incoming messages rather than outbound messages- but that's on the list as well.
Yes!
If correctly parsed the From address in many of the demo's should be <demo@mailsploit.com>
However,when you reply the address is taken from the "Reply To" field, which (in the demo's) has been set to: potus@whitehouse.gov.
More details and an option to send 14 different test emails to yourself at https://www.mailsploit.com/index
In my experience, petitioning Mozilla to make any adjustments to Thunderbird results in a response which ultimately boils down to "not my table."
But the sad fact is, it's still a hell of a lot nicer to use than any of the other stand-alone mail clients for Linux.
Thunderbird is probably the most comprehensive and shiny GUI mail client available on Linux, but it is also horribly bloated.
Claws mail is the best alternative as far as I can see (and not vulnerable to this attack IIRC) - it's GUI enough to not need years of fiddling to become comfortable with, feature-complete for almost everyone, reasonably bloat free and dead stable.
Not brilliant for viewing HTML email, but then again I'd rather not have a full blown web browser embedded in my email client anyway...
(The situation isn't any better on Windows by the way, proper email clients are sadly not fashionable and nobody seems interested in working on them.)
Thunderbird is probably the most comprehensive and shiny GUI mail client available on..
.. all the platforms I use. Mac, linux and Windows.. Yes - there are some open-source mail clients that also run on all three, but most of them have limited functionality or look like a mail client from 2001..
But the sad fact is, it's still a hell of a lot nicer to use than any of the other stand-alone mail clients for Linux.
Thunderbird does a nice job of highlight folders that have new mail in, and highlighting the folders above them if you're using a collapsed view (so if I get something from the Accounts people at my Power company that's filtered into the correct place in the Utilities tree under my Inbox (Inbox -> Utilities -> Powerco -> Accounts Dept) then the lowest visible one of those folders will be highlighted with blue text. If I have the lot collapsed just showing the account name, that will be the one that gets the highlight.
However. Thunderbird is an outright PAIN to compose messages in where formatting is important (without lots and lots and lots and lots of faffing around with styles and paragraph spacings etc - I just want a nicely laid out clear easy to read email without gobs and gobs of space between paragraphs or with other formatting going to pot), misses the boat on simple things like rightclick -> create filter from message (instead you have to go off into places most users will never find), has a bug (STILL!) where it can bring up reminders for recurring events months after they've been deleted, and lacks a few other nice bits of functionality I have to go elsewhere to find.
I still sometimes call it up because I haven't seen where a new message went to.
If the TB team at Mozilla could actually get off their arses and start listening and improving things instead of making their stuff worse.. Oh, right. Mozilla. What am I thinking? TB got too good and now they have to actively ruin it, like they did to Firefox when that was still around.
...what fun responding to this one has been. The well-known mail filtering service that, when I pulled them to see when they'd be adding detections, seeing as 11/14 test mails using variants (available at http://mailsploit.com), responded with a ouzzled-sounding request for samples... First line eventually responded that he'd be escalating it to "security engineers".
These days, there seem to be quite a lot of young, startuppy firms who, despite pedalling some sort of of buzzword laden hipster magnet nonsense (that The Business insists it needs to use), really do seem to properly Get It about security. They respond quickly to news about vulnerabilities, researches mailing security@bizzystartup.com get a reply from someone with clue within an hour or two, they have immediate answers to questions about their security practices. When they inevitably suffer some kind of incident, hey go public very quickly and share info openly and transparently as possible. They give researchers public credit. They have people's they spend money,.. they are, in short, everything my employer is not.
And yet my employer is knocking on the door of a billion (sterling) profit a year, and startups that get it are acquired by clueless multinationals or bought out to be shut down.
The wheels grind slowly, slowly. I hope they do grind small, even if I don't live to see the day. The karma is in the post - right, kids?
Right?
Mine's a double....