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).
Maildir2smtp does NOT require a seperate queue to be created: you just let
the mail be delivered at a normal mailbox, and when the person connects
using POP3, maildir2smtp starts delivering mail to that ip address.
This is a great advantage for when you're using dynamic ip addresses: you
don't always know which ip address a client gets.
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.
> ----------
> From: Andrew Spencer[SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, March 17, 1999 9:44 PM
> To: [EMAIL PROTECTED]
> Subject: ETRN, qmail-1.03 and etrn patch v0.1f
>
> This is the first time I've posted to the list, so if I've missed
> something, kindly let me know...
> I checked the FAQ but didn't find anything...
>
> This is concerning the etrn solution I found at this URL:
> http://www.cqc.com/~pacman/projects/qmail-etrn/
>
> I am currently using a P90/Redhat 5.2 test station using qmail-1.03
> installed via the memphis rpm's.
> (qmail-1.03-11ucspi.i386.rpm, based on a src rpm)
>
>
> I then compiled the qmail-1.03, patched with etrn diff v0.1f on another
> test station also running Redhat 5.2 and the memphis 1.03 rpm.
> (only have a limited HD on the testing station)
> Compared the binaries from my existing /var/qmail/bin to qmail-1.03/ and
>
> moved in the changed binaries...
>
> Restarted...
>
> Took a bit to get the permissions on etrntrigger and
> /var/qmail/queue/lock/tcpto but it appears to be working...
>
> The etrn command is received and says ok....
>
> But I'm not seeing an "instantaneous" outflow of held mail... I use
> qmHandle -l to see what's sitting in the queue, and I have the test mx10
>
> go offline, watch the mail pool by watching for deferrals in the wmail
> log, and then I bring it back online and issue the etrn command via port
>
> 25... 250 ok...
>
> But no outgoing mail traffic... In amount 5-10minutes it will starting
> spooling out and everything is fine...
>
> The only thing I can think of is the patch isn't quite right... I have
> noticed that nothing shows up in qmail-tcpto but I've gotten varied
> results in regenerating qmail-tcpto tables for specific IP address on
> "unmodified" qmail installs... I can see healthy qmail-tcpto responses
> on our outgoing mail server, but everytime I trick it into holding email
>
> a specific IP using static mail routes I don't see it show up in the
> qmail-tcpto tables...
>
> Is 5-10 minutes response from an ETRN, in this configuration normal or?
> Any checks I can make to make sure that tcpto "tables"(?) are working
> ok...
>
> I have attempted to find other ETRN solutions, and have found mention of
> AutoTRN(?) but can't find anything concrete on it....
> If you have URLs or leads on an ETRN package you can email me
> directly...
>
> Any input would be greatly appreciated...
>
>
> Andrew Spencer
> Qmail Admin / RMCI
> [EMAIL PROTECTED]
>
