On 5/9/2014 1:24 PM, Eric Shubert wrote:
> On 05/09/2014 11:19 AM, [email protected] wrote:
>> Are you sure that both .qmail-default and .qmail are not used in the
>> delivery process? I'm seeing each email processed by both files as each
>> email has a dspam tag (.qmail-default) and also is logged by maildrop
>> (.qmail).
>>
>> That said, I do have the servers set up to do the test you suggest.
>>
>
> I wouldn't bet my life on it, so no I'm not positive. It doesn't make
> sense to me though that both would be invoked. So much for making sense.
>
> Upon further review, it appears to me now that you're correct. The
> domain's .qmail-default is used first, invoking vdelivermail, which
> then must invoke the user's .qmail file if it exists. I need to do a
> little more digging in the source to see what's really going on.
>
> In the meantime, can you do a little more testing? I'm guessing that
> the attachments are making it to the queue and they're being dropped
> during delivery. Can you verify this? We'll simply need to track this
> thing through the various stages to see where the problem is.
>
> I'm guessing the problem is between dspam and vdelivermail. That's
> just a guess though.
>
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
