I think I found it!
For several years, the Parallels Plesk Panel, running Postfix, has been plagued with a problem where the server suddently starts sending out a rather useless error message:
-----------------------------------------------------------------
Transcript of session follows.
Out: 220 xxx.yyy.net Postfix (Ubuntu)
In: EHLO exprod7mo102.postini.com
Out: 250-xxx.yyyt.net
---snip---
Out: 250 DSN
In: MAIL FROM:<xxxxxxxxxxxxxxxxxx> SIZE=1038
Out: 250 2.1.0 Ok
In: RCPT TO:<xxxxxxxxxxxxxxxx>
Out: 250 2.1.5 Ok
In: DATA
Out: 354 End data with <CR><LF>.<CR><LF>
Out: 451 4.3.0 Error: queue file write error
In: QUIT
Out: 221 2.0.0 Bye
Session aborted, reason: lost connection
-----------------------------------------------------------------
My observations indicate that this is coming from the Postfix "Before Queue Filter."
http://www.postfix.org/SMTPD_PROXY_README.html states, among other things, "For privacy reasons, all the remote SMTP client sees is "451 Error: queue file write error". It would not be right to disclose internal details to strangers."
The Postfix before-queue content filter, when running under Plesk, is /usr/lib/plesk-9.0/postfix-queue. This is true even in Plesk 10. postfix-queue is a compiled binary and offers no help. It's job though is pretty well outlned in the SMTPD_PROXY_README file mentioned above.
In this case, the filter is returning 451 queue file write error, which is what postfix specifies in the readme, but the definition of a 400 series error is that it's temporary, and that the sender should retry. So it does.
I removed the before-filter from one of my servers, and one of the messages that had been retrying over and over again then delivered. I was able to get a look at it. What I saw was a little message with a binary mime attachment, clearly spam or malware. The content-filter was quite right in refusing it.
This would be cured if the postfix-queue program would return a 500 series error on the message. After all, the content filter isn't going to accept it next time around, so why retry it.
Anyway, the only solution that I see for us at the system administration level, is to remove the before-content-filter. This is accomplished by editing /etc/postfix/master.cf as follows:
Find this line: smtp inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025
remove everything after smtpd. (remove the -o and what follows)
Then restart postfix with /etc/init.d/postfix restart (or similar)