I don't think there is any "Delivered-To" header yet, because the message never gets delivered -- it's just repeatedly relayed (from the server to itself). The hostname in the address is not in rcpthosts or locals, so there's no delivery.
Almost exactly right: the hostname in the address can be in both rcpthosts and locals (of one of the boxes involved) and still loop. In one example I have saved off, the spammer sent a mail to:
<[EMAIL PROTECTED]>
which is the FQDN of one of my inbound MX boxes (obviously ;-). The problem is that qpsmtpd pays attention to locals/rcpthosts *only* for purposes of determining whether to accept the message, not how to deliver the message. So in my case, the message was accepted, sent via QMQP to the host responsible for rlpgbooks.com; said host then decided it wasn't the final delivery agent and sent back to the original box:
Received: (qmail 32639 invoked by uid 107); 6 Apr 2005 12:11:48 -0400
Received: from unknown (12.38.22.1)
by ranger1.rlpgbooks.com with QMQP; 6 Apr 2005 12:11:48 -0400
Received: from ranger1.rlpgbooks.com (HELO ranger1.rlpgbooks.com) (12.38.22.130)
by a.mx.rlpgbooks.com (qpsmtpd/0.29) with SMTP; Wed, 06 Apr 2005 12:07:27
-0400
Received: (qmail 32486 invoked by uid 107); 6 Apr 2005 12:11:30 -0400
Received: from unknown (12.38.22.1)
by ranger1.rlpgbooks.com with QMQP; 6 Apr 2005 12:11:30 -0400
Received: from ranger1.rlpgbooks.com (HELO ranger1.rlpgbooks.com) (12.38.22.130)
by a.mx.rlpgbooks.com (qpsmtpd/0.29) with SMTP; Wed, 06 Apr 2005 12:07:09
-0400
...on and on until the heat death of the universe or the machine runs out of memory or the CPU explodes in fragments of silicon or more likely, I notice that the load is over 10 and figure out something is amiss...
Granted this was a misconfiguration on my part; adding
@a.mx.rlpgbooks.com
to config/badrcptto fixed the looping problem for me (since those boxes have no local accounts at all). It's not the only way a loop can be constructed, but it is a useful test point since I can clear the above file and trigger it at will. ;-)
Without qpsmptd, this would be stopped by the loop-detection code in qmail-smtpd, which is based on counting the "Received" headers. If qpsmtpd is supposed to be a replacement, it should do that function of qmail-smtpd.
I'll get around to this at some point I expect, but I wouldn't be averse to someone just ginning up a simple Received: header count patch until I can come up with the time to craft something smarter...
John
