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..
Bill
--
韓家標
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
