Mark Rogers wrote:
Handling of errors is minimal, but should leave the message in the
quarantine if undeliverable, so I think my problem is with dspam not
telling me a message can't be delivered when that is the case, but the
whole processing mechanism looks to be using a huge amount of RAM on a
large quarantine (which is probably the root of why things are
breaking for me) and doesn't seem very robust (overwriting the
quarantine doesn't leave a fallback position). However I'm pretty much
learning Perl as I go so I may be getting a lot wrong.
Update on this:
My problem appears to be that the following
# dspam --deliver=innocent --class=innocent --source=error --user
[EMAIL PROTECTED] -d %u < tmp.eml
# echo $?
.. always returns 0 error code, but does not always deliver the email.
It seems at the moment to consistently fail to deliver old email
(several months old) but does deliver new email (last couple of days) so
I guess the problem is something to do with data having expired in the
database, but even so it would be useful to know that through an error code.
Is there a way I can force dspam to deliver tmp.eml?
The logs (syslog) show:
Jul 22 18:42:21 moresaa5 dspam[5656]: Signature retrieval for
'47874562327015553915946' failed
Jul 22 18:42:21 moresaa5 dspam[5656]: Unable to find a valid signature.
Aborting.
Jul 22 18:42:21 moresaa5 dspam[5656]: process_message returned error
-5. dropping message.
--
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555
Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG
!DSPAM:1011,48861c4c150928593137770!
