The 'noauth' change did it
First I just added 'noauth' to my 'ppp-on' script and it ran fine, with the
connection remaining intact until 'poff'. Then I removed 'noauth' from my
script and added it to /etc/ppp/options with the same effect. Despite the
pleading in /etc/ppp/options not to disable auth, I followed Lawson's
suggestion and left 'noauth' there
Once I had ppp fired up I tried fetchmail, having previously set up
.fetchmailrc. I ran fetchmail -v -v and got:
fetchmail: querying email.msn.com (protocol POP3) at Sun Aug 6 15:38:42 2000
fetchmail: POP3 connection to email.msn.com failed: name is valid but has no
IP address
fetchmail: Query status=2
fetchmail: normal termination, status 2
These results were the same when or not DNS was enabled in .fetchmailrc
The output from fetchmail -V follows:
This is fetchmail release 4.6.4
Linux debian 2.2.12 #2 Thu Aug 26 11:46:26 PDT 1999 i686 unknown
Taking options from command line and /root/.fetchmailrc
Idfile is /root/.fetchids
Fetchmail will forward misaddressed multidrop messages to postmaster.
Options for retrieving from [EMAIL PROTECTED]:
True name of server is email.msn.com.
Protocol is POP3.
Server nonresponse timeout is 300 seconds (default).
Default mailbox selected.
Only new messages will be retrieved (--all off).
Fetched messages will be kept on the server (--keep on).
Old messages will not be flushed before message retrieval (--flush off).
Rewrite of server-local addresses is enabled (--norewrite off).
Carriage-return stripping is disabled (stripcr off).
Carriage-return forcing is disabled (forcecr off).
Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
MIME decoding is disabled (mimedecode off).
Nonempty Status lines will be kept (dropstatus off)
Messages will be SMTP-forwarded to: email.msn.com
Host part of MAIL FROM line will be 204.255.246.17
Recognized listener spam block responses are: 571 550 501
Single-drop mode: 1 local name(s) recognized.
No UIDs saved from this host.
The modprobe message continues in /etc/ppp/connect-errors
Attempting to break the connection with /etc/ppp/ppp-off produces:
bash: /etc/ppp/ppp-off: Permission denied
This is a puzzlement since I wrote it (copying O'Reilly)
The script reads:
kill 'cat /var/run/ppp0.pid'
poff terminates the connection successfully
using pon (instead of my /etc/ppp/ppp-on script) also gets me a good
connection
I seemingly sent myself mail via sendmail, but it certainly hasn't arrived.
I wrote:
sendmail [EMAIL PROTECTED] 'sendmail test'
.
Ctl-D
I assume once I 'pon' or '/etc/ppp/ppp-on' I can then rev up any application
that wants to use the connection. How do I integrate the dialup into
fetchmail/sendmail/exim . . . or should I?
David
----- Original Message -----
From: Ray Olszewski <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, August 06, 2000 10:52 AM
Subject: Re: fetchmail/minicom
> At 01:25 PM 8/6/00 EDT, [EMAIL PROTECTED] wrote:
> ...
> >> Aug 6 11:25:29 debian pppd[274]: rcvd [LCP ConfRej id=0x1 <auth pap>]
> >
> >Looks like the remote pppd is satisfied with the shell login and doesn't
> >want to be bothered with PAP. Maybe you can try
> >
> >noauth
> >
> >in /etc/ppp/options.
>
> Good catch, Lawson. I'd missed that he had "auth" in that file AND didn't
> override it in the command-line options that invoke pppd (the usual
> workaround).
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.linux-learn.org/faqs
