Did I read that headline correctly? A Hoax? Dude, you MUST be joking or smoking something, how do you figure they're a hoax.
Nope, not joking nor high, AND, just to set the record straight, I'm NOT talking about Anti-Virus applications, themselves, just the email scanners they, for the most part, force on you. Email scanners are an unfortunate joke, a lie perpetrated by a few of the A/V manufacturers in the early days to make money. They are totally redundant, they offer ZERO additional protection over the resident file system scanner, they waste both time and system resources, and, most importantly, they are HIGHLY TROUBLE PRONE. These A/V folks did such a good job of selling the concept to users that just about every manufacturer includes them as part of their system, in spite of the fact that they knew at the time email scanners weren't needed. These are pure and simple truths mandated by the email sending protocol, itself. Let's talk about that.
Regardless of what kind of email account you have, everything you send via email is sent using the Simple Mail Transfer Protocol (SMTP for short):
POP account? Sending is by SMTP.
IMAP, Exchange Server? Again, sending is by SMTP.
Fine, why is that important?
SMTP is as old as the Internet and is mostly the same as the day it was released. It was built with one very important characteristic that is paramount to this discussion, it will only transfer Plain Text printable characters - letters, numbers, punctuation characters, and a few others to handle carriage returns, line feeds, and the like. Plain Text is harmless, it CANNOT be executed; you need binary data for that.
I hear you scoffing at that last statement. "Why, my email comes in with attached files and pictures, it has a wide range of fonts and text colors, and ALL of that involves binary data". True, but the fact that only plain text is allowed remains. ALL these things you mention that involve binary data are, in fact, sent as plain text. How? Simple, the binary data is converted to plain text BEFORE it is sent! On the receiving end, the plain text is converted back into binary data and THIS is the key, right here, the reverse conversion process
I should add, at this point, that SMTP has received several extensions to address this plain text limitation, things like 8BITMIME, 8BITCLEAN, and BINARYMIME. In fact, it's now called ESMTP (Extended SMTP) which allows for the transfer of 8-bit data. These are all still forms of content transfer encoding which in turn, also still means that a decode process is required on the receiving end.
The conversion process, Content Transfer Encoding, has used several different methodologies over the years, names like Bin-Hex, S-records, and MIME (Multi-part Internet Mail Extensions, the current methodology); they all do the same thing, they take a block of binary data and convert it to transferable data on the sending end and do the reverse on the receiving end. This is our attack point, that reverse conversion. In this process, transferred characters are converted into binary. The converted data characters must be stored somewhere as they're converted. Enter the resident file system scanner, the main defense engine of every A/V application on the market. This scanner watches writes to memory, drives, the screen, and anywhere else used to store data as its written.
So, let's say someone sends you a virus hidden in an attachment. Remember, this attachment is a formless block of data as it enters your email program and totally harmless in this condition. You then decide to view the attachment. The email program dutifully takes the data block and starts converting it to binary, one character at a time, writing each to a buffer somewhere. Our resident file system scanner is watching this process and checking each character as it's being written. After a few characters, the scanner notices the data pattern being written matches a known virus and BAM! the process is stopped, the binary block is quarantined, and you get a message from the scanner telling you it has detected and quarantined the bad guy. Our virus never stood a chance of ever being executed. Again, this process and the scanner involvement applies to each and every email you receive, no exceptions, you are as fully protected as the A/V application can make you.
Now, lets talk about that email scanner. I just finished showing you how the resident file system scanner FULLY has your Six, so how does an email scanner help? Plainly and simply, it does NOT help. It does exactly the same thing the file system scanner does, but often makes a big mess trying to do so because of the way it must operate.
I like to describe an email scanner as a small office with two doors, one in and one out, and one window. The office is staffed by two liars and an office clerk; one liar stands by each door and the clerk has a desk in the middle; beside him is the window which has the file system scanner folks on the other side. One liar is there to tell your email program that the office is your post office, the other is there to tell your post office that the office is your email program.
Let's repeat our virus-laden email experiment. The email arrives from the post office- a postal worker knocks on the outside office door looking for your email program. Liar #1 opens the door and swears up and down that HE is the email program, "Please hand it to me." and the postal worker does. Liar #1 then hands the email to the file clerk. The file clerk whips out a letter opener, opens the letter and throws away the delivery envelope(this is important!). He then hands the letter through the window to the files system scanner folks who scan it and either return it intact (a safe email) or return it with the virus removed and a warning message (the expected result for the infected email we just received). The file clerk takes whatever comes back, puts a new envelope, does his best to remember all the addressing data that was on the original envelope, and hands it to liar #2. Liar #2's job is to swear up and down that HE is the postal worker, "Here's your mail".
What's wrong with this picture? Pretty much EVERYTHING!!
First, our two liars. Habitual liars often have trouble remembering the exact details of the lies they tell, so we immediately have the potential for problems- you change your password at the post office, but liar #1 forgets this and the postal worker won't give him the email. Something changes with your email program, liar #2 forgets this and puts your email in the wrong folder or deletes it along with other emails. And then there's the file clerk and the discarded envelope. He tries his best to remember all the addressing, but doesn't quite and this confuses the email program- nothing but problems! The final insult? The resident file system scanner is used, the same scanner that would have safely caught the virus WITHOUT all the extraneous nonsense we just went through.
Quite a difference it the two processes, isn't there? In the first case, you get your email with the virus removed, no extraneous nonsense. In the second case, usually (but NOT always) you get your email with the virus removed, the email may or may not go to the correct folder, and there's a very good chance it will be bent, folded, spindled, or mutilated when you finally get it because of all the extra handling and the loss of the original delivery envelope.
The long and short of this is, keep your Anti-Virus installed and make sure it's always up-to-date, but if it's possible with your chosen Anti-virus, DISABLE the email scanner features. If you happen to have Windows Defender, there's nothing to dump, it does not have an email scanner. Microsoft got this one correct. If you happen to already be Roland Schorr & Tower customer there is also nothing to do, this feature is not even there to cause problems. A service like RST Secure mail that scans and removes email malware ON THE EMAIL SERVER. does a great job for our customers.