On 2/9/2013 5:23 AM, Titanus Eramius wrote:
> Fri, 08 Feb 2013 21:54:02 +0100 skrev Jeroen Geilman <jer...@adaptr.nl>:
> 
>> On 02/08/2013 06:02 PM, Titanus Eramius wrote:
>>
>>> Feb  7 22:12:48 ntdata postfix/pickup[24843]: 048341743609: uid=5005
>>> from=<SRS0=3u76=L7=gmail.com=jimmiedcu...@nt-data.dk>
>>
>> So you are...not re-injecting spamassassin traffic, but instead 
>> re-submitting it via sendmail ?
>> That's weird.
>>
>>> Feb  7 22:12:48 ntdata postfix/pipe[30177]: 39E441743607:
>>> to=<a...@ubuntudanmark.dk>, relay=spamassassin, delay=0.95,
>>> delays=0.53/0/0/0.41, dsn=2.0.0, status=sent (delivered via
>>> spamassassin service)
>>
>> THIS is a send to spamassassin, but delayed in logging for almost a
>> second.
>>
>> It looks very much as if you're doing in-line spamassassin checks,
>> but then not re-injecting it via SMTP.
>>
>> Why are you doing such a strange thing ?
>>
> 
> To be honest I've read quite a lot about Postfix, Dovecot, SA ... , but
> my experience is very limited and contained to about 3 months of
> running time.
> 
> So SA is integrated as I found best after reading docs and guides, and
> it's more than likely it can be done in a better way. Normally though,
> the running time of SA is around ~200ms per text-mail.
> 
> It's integrated as a content_filter on smtp like so:
> smtp inet n - - - - smtpd -o content_filter=spamassassin
> 
> And then on it's own lines:
> spamassassin unix -     n       n       -       -       pipe
>    flags=Rq user=spamd argv=/usr/bin/spamc -u ${user}@${domain}
>    -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
> 
> The sendmail-method seems to be preferred by the SA-folks
> https://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix
> 
> All of those examples uses sendmail. But again, in relation to Postfix,
> it might very well be possible to integrate SA in a better way. 

Nothing wrong with this setup.  It's very easy to configure,
requires no third-party software or additional packages, and it's
easy to understand where your mail goes.  I expect that's why it's
used as an example on the spamassassin wiki, and doesn't necessarily
mean it's the recommended or preferred method.

It's not necessarily the highest performance or the most flexible,
but if it suits your needs, no need to change.

Folks who need more usually pick some third-party filtering software
that can run pre-queue as an smtpd_proxy_filter or milter. These
are, without exception, more complicated than the setup you
currently have.  The big advantage of a pre-queue filter is you can
safely REJECT unwanted mail.

Amavisd-new is a popular choice for pre-queue filtering since it's
fast, reliable, flexible, and can integrate both SpamAssassin and
antivirus.


  -- Noel Jones

Reply via email to