Charlie Brady wrote:
Which in turn could only be inappropriate response to a TERM signal - there's nothing magical about 'svc -t'.
$SIG{TERM} is bound to &huntsman in forkserver; if there was some problem with that code, it might not be cleaning up correctly. Looking at the timestamps on some servers where I cleaned out ./tmp/ recently, there is no relation to when I might have restarted qpsmtpd.
My next SWAG is that the undeleted files are exclusively from the cases where the remote MTA ended the connection prematurely (or timed-out). This would seem to bear out the contents of the files I find, which frequently include only headers, or maybe part of the message body but it ends in the middle of an HTML tag (for example). I'm going to need to catch this happening so I can check the logs for details...
I'm struggling to think of any case where qpsmtpd needs to preserve content. The content is always available elsewhere - either in the backend, which has acknowledged receiving it, or in the sender's system, which will keep it for resending until it receives a permanent status code. Or both, if the backend has provided a response which hasn't yet been relayed to the sender.
Personally, I sometimes like to save copies of virus infected messages which were only caught by the second scanner and not the first. I like to submit those to the primary AV package so that they can add the signature to their next update.
I think I'll replace our File::Temp Lite code with the real thing and see whether that works better.
John
