I have a situation that may or may not be qpsmtpd related though I'm only seeing it in my qpsmtpd implementations. These are typically not spam but legit folks doing legit things.
I receive the DATA segement and then go on to process with SA and clamav only to forward through a smtp_relay hook to a "real" MTA. The sending MTA is dropping the connection somewhere along my processing (likely due to a timeout) but I'll continue delivering the email complete with a "250 Queued" in my log. They'll come back some time later and hand me the same email again. The sender's MTA will pass back a "can't deliver" message in each pass of their spool as well. We're looking at about a minute from the time I've received their whole DATA until I have the email queued on my relay. Shouldn't they really wait for me to respond? I've debated creating a potential for a black hole by instantly responding with a 250 Queued even before I've run it through the scanning. The black hole would come if my inside relay were down or some network issue. I'm not convinced this is the right solution. I'm not running an MTA on my qpsmtpd servers and I've debated spinning up one, but I don't think this would "fix" the problem either. Has anyone seen this before with qpsmtpd or with an MTA? Maybe there's a way I can pick up that they closed the socket before I finish each hook or queue to the relay? Thanks for your thoughts, peter
