postfix: conditionally ignoring certain "User unknown in virtual mailbox table" errors when using a milter

The right-hand side of a check_sender_access lookup in a smtpd_*_restrictions list can in turn contain named conditional restrictions (documented in the RESTRICTION_CLASS_README file). This means if the criteria for rejecting messages to unknown recipients is solely‡ dependant on the rfc5321.MailFrom ("envelope sender"), then moving the reject_unverified_recipient statement from a the smtpd_*_restrictions list itself, into a sender-dependant lookup should do the trick:

# OLD (example, you get the idea)
smtpd_recipients_restrictions =
    reject_unauth_destination,
    reject_unknown_recipient_domain,
    reject_unverified_recipient

# NEW (just a single replacement, adapt to your OLD version)
smtpd_recipients_restrictions =
    reject_unauth_destination,
    reject_unknown_recipient_domain,
    check_sender_access pcre:/etc/postfix/maps/no-recipient-lookups.pcre

# /etc/postfix/maps/no-recipient-lookups.pcre
/.*@example.org/   DUNNO
/./                reject_unverified_recipient

For each listed sender (or any other single check_*_access condition), this skips the "Does this recipient exist?" check, and for all other senders, it will enforce that check.

Now, this whole exercise pretty much only makes sense if you are later unconditionally reject any messages receiving this special treatment, because what is postfix going to do with messages it should have already checked earlier that it won't be able to deliver them. You should never emit non-delivery reports in cases where SMTP-stage rejections would have been possible. If your milter only needs the message headers (as your use case of investigating abuse suggests) you may be able to guarantee this by adding the unconditional restriction also in the smtpd_end_of_data_restrictions list (expect of minor performance implications in case this 2nd lookup races with the address verification process).

‡ If not, you can implement the decision of whether the special case is applicable in a check_policy_service, which lets you more complex decisions then a simple (or regex) lookup on the sender, e.g. you could parse the rfc5322.From (headers indicating sender) there. The only difference is, that instead of writing two lines of no-recipient-lookups.pcre file, you have to write/adapt and run a policy daemon that returns the reject_unverified_recipient result, analogous of how your Milter currently return SMTP status codes.