At 8:37 PM +0000 11/18/01, Rick Hoffman wrote:
> Thanks for your response Randall.
>
>> > > or looking in the wrong place.
>> > This I have a feeling is happening. I copy my mailbox file (/var/spool/
>> > mail/hoffy) into /var/spool/pop expecting Qpopper to see it but it still
>> > tells me zero messages.
>>
>> That seems very odd.
>
> Yeah, just what I thought. I figured that should've done it to.
> Any ideas on why this didn't work? You also saw, I'm sure, that I
> explicitly created a config file and was trying to order Qpopper to
> use /var/spool/mail as my mailbox path but it appears it is totally
> ignoring that. Could it be that Qpopper is not seeing this config
> file for some reason?
That's possible. Since you're running Qpopper through tcpd instead
of directly from inetd there may be something funny about parameters.
>
> Also, when I use the telnet command to invoke Qpopper and it accepts the
> user and password stuff and then tells me no messages, doesn't that mean
> Qpopper is up and running?
It sure does.
>
>> Which version of Qpopper?
>
> $ qpopper -v
> Qpopper version 4.0.3 (non-standalone)
That version certainly knows about configuration files and the
spool-dir option.
> > Probably the best thing is to get a fresh copy of 4.0.3 and run
>> './configure' and 'make' yourself. Then, if you still have any
>> problems, you can enable debug tracing and see what's going on.
>
> I have no problem doing that but its a shame I should have to.
> I am curious what difference this would make? I suppose I can't
> enable debug tracing unless that is compiled into the executable, is
> that right?
That's it.
>
> I am guessing the Debian maintainer of this package used all the
> default settings when he/she compiled it. I am also guessing that
> would be the most logical thing to do because if there are any
> specific user settings/configuration issues shouldn't I be able to
> negociate those through command line options or a configuration file?
> If not then I wonder what it is that I need to compile in to make
> a difference from what is going on now.
You should be able to set almost everything using a configuration file.
>
> For some reason I have a feeling I am in for a big time-consuming
> fight here. I don't understand what I am doing wrong. It all seems
> so cut and dried.
You could try, just as a test, changing the inetd.conf line from:
"pop-3 stream tcp nowait root /usr/sbin/tcpd
/usr/sbin/in.qpopper -f /path/to/config/file"
to:
"pop-3 stream tcp nowait root /usr/sbin/in.qpopper
qpopper -f /path/to/config/file"
You could also try putting something bogus in the configuration file.
That should cause Qpopper to spit out an error message and close the
connection. That would confirm that it's reading the configuration
file. (For example, "set foobar gork"). If this doesn't happen, try
adding a bogus command-line argument. The idea to isolate where the
problem is:
- Are you failing to send inetd a HUP signal?
- Are your command-line flags not being passed to Qpopper?
- Is Qpopper failing to read or process the config file?
>
> My ISP is, of course, using a POP server to deliver messages to me.
> Could there be something his POP server is doing so that these messages
> can't be delivered again by another POP server? Does that make any
> sense?
That should have nothing to do with it. As a totally separate
matter from your current problem, SMTP delivery is much more reliable
than POP delivery. If your ISP supports it, you could use ODMR
(On-Demand Mail Relay, RFC 2645), which fetchmail now supports.
