Le 06/01/2011 00:48, Karsten Bräckelmann a écrit :
> On Thu, 2011-01-06 at 00:27 +0100, mouss wrote:
>> Le 05/01/2011 02:15, Karsten Bräckelmann a écrit :
>>> On Tue, 2011-01-04 at 00:58 +0100, mouss wrote:
>
>>>> Recipient unknown................: 5318 ( 73.85 %)
>>>> DNSBL zen.spamhaus.org...........: 816 ( 11.33 %)
>>>
>>> This alone tells some facts about these stats. For one, they are
>>> gathered from all SMTP delivery attempts. Usually, on this list, stats
>>> for BL performance are relative to mail that otherwise would have been
>>> accepted without SA. Which in every case but the most pathetic does not
>>> include unknown recipient rejections at all.
>>
>> My understanding was that OP asked about smtp time rejections.
>> obviously, this won't check received headers, nor junk from yahoo/gmail/...
>
> That was my understanding, too. My point though was, that given a sanely
> configured server without SMTP rejections based on BLs, the expected
> difference will be nothing like the numbers above.
>
> Current spam stats for such a server usually will be based on the SA
> results, totally ignoring unknown recipient rejections, which happen way
> earlier. In that case, ZEN will make a difference of rejecting 80% or
> more -- based on the number of mails previously processed by SA, after
> the most basic SMTP rejections. Not a mere 11%...
>
sure. it was not my intention to show comparative results nor global hit
rates. so it by no means tells that zen catches 80 times as much spam as
BRBL for instance (if BRBL is moved before zen, the relative ratios will
be completely different).
Anyway,
- OP should start with only a few checks and only add other checks if
the value they bring is worthwile to him.
- in postfix, place
reject_unlisted_recipient
reject_unlisted_sender
soon enough in the checks, so as to reject as much junk as possible
before querying lookup maps or dns based tests. of course, this is only
helpful if you don't have catchall addresses.
and regarding check ordering, some rules of thumb:
* safer rules should come before. this way, false positive analysis
takes less effort
* cheap rules come before more expensive ones.
* optionally, try to be helpful to the other side (assuming legitimate
senders or relays). For example, a legitimate relay operator can look at
the "unknown user" errors and detect an infection or a violation. also,
there's no point to tell the other side "rejected because your helo
looks ugly to us" then have him change his helo just to discover a
"rejected because your IP is in wrong country/network/place"...
> [snip]
