The MTA *still* won't deliver to a non-existant recipient. Instead of attempting a delivery, it will bounce the mail with an "address unroutable" message.

| Bounce proxy flooding cannot happen this way because the user could | just send direct mail instead.

I'm not sure what bounce proxy flooding is.

| With "mailbox_command=/usr/bin/maildrop plus options here", it's fine | with Postfix also, but that way, it won't work for virtual users (the | local(8) transport does not do this). With Postfix, you'd then have two | choices: use the virtual(8) transport, which is ultra-safe, but does not | support filtering or .forward, or use maildrop(8) as new transport, | which requires maildrop to return EX_NOUSER. (And yes, Postfix supports | rejecting mail for users outside virtual_mailbox_maps at the SMTP port, | but not at the sendmail port).

Ahh, I see your problem. It's not that maildrop isn't a correctly functioning MDA, but rather it isn't a correctly functioning _postfix transport_, which requires a different interface.

| > It is simply a matter of configuring exim (or $MTA) properly, and then | > maildrop will never see messages it isn't supposed to be seeing. | | Depending in your needs, that simply won't work out.

exim has support for ldap, postgresql, mysql, dbm, cdb, "lsearch", and other databases. Choose your poison :-).

| This is needed for virtual mailboxes delivered to virtual users. Virtual | users are not known to the Unix OS.

Every UNIX process is run as some UNIX user.

If maildrop is run as the user 'mail', and $HOME is set to, say /usr/local/mail/virtual/<domain>/<local_part>, then maildrop will look for /usr/local/mail/virtual/<domain>/<local_part>/.mailfilter as the filter file. maildrop would be happy, then, and not care that $local_part isn't a UNIX user. Alternatively, couldn't one just specify which filter file to use on the command line?