Magnus Sundberg wrote:
> ...
> Why not forward one mail to sendmail to userlist@foo.bar 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.
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.
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.
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
> ...
> Why not forward one mail to sendmail to userlist@foo.bar 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.
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.
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.
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