Make dspam able to tell postfix to hold on to mail when delivery issues occur so that it doesn't bounce. return EX_TEMPFAIL for example if it can't communicate with the delivery socket, instead of 255 error code. From the email with Steve...
"> So what I'm hoping for is an error code exit that postfix would
> > interpret as, try again later. It seems that this should be possible
Yes. That would be possible. Most MTA's obey the error codes defined in sysexits.h:
#define EX_USAGE 64 /* command line usage error */
#define EX_DATAERR 65 /* data format error */
#define EX_NOINPUT 66 /* cannot open input */
#define EX_NOUSER 67 /* addressee unknown */
#define EX_NOHOST 68 /* host name unknown */
#define EX_UNAVAILABLE 69 /* service unavailable */
#define EX_SOFTWARE 70 /* internal software error */
#define EX_OSERR 71 /* system error (e.g., can't fork) */
#define EX_OSFILE 72 /* critical OS file missing */
#define EX_CANTCREAT 73 /* can't create (user) output file */
#define EX_IOERR 74 /* input/output error */
#define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */
#define EX_PROTOCOL 76 /* remote error in protocol */
#define EX_NOPERM 77 /* permission denied */
#define EX_CONFIG 78 /* configuration error */
So to have Postfix (or another MTA) retry we would need to return EX_TEMPFAIL. Currently DSPAM returns various error codes but there is no interface exposed to the DSPAM operator to influence the codes returned. I could imagine that we could add such a capability to DSPAM and allow to control from within dspam.conf what to return under what condition.
Some stuff is already inside DSPAM and would only need to be extended. But I can tell you now that for DSPAM 3.9.0 this will not happen as we are currently in a feature freeze. Might I suggest to you to add a feature request into our tracker so that we could consider adding that functionality into DSPAM after releasing 3.9.0?"
Log in to post a comment.