I was trying to send the eicar.com virus to someone to test an antivirus. When I've tried to send it as is, Google SMTP blocked it, saying that the software was malicious.

So I've zipped it with a simple password (1234) and it blocked it again. I assumed that the server somehow brute forced it because the password was too simple. So I've then tried to use a stronger password (jfdsg4453dsfsf), and it blocked it again.

For testing, I've also tried to send a similar non-virus file in a zipped, password-protected, archive, and it works.

So I'm wondering, how does Google know what contains a virus and what doesn't? Since I've used different passwords, it cannot check the hash or anything. Or is it that zipped archives can be easily brute forced?

  • 1
    @pnuts, the conditions when it didn't work (with the encrypted virus) and did work (with the encrypted non-virus) were the same. Same subject, same body and recipient. At first, I indeed thought it was recognizing the same email so was blocking it, but since it worked with the encrypted non-virus attachment, it must be something else.
    – laurent
    Sep 25, 2014 at 8:19

5 Answers 5


Most likely, your archiver only encrypts file contents by default, and leaves filenames in clear text. This allows a user to browse the archive and selectively extract individual files by name. WinRAR is one such archiver.

Try renaming your file before archiving it, or enable filename encryption before sending.

  • Are you saying Google only noticed the filename "eicar.com" in the archive and said it was a virus just based on that name? Sep 26, 2014 at 19:22
  • 3
    If the contents of the file are encrypted with a password, I’d say that’s likely.
    – user13779
    Sep 26, 2014 at 22:34
  • @Phong Winrar encrypts file names as well as contents and I'd sent password encrypted .rar files with non-malicious Javascript files before, they still got blocked. How far-fetched is it that Google owns enough computing power that it can brute-force and unlock encrypted .rar files?
    – pilau
    May 25, 2016 at 22:15
  • @pacoverflow Probably just the ".com" extension was enough. A file with a ".com" extension is treated as an executable on Windows, though 64-bit versions won't be able to run it. This goes back to MS-DOS, where .COM was one of two supported executable formats, along with the more familiar .EXE. It's pretty obscure now, as not only is it obsolete, but ".com" has had an entirely different meaning on computers for quite a while.
    – Sparkette
    Dec 10, 2020 at 20:16
  • @pilau security.stackexchange.com/questions/35011/… Probably not, at least not enough computing power to do it every single time someone tries to email an encrypted .RAR archive.
    – Sparkette
    Dec 10, 2020 at 20:18

I think @Phong's answer is probably correct, but Gmail also blocks certain encrypted attachments no matter what.

Note, zip and tar.gz archives don't support an encrypted filelist but rar and 7z do.

From Gmail's help-page:

It isn't possible to send a password-protected zip file containing a zip file. Please de-compress all files or remove the password protection if possible.

I tried testing this, and I didn't see this very uniformly enforced.

To test, I tried to email myself 8 different compressed archives containing a non-virus binary, with and without encryption, and with and without an encrypted filelist. Oddly enough, the only file Google blocked was the content and filelist encrypted rar archive, which it reported as a "Blocked for security reasons!".

It allowed everything else, including the plain password protected zip file their help page claimed would be blocked, which is strange. You'd think if Gmail would block a filelist encrypted rar, they'd also block the open filelist rar? Maybe they saw the filename "definitely_not_a_virus.exe" and took my word for it?

The best part is this "protection" is easily foiled because it's entirely based on the file extension. If I give my filelist encrypted rar a txt extension, Gmail allows it.

  • the only thing that worked for me was a 7z filename encoded and renamed to .txt Nov 3, 2017 at 12:23
  • It's a good thing that it's easily foiled, really. It shouldn't be there in the first place, unless you can turn it off.
    – Sparkette
    Dec 10, 2020 at 20:10
  • 1
    note that the simple fake .txt extension doesn't work any more (but if you compress it again without encryption then it works :p) f**king google.
    – Gab
    Apr 21, 2021 at 8:36


Currently Gmail blocks any of

  • Archives whose listed file content is password protected
  • Archives whose content includes a password protected archive

regardless of the contents.

The only solution is to rename the file or use Google Drive attachment as forums link above suggests.

  • Ha what about password protected archives that contain password protected archives?
    – Timmmm
    Jun 25, 2022 at 12:50

Yeah as other have said, it doesn't know; it assumes. If you have a big archive of deadly dangerous executables that you want to send then the following does not work:

  1. Renaming the archive, e.g. archive.sevenzip. Google does file type detection.
  2. Encrypting the data - Google rejects it based on the filenames (.exe).
  3. Encrypting the data and filenames - Google rejects it based on the fact that it can't see the filenames.

However I did find a workaround!

  1. Compress the original data (.exes) once with data and filename encryption.
  2. Compress that archive again but this time with only data encryption.

Google won't reject it out of hand because it can see the filenames, and it can't look into the inner archive to tell what's in it so it lets it go.

Enjoy it while it lasts. I assume they'll just block all encrypted archives eventually even with plaintext filenames. Wouldn't want users using things.


Gmail makes money by reading all your emails and attachments. If they cannot read your attachment, they just don't allow sending it. That's why password protected zips are not allowed:

Password-protected archives with archived content

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.