Hello Reindl
>>> after a bit of reading on the project site, there is one thing, i see a
>>> little bit critical:
>>>
>>> On the "about" page there is a "Simple Setup" example. In this you describe:
>>> - Postfix accepts and receives (or rejects) the mail and delivers it to
>>> the Detective.
>>> - The Detective might reject the mail, which will force postfix to bounce
>>> it, or passes it again and re-inject it into another postfix process.
>>>
>>> I i understand this right, postfix would bounce the mail after it was
>>> accepted for delivery. This would cause backscatter.
>>> And a backscattering spamfilter is as bad as a real spamserver.
>>
>> Ok, that was not lucid, i agree. I clarified this on the about page,
>> respectively left it the reject-part out to prevent misunderstandings.
>> However, the Detective server actually can bounce the mail, if he is
>> configured to do so in the spam.handle directive. There are four different
>> handlers:
>> 1) tag: Default handle. Mail will be tagged (with a X-Decency-header and
>> possibly a Subject-header prefix, if configured).
>> 2) ignore: Nothing happens to the mail. For testing (and log analysis).
>> 3) delete: Mail will be silently deleted. I clarify that this is not a good
>> idea in the docu. However, there is the possibility to send a mail to the
>> recipient ("You received SPAM, we deleted it").
>> 4) bounce: The recognized SPAM mail is bounced back to the sender. The valid
>> scenario for this is an outbreak-prevention mailserver in which the sender
>> wants to know whether the mail he send himself would be recognized as SPAM.
>
> but none of the cases REJECTS spam-mails
> the spamfilter has to answer with 5xx to the sending serverThere are two servers involved: a policy server called Doorman which can reject mails via 5xx or 4xx codes, because it is implemented in the restriction classes. The second server is a content filter called Detective, which comes into action after Postfix has received the mail fully (including everything after DATA), so it cannot reject any mail via any SMTP response code anymore. > 1) and 2) does finally nothing > 3) MUST NOT happen > 4) SHOULD NOT happen The above listed handlers and the cited about-text are in the realm of the content filter (Detective), so they take care about what happens when the mail already has been received (and a 250 has already been sent). The third case (delete) is course expessivly discouraged in the docu but still possible. In the end, the idea of Decency is that you can extend it easily with your own (Perl-written) modules. You (as the admin using Decencyg) could write a delete-handle-like module in under 10 lines, if you wish to. Having this as a configurable handler, i can at least talk about it and the negative effects. The fourth case (bounce) is valid, if you setup a content filter on a mailserver, which you use for outgoing mails in an outbreak-prevention scenario. Here you goal is to filter your own outgoing mails for SPAM, so you a) can be sure (at least with a higher probability), that your mail will not be recognized as SPAM by receiving mail servers (because they are going to use probably quite similar SPAM filters as you do) and b) get informed, if you got a zombie client on your side, which tries to send SPAM. You can however, misuse this and configure a backscatter server. I hope to address this in the docu might be more helpful than not talking about it and the admin implements it himself without having thought about the problems.. Thanks for that, i try to extend the docu further, so it becomes abandonly clear on when and how you might use those handlers - and when not. Greets Ulrich -- Blog http://blog.foaa.de/ ICQ 315125501 Skype ulrich.kautz GTalk ulrich.ka...@googlemail.com PGP 0x8089C888
signature.asc
Description: OpenPGP digital signature
