[Dovecot] Dovecot aspects of fighting spam

[Phil Howard]

On Tue, Jun 1, 2010 at 12:17, Stan Hoeppner <stan at hardwarefreak.com> wrote:
> Phil Howard put forth on 6/1/2010 9:15 AM:
>> On Tue, Jun 1, 2010 at 10:04, Jerry <dovecot.user at seibercom.net> wrote:
>>
>>> The fight against SPAM is NOT Dovecots responsibility.
>>
>> Whose responsibility is it to get detected spam delivered into the
>> correct folder?  Dovecot deliver is typically used to deliver into the
>> Inbox(es).  It would be involved.
>
> It's the MTA's responsibility to _REJECT_ spam attempts at SMTP time.  It's
> the mail OP's responsibility to properly configure the MTA to do so.  Spam
> fighting should be performed pre queue, not post queue.
>
> I suggest you bone up on modern spam fighting techniques.  Post queue content
> analysis is not the proper way to fight spam, especially in 2010.

For my own personal server, I would agree.  Even for a general email
or freemail service I would agree.

However, for certain business environments, even a few false positives
can be very troubling to management.  Greylisting, and with shades of
grey, is often more appropriate.  Given that this puts mail where it
will likely never be read or responded to, certainly doing as much as
you can at SMTP time for a 5XX rejects is preferred, so that
legitimate mail that would otherwise not be responded to is known to
be not delivered where it would be read.  But this can't be for
everything, as even a FP rate of 0.01% is too much.

So in the end, there has to be an administrative policy decision as to
what to do with what is detected as spam.  And if I can find a way,
I'd like to even set that up so end USER policy can be applied even at
SMTP time (e.g. user decides if spam is blacklisted or greylisted,
along with user specified whitelists).  But that's pushing the
boundaries for now.  When I get time, I will look into that degree of
control.