full-disclosure - Administrivia: Testing Emergency Virus Filter..

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: madsaxon at direcway.com (madsaxon)
Subject: Administrivia: Testing Emergency Virus  Filter..

At 09:43 AM 8/20/03 -0500, Schmehl, Paul L wrote:
>I would go farther.  SMTP was never designed as a file transfer
>mechanism, and it should not allow file transfer.  This would solve both
>the problem of email attachment viruses *and* the scourge of the
>Internet, HTML email.

I concur completely.  I've been preaching a similar gospel for
many years; to wit, that we've been employing SMTP in a manner for
which it was not designed, and we're now paying the price for that
misuse.  MIME and similar initiatives were well-intentioned, but
fundamentally they're still little more than kludges.

I was the manager of a large (18,000+ users) email system back in
the 1997-98 era, when it first became de rigeur to attach cute
binaries and, more insidious, Powerpoint presentations to emails.
I can't tell you how many times I had to reset the SMTP queue at
3:00 AM because it contained 1,000 copies of "rudolph.exe" or
some series of 500 slides from a conference sent to an "all-user"
mailing list, the vast majority of which were simply text on a
colored background, anyway.

I can't see any immediate solution to this problem, however.
We've painted ourselves into a corner by trying to adapt SMTP
to FTP, rather than enforcing implementations that respect the
protocol's original purpose. That way lies madness, as well as
long-term frustration.

m5x