That's how I've understood it as well. Secwrap isn't about changing that. Or breaking those rules!
Secwrap is focused on how to hide those aspects of messages as well as the body can't (easily) be accessed by unsavory fellows or handed over to third parties. It does this by encrypting incoming messages (headers and body) using a public key provided by the recipient before storing it (e.g. attachment sent to another email address).
Or in list form.
Email message comes into secwrap SMTP server
Secwrap checks config for public key for recipient.
If key is found, encrypts entire message (headers and body).
Forwards encrypted message as an attachment to another email address or POSTs to a specified url.
Note that the original message sent could be a plain text, S/MIME, have attachments or not, it doesn't really matter.
Of course this doesn't help when the messages are intercepted before it is encrypted. Nor if the sender is using some sort of service like gmail or whatever MS is calling their's these days.
The dead drop enhancement idea is to allow for the sender to encrypt the email message (step 3 above) so secwrap doesn't have to do it itself. The idea of having the sender encrypt the message again with their private key was something to keep out unwanted encrypted messages by requiring "proof" the message was from a specific private key. Thereby allowing the recipient to filter based on knowledge of the sender's key at the server instead of later when offline. (Since the recipient probably wouldn't have the public keys of spammers or other potentially annoying sources the messages.)
Does that help clear up my goal? I'm kind of like Richard in that I can really suck at explaining my ideas.