I believe that you are glossing over the distinction between the MTA and the MDA, and ignoring an important question: who is in charge of accounts? The answer on most systems is that /etc/passwd is in charge of user accounts. On some systems, it is the NSS switch.
In any event, you are looking at *system level accounts* which is exactly not what DBMail is intended to support. More comments inline... Aaron On Thu, 24 Apr 2003, Blake Mitchell wrote: > Magnus Sundberg wrote: > > > ... > > Why not forward one mail to sendmail to [EMAIL PROTECTED] and then let > > sendmail do the list expansion, by looking up the alias from the > > database instead of /etc/aliases. I beleive this is one of the tasks > > sendmail is written for. > > ... > > This is a very good point, and I think it deserves further > consideration. Why is dbmail handling aliases? That is a job for an MTA, > not an IMAP/POP server. > I believe that you are underestimating the amazing pain that you wish to inflict upon yourself by forcing the MTA to become intimately involved with ephemeral aliases. For such accounts as root, postmaster and webmaster I would prefer if those were only found in /etc/aliases, but for John Doe who left the company but you're nice enough to forward his old account to him for a few months, /etc/aliases? I say no. Under your proposal, either all users must have system accounts and we're wasting our time with a system that allows 'virtual' email accounts, or the MTA must be able to support virtual accounts. Most MTA's don't do this out of the box, e.g. Sendmail and Postfix. Those that do support virtual users directly also have their own mail stores and IMAP and/or POP3 servers, e.g. Courier, Cyrus and qmail. > The current implementation of dbmail-smtp is actually an MTA, (even > though--ironically enough--it's not an smtp server). It does what all > other MTAs do: receive a message, look up the proper recipients, deliver > the message. I'm sure the original thinking was: we need to keep our > aliases in the database, so we're going to have to write something that > can do the lookups for us. The problem with this strategy is now > becoming evident, we have to handle bouncing messages, adding headers, > mail loops, forwarding to external software, resource constraints, etc. > DBMail is the 'back half' of the MTA -- the MDA, Mail Delivery Agent. You are correct that DBMail does *some* of what other MTA's do, but with a distinct difference: it only takes input on stdin. The 'front half' is an actual MTA that speaks SMTP and can run out on open Internet. It does the work of communicating with hosts sending mail to it, and collects mail on the system to send it out to other hosts. It knows how to stop mail loops and how to add headers. DBMail does not add headers, expect for one that is expected by programs that expect mbox style input. I would not dignify this as anything more than a compatibility hack, certainly not 'adding headers' in its full sense. > I say we should get out of the MTA business, there are already too many > of them as it is. The best part is, we give up nothing, and gain so > much. dbmail-smtp would simply become an injector (and hopefully be > renamed), the userse/mailboxes specified explicitly. You could even > still use the same dbmail aliases table we have today, postfix seems > quite happy using it from what I've gathered from the mail list. I know > there are other MTAs that (can) use a database for aliases. Or you could > use something completely different, it wouldn't matter because dbmail > would never interact with it. The problems of pipes and resource limits > would be gone, because dbmail would never send mail, ever. There would > be no cause for it to do so. dbmail-mini-injector does exactly as little as you are requesting. > > > Here is what I see as the three big gains from this strategy: > > 1. dbmail as a whole is simpler and smaller, that means less bugs. > > 2. Aliases are handled by a full featured MTA, whichever MTA the admin > finds most appropriate for their situation. > > 3. Since we don't have to put any effort into coding an MTA, we can work > more on the IMAP/POP servers to get the features we want there. > > > This reminds me of point 12 from ESR's "The Cathedral and the Bazaar": > http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s07.html > where he discovers that fetchmail is better software without all the > local deliver options, because there is already good software in place > which handles that. > > > Comments? > > Blake > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
