Author: Alan J. Flavell Date: To: Exim users list Subject: Re: [exim] Continuing Exim 4.60 & SpamAssassin 3.1.0 Problems
On Fri, 13 Jan 2006, exim-users@??? wrote:
> There's no need to check whether a 1 MB message is spam.
I can't really confirm that diagnosis. Practically all messages >=1MB
which get to *me*, I would categorise as spam[1], but, across our user
population, there are both spam and non-spam mail items of quite
remarkable size.
I agree with your conclusion that things get nasty if you routinely
feed the whole content of such mails to SA, but that doesn't mean
there's "no need to check" such items. For large mails, we've been
tending to rely on some outright blocks (e.g looking up the offering
IP in some reliable dnsRBLs) that take effect prior to the point where
SA would have been invoked.
There might be something to be said for feeding manageable parts of a
large mail to SA. Quite a few spams which got past the IP blocks
consisted of a modest sized SA-rateable HTML-only textual content,
with a dumpster full of image attachments. But I haven't actually
tried doing that - I'm only commenting on it as a theoretical
possibility.
[1] The kind of people who correspond with me, understand that the
best way to communicate large documents is to put them on their web
server and send me the URL.
> We are only feeding messages smaller than 250KB to SA and haven't
> had any problem with SA timeouts yet.
Certainly it's unwise to spend too much time noodling around before
responding to the peer MTA after its end of DATA. Indeed this can
result in duplicate transmissions (as you obviously know, and as the
RFCs indicate).
Some versions of SA have been seen to go into orbit with even quite
small documents in certain bug situations; but this is something which
can be recovered from, and - if the timeouts are set reasonably - it
should be possible to respond to the peer MTA before it's too late.
