> I've read the page about etrn, and I think the author made some
> mistakes (at least on his first page, I'm saying anything about the
> code).
[snip]
> This solution of etrn relies on the fact that all mail
> should stay in a queue. But why? In a maildir, you've much more
> control about the size (quota) and all, which I think is a feature
> many people appreciate. When mails stay in the queue, it can grow
> beyond your control and crash your own machine. So to summarize: use
> maildir2smtp, not etrn.
That's one part of the truth. The rest is that for
maildir/maildir2smtp you need to know _in advance_ for which domains
you have this feature. ETRN is much more democratic - every domain
for which you have the mail in queue can ask you to deliver it now.
In "normal" setup you probably don't need etrn - the messages in
queue are either outgoing or going to your clients. I can't think of
an example where etrn cuts it more easily than maildir2smtp does but
that probably doesn't mean there is one...
Just my 0.02 whatever.
--
Petr Novotny, ANTEK CS
[EMAIL PROTECTED]
http://www.antek.cz
-- Don't you know there ain't no devil there's just God when he's drunk.
[Tom Waits]
