Autor: W B Hacker Data: A: exim users Assumpte: Re: [exim] Varying message size limit according to sending host?
Jeff Breidenbach wrote: > JB> Specifically, I want to blackhole any messages largerJB> than size
> X, unless the List-Id field is set to A,B, or C in whichJB> case I'd
> like the limit raised to Y.
> DL> Well, he did say 'blackhole', so in the data acl, a discard stanza can
> DL> be added that tests for the size> X and list id != what he's looking
> DL> for.
>
> Exactly. Can I entice someone to provide configuration syntax? My
> current exim4 configuration looks like this.
>
> # Stop large messages.
> MESSAGE_SIZE_LIMIT = 60K
>
> # We want to silently discard large messages, not reject. Thus comment
> # out the following section.
> #.ifdef MESSAGE_SIZE_LIMIT
> #message_size_limit = MESSAGE_SIZE_LIMIT
> #.endif
>
> 2011-10-25 20:02:50 1RItlQ-0004Xi-M1 => blackhole (DATA ACL discarded
> recipients): Message size 3389749 is larger than 60K
>
Blackholing, or any other 'silent discard' scheme has several downsides.
One of them is that MANY 'botnets are too cautious to actually await
re-arrival of a test message probing for an open relay. Something IS
'after them'.
So .. when they see no REJECTION of their sewage, some will assume they
HAVE found a willing victim, even an open-relay, report back to their
master or peers...and you can get a rather nasty pile-on effect within
days if not hours.
IF you do not want to tip your hand with an in-session rejection, THEN
better to do an in-session 'defer'.
Forever, of course...
More workload for all-hands than a clean 'deny'.
But at least you won't attract as many flies as 'blackholing' can do.
Nor confuse your allies *quite* as badly...
A clean in-session 'deny' with appropriate message is still better, though.
And why not do so?
(Potential) allies will know what needs changed.
'botnets will ignore - but eventually move on to pick on easier meat.
No real negatives to being clear, several downsides to hiding..
