On Thu, Jul 11, 2002 at 11:51:32AM +0200, Matthias Andree wrote: | Derrick 'dman' Hudson <dm...@dman.ddts.net> writes:

| > | What MTAs "sendmail" commands exit with EX_NOUSER when there is no | > | user? | > | > Why does it need to? | | Reworded: sendmail commands usually take mail in regardless of whether | the user exists,

However, the sendmail commands are run by a valid "sender" (can't be forged like spammers do) and thus a bounce can be delivered properly.

| so the MDA may have to deal with this condition even though SMTP | rejects that mail.

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.

| 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 exim I set up a router that uses a pipe transport to pass the mail to maildrop. I have the same thing set up for procmail, in case a user wants that instead. I simply specify the "pipe" driver for the transport instead of the "appendfile" or "smtp"

| > | Hint: qmail's and Postfix's sendmail wrappers don't. | > | > I just tested -- exim's doesn't either. However, *exim* creates a | > proper bounce message and delivers it to me. maildrop never sees that | > non-existant user. | | With *virtual* users that are only known to maildrop, not to the system? | Call yourself lucky.

Exim knows about all recipients. It won't attempt a delivery unless I explicitly configure it to accept the address. I _can_ tell exim that every possible local_part is valid, but why would I want to to that? Even though I don't personally have a virtual users setup, I still don't see why maildrop needs to know about the virtual users database.

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

| Or can you tell exim to use Maildrop's userdb?

Upon reading the documentation of the format, it would be quite easy to write an expansion which would read the single-file variant (I'm not sure about the multi-file one) and extracts the relevant information so that it can set $HOME, $SHELL, etc. in the environment before execing maildrop. Thus maildrop doesn't even need to read the database itself, since exim has already taken care of it (see below).

| > In fact, I don't really see why maildrop needs to have | > ldap/sql/whatever support in it at all. All maildrop needs is to be | > run as a valid (and the proper) UNIX user on the server, and have | > $HOME set so that it can find ~/.mailfilter and have the right base | > for relative paths. | | 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.

| > The MTA can easily set that environment for maildrop to run in, and | > maildrop wouldn't even need to know anything about the "virtual" user | > database. That sort of setup prevents the need to duplicate user | > checking in maildrop, and puts it where it belongs in the MTA. | | See above.

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?

Do note that I consider maildrop to be an MDA; a separate entity from the MTA and one which really isn't involved in the message routing process, but rather in determining the final resting place. I do not consider maildrop to be a component of the MTA (which it seems you are trying to do with postfix). The TA, not the DA, is the one responsible for determining that a recipient is valid.

-D

http://dman.ddts.net/~dman/