Derrick 'dman' Hudson <dm...@dman.ddts.net> writes:

No, read closely: Sam says that a MDA's task is to tell the server that the account does not exist. However, maildrop cannot tell the server that without my patch. That means: Sam just said that maildrop is only suitable to be called FROM an MDA, not to replace one.

Reworded: sendmail commands usually take mail in regardless of whether the user exists, so the MDA may have to deal with this condition even though SMTP rejects that mail. Bounce proxy flooding cannot happen this way because the user could just send direct mail instead.

It just depends if the MTA directly queues into maildrop, with maildrop replacing the original local delivery agent for efficiency, or if you configure a "global .forward" that tells the MTA's MDA (local(8) for Postfix) to use maildrop unless the user specifies otherwise.

With *virtual* users that are only known to maildrop, not to the system? Call yourself lucky.

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).

Depending in your needs, that simply won't work out. Or can you tell exim to use Maildrop's userdb?

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

See above.