Exact match. Not showing close matches.
'[TECH] RFC that forbids zip within a zip'
We started having problems with emails getting blocked by one of our vendor's mail servers:
184.108.40.206 failed after I sent the message.
Remote host said: 551 Message contains ZIP file that is too deep (4) (Mode: normal)
The president of their IT company said this:
"Even though the manufacturer allows it, I would not put a zip archive inside other zip archives as a standard practice. The path to the archived file can be too long, thus the message that the "zip file is too deep".
Just to let you know, it is also a standard virus ploy (hiding infected files or malware inside a clean archive) that is no longer allowed by many RFC-compliant mail servers. "
I did a search out of curiosity, but could not find the RFC in question. Is he full of it?
On Wed, 2010-09-15 at 12:14 -0700, Vitaliy wrote:
I think you misunderstand his statement.
He's saying that many mail servers, which happen to be RFC compliant, do
not allow it. He's not saying it's disallowed my the mail server.
As for the issue, yes, it's common practice by malware to multiply zip
the payload, the assumption being that the anti-malware software will
only "unzip" a certain number of times. I can't confirm that mail
servers reject emails because of this.
M. Adam Davis
There's no RFC specifying a limit to the depth of nested compressed files.
However, most virus checking programs will only go down to a certain
depth when scanning compressed files. It is this program to which he
refers when he mentions the error "zip file is too deep". This is to
protect the server from being bogged down by intentionally deep files
(on the order of thousands deep). There are some programs that treat
nested zip files as directories along a path, and have a finite path
length, so this depth limit may also be meant to prevent buffer
overruns in the path, which can be a security problem in poorly
designed compression software. Limiting the depth is a poor solution,
though, because an archive could contain a very deep path already,
such that zipping it once would break software that places limits on
It is certainly ludicrous to change that setting so that files which
are compressed twice cause this problem. A more sane setting would be
between 5 and 10 deep, which would allow most backups (which often
contain zip archives) to go through.
Technically, I doubt RFC compliant mail servers care. Generally
software plugins for virus and spam detection are used to examine
attachments - the mail server has little need to unzip anything. This
further removes the whole issue from the realm of RFC compliance.
His comments are technically odd, but the message is simple: "I will
not support nested compressed files. If you are experiencing
problems, you are on your own unless you follow my guidelines."
On Wed, Sep 15, 2010 at 3:14 PM, Vitaliy <maksimov.org> wrote: piclist
On Wed, Sep 15, 2010 at 8:21 PM, Herbert Graf <gmail.com> wrote: hkgraf
> As for the issue, yes, it's common practice by malware to multiply zip
> the payload, the assumption being that the anti-malware software will
> only "unzip" a certain number of times. I can't confirm that mail
> servers reject emails because of this.
Attackers know that all modern AV scanner has sophisticated decomposer that
does recursive unpacking. There are though many issues that raises. First of
all on-demand and on-access scanners are working different. without going
into too much details, unpacking is one of the main differences. An
on-access scanner is running on the background as a service or daemon and
detects whenever a file modified or created on the system. When it happens
it scans the file. That slows down the computing performance of course which
is annoying sometimes. And if it was even decomposing all ZIP and other
compound formats then it would have slow down the computer even more to an
unusable stage. For example someone downloads a huge ZIP or Installation
file, then it would take several minutes(!) to fully decompose all elements
of it and scan them through with the AV scanner. So simply they do not do
that... That's one of the many reasons why an on-access version might have
different detection rate than an on-demand one from the very same vendor.
On a mail server they might though check if the ZIP contains an executable
just by checking the extensions of the files from the archive header. That
is quick and dirty but effective. If for example there is an EXE in it, then
the MTA blocks the ZIP. They can do that most cases even when the ZIP is
password protected (as most cases the headers with the file and directory
names are not encrypted, only the content of the files). That's why they
might wrap the archive into another archive, so that it could go through the
ail server... Not necessarily by malware but also by angry users who just
want to use their system sending legit files to colleagues...
Also of course bad guys are trying to do everything to push through their
malicious code on the mail server. So they may try to crash the AV scanner
as many times as the can so they hope that the mail server admin gets
annoyed at some point when he/she turnes the scanner off. Even if it happens
only for few minutes the bad guys can have a chance to pushing through their
badware on the system. So yes, they might try to use malformatted ZIp files
as well as 'too deeply nested' ones.
BUT, how does someone accidentally execute a .ZIP file? I don't see
why it is all that bad for ZIP files to get through even if they
contain EXEs which are infected.
I've also found that Gmail seems to take the "quick and dirty"
approach Tamas mentions here - you can't gave any files in the ZIP
file which have an executable extension. This is very annoying because
I use Gmail to back up PCB design files, some of which are .LIB and it
considers that to be executable. Even zipping it several layers deep
didn't fool it. I had to make a script to rename the .LIB files to
On Wed, Sep 15, 2010 at 7:41 PM, Tamas Rudnai <gmail.com> wrote: tamas.rudnai
On Thu, Sep 16, 2010 at 6:41 AM, Sean Breheny <cornell.edu> wrote: shb7
> BUT, how does someone accidentally execute a .ZIP file? I don't see
> why it is all that bad for ZIP files to get through even if they
> contain EXEs which are infected.
Right, so you can't execute a ZIP file unless it is a self extractor (WinZip
installer for example). BUT: Windows Vista and 7 are treating ZIP as it was
a directory, so you double click on it and it brings the file listing up.
Then if there is any interesting file name in it, user can and believe me
will click on it to see what it was. The very very old trick is to use
double extensions, for example "yourphoto.jpg.exe". What happens is that
Windows Explorer hides the extension by default, so it hides '.exe' leaving
the '.jpg' there as that is not part of the extension but then looks like it
is. So user believes that he/she opens a picture file... Other tricks
includes putting an icon that looks like it was a folder - again, user only
would like to open the folder to see what is inside... Or just an icon with
a naked girl so many guys would like to see that anyway :-) Or put a name
like: "AntiVirus 2010" - Called 'antivirus' so it is supposed to be good,
As a moral of it: In all security measurements - not only in computer
security - the weakest link is always the human.
M. Adam Davis
If you password protect your zip files then they won't be scanned by
gmail or most other mail servers. Also, you will likely find that the
7z archive scheme produces much smaller files, and many scanners
ignore it completely (because it's not widely used, so it's not a good
attack vector for malware). 7-zip is a good open source
compression/archive utility that also handles zips, rars, and most
other common compressed files. 7z and rar are comparable in terms of
compression ratio, and both are significantly better than zip.
On Thu, Sep 16, 2010 at 1:41 AM, Sean Breheny <cornell.edu> wrote: shb7
On Thu, Sep 16, 2010 at 10:13 AM, M. Adam Davis <gmail.com> wrote: stienman
> If you password protect your zip files then they won't be scanned by
> gmail or most other mail servers. Also, you will likely find that the
> 7z archive scheme produces much smaller files, and many scanners
> ignore it completely (because it's not widely used, so it's not a good
> attack vector for malware). 7-zip is a good open source
> compression/archive utility that also handles zips, rars, and most
> other common compressed files. 7z and rar are comparable in terms of
> compression ratio, and both are significantly better than zip.
I second either 7zip or Rar. Sometimes I will just rename the
file.zip to file.zip.x and that gets by google at least. Of course,
whoever you send it to has to "open with" or rename it.
More... (looser matching)
- Last day of these posts
- In 2010
, 2011 only
- New search...