On 7/17/2014 9:38 AM, Eric Shubert wrote:
> On 07/16/2014 07:34 PM, Eric Broch wrote:
>> Update:
>>
>> I think you were correct in the last statement of the above email,
>> EricS.
>>
>> I've found a workaround for this issue, if anyone cares, as DSPAM MAY be
>> on the ropes, though, I'll use it for as long as possible. Make the call
>> to dspam in the .mailfilter file instead of the .qmail-default file. Use
>> the 'xfilter' call like so:
>>
>> exception {
>> xfilter "/path/to/dspamc --user $EXT@$HOST --deliver=stdout"
>> }
>>
>> I've had it in place for a couple days and clients have reported
>> delivered attachments where once there was failure.
>>
>> EricB.
>
> That's interesting.
>
> I expect that when we implement dovecot's deliver lda that it will be
> able to handle dspam ok for you. Even though we might not make dspam
> part of the stock QMT, I hope to people will still be able to use it
> if they choose. Who knows? Maybe someone will step up to support it at
> some point.
>
> This makes me wonder if we might need to keep maildrop around as a
> bridge to dovecot's deliver in order to implement that. I certainly
> hope not. Seems like a wasteful step.
>
> Anywise, thanks for your work on this, EB. :)
>
I have a query into the dovecot user's group concerning the
implementation of 'any' spam filter, including DSPAM, in the dovecot-lda
process as their site does not make it obvious to me how to do it.
I've found a source for Maildrop (standalone) in the event it is no
longer supported by QMT and in the interim:
1) wget
http://dl.atrpms.net/el6-i386/atrpms/stable/atrpms-repo-6-7.el6.i686.rpm
2) rpm -Uvh atrpms*.rpm
3) yum install maildrop
I've thought about wading into the DSPAM code myself as it has worked so
well for me, and still is.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
