Thank you for taking the time to help!
I should have specified that before, sorry. Checking the postqueue and flushing any messages inside of it was the thing I did right after fixing /dev/null.. But the missing mails weren't there.
In addition, the weird thing is, I'm using maildrop as mailbox_command in postfix/main.cf instead of procmail, however, two users are using .procmailrc filters. So the errors reported by procmail via mail.err could be related to those users only and I probably must look into maildrop mail handling/ error handling for more insights... The only other error I get is the (probably inoffensive?) "imapd-ssl: /etc/courier/shared/index: No such file or directory"
From the procmail manpage I understand that when encountering issues, procmail should store the mail in the default system mailbox. I'm not so sure about maildrop and I remember maildrop debugging being a pita..
Also, it looks as though only non-virtual users were affected by the problem while all virtual users weren't... And that is weird. Not knowing enough about postfix/ clamsmtp/ spamd/ master/ etc interaction, I'm a bit on the defensive side atm.
What surprises me most, is that while debugging the error, NO log-information whatsoever was written to the logfiles upon sending from a "bugged" account. From a user perspective it looked as if the message was delivered (no mailer daemon errors) though it never got to the intended recipient (local or remote afaik).
I might just wait until next maintenance cycle, reintroduce the bug and debug further to find out what was going on. Atm, I'm quite lost and think the mails got lost just as well...
I'm not sure above info will help with finding the mails again, so sorry if anything in here is unessential. I will let anyone know if I find out what went wrong where. Of course I'm open to any propositions.