Re: [Exim] W32.Swen@MM

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Alan J. Flavell
Date:  
À: Exim users list
Sujet: Re: [Exim] W32.Swen@MM
On Sat, 20 Sep 2003, Robert Kehl wrote:

[quoting me:]
> > already set ours to 50k, but eventually I suppose we'll have to scan
> > the entire mail, even if it _is_ a couple of terabytes and takes
> > days to scan...)
>
> Ah, I see. But, Alan, you don't have to feed terabytes if you don't
> allow them to be received.


(It was clear, wasn't it, that I was deliberately exaggerating?)

> Set your mail scan limit as high as an email
> may be which arrives at your system(s).


Some of our users don't seem to be able to be persuaded to desist from
sending tens of MBytes or more, no matter how often one suggests to
them that it is more effective (and safer) to put their material on an
unlisted web page, and send its URL to the recipient[1].

If we're lucky, the recipient MTA will reject their mail as being too
large anyway [fx: evil chuckle]

> Ie. If you'd only allow 10 MB mails, or say: 50Mb you'd never scan
> more than that.


That's true, but it's still a lot more work than scanning the
first 50k only.

Seems to me that for the purposes of the current risk factors, we
could go a fair way to mitigating the risk if the scanner would simply
break-out the MIME parts (should be fairly cheap, compared with
actually scanning the whole content at the full strength of the
scanner), and then scan the beginning of each part.

Caveat: we _SHOULD_ be able to discount uuencoded snippets being
smuggled into the middle of plain texts in MIME-encoded mails: IMHO
the presence of a MIME header declaring content to be text/plain
should ipso facto rule-out the presence of uuencoding - only mails in
pre-MIME formats should be eligible for uuencoded content, as I
interpret it. UNFORTUNATELY, we know that the most-vulnerable client
software comes from a vendor who evidently believes that a MIME type
of "text/plain" means "client software should make a wild guess",
contrary to the RFC definition of text/plain, and so, sadly, all bets
would seem to be off.

In the end, I guess it may need a lightweight scan of the whole thing
for vulnerabilities, in conjunction with a more-extensive (a la
spamassassin) scan of some part of it for anti-spam protection.

all the best