Fetchmail problem with ISDN (SuSE 7.1)
Hi! Yesterday I installed ISDN (E-Tech PCI card) on my SuSe box. When fetching mail from my ISP I've noticed some strange error. Here is the log: ***************************** fetchmail fetchmail: 5.6.5 querying pop.iskon.hr (protocol POP3) at Sri 24 Lis 2001 09:49:20 fetchmail: Invalid command, try one of: USER name, PASS string, APOP name digest, QUIT fetchmail: 3 messages for sjaniska at mail.iskon.hr (8611 octets). fetchmail: reading message 1 of 3 (2818 octets) ..fetchmail: flushed fetchmail: Mailbox corrupted fetchmail: client/server protocol error while fetching from pop.iskon.hr fetchmail: Query status=4 (PROTOCOL) ************************************* I contacted ISP technical support and they checked my account - logging and fetching mail and they say that everything is OK on their side. I'm running Linux almost three years and never had similar experience. Nothing changed on my setup except ISDN card. I establish connection manually by calling script which executes isdnctrl dial ippp0, and hangup via script that calls isdnctrl hangup ippp0. Also, it is strange that when executing sendmail -v -q (I don't see procedure when sendmail is establishing conneciton with SMTP mail server on my ISP, which was the case before ISDN. Any idea what can be wrong? Sincerely, Sasa
* Sasa Janiska
Hi!
Yesterday I installed ISDN (E-Tech PCI card) on my SuSe box.
When fetching mail from my ISP I've noticed some strange error. Here is the log: ***************************** fetchmail fetchmail: 5.6.5 querying pop.iskon.hr (protocol POP3) at Sri 24 Lis 2001 09:49:20 fetchmail: Invalid command, try one of: USER name, PASS string, APOP name digest, QUIT fetchmail: 3 messages for sjaniska at mail.iskon.hr (8611 octets). fetchmail: reading message 1 of 3 (2818 octets) ..fetchmail: flushed fetchmail: Mailbox corrupted fetchmail: client/server protocol error while fetching from pop.iskon.hr fetchmail: Query status=4 (PROTOCOL)
To me it looks like fetchmail is not configured correctly... Did you use fetchmailconf? If not, try it out. -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogic, with just a little bit more effort." -- A. P. J.
On Today, +0200, Mads Martin Joergensen wrote:
To me it looks like fetchmail is not configured correctly... Did you use fetchmailconf? If not, try it out.
Yeah, it could be. But why did it work properly so long? My present fetchmailrc is made with fetchmailconf in July 2000. Sincerely, Sasa
On Wed, 24 Oct 2001, Sasa Janiska wrote:
Hi!
Yesterday I installed ISDN (E-Tech PCI card) on my SuSe box.
When fetching mail from my ISP I've noticed some strange error. Here is the log: ***************************** fetchmail fetchmail: 5.6.5 querying pop.iskon.hr (protocol POP3) at Sri 24 Lis 2001 09:49:20 fetchmail: Invalid command, try one of: USER name, PASS string, APOP name digest, QUIT fetchmail: 3 messages for sjaniska at mail.iskon.hr (8611 octets). fetchmail: reading message 1 of 3 (2818 octets) ..fetchmail: flushed fetchmail: Mailbox corrupted fetchmail: client/server protocol error while fetching from pop.iskon.hr fetchmail: Query status=4 (PROTOCOL) *************************************
I've never run an internal ISDN card, so I'm no help with specifics, but I can say that I've gotten strange messages like this when pppd has gotten fooled about asyncmap and MTU protocols on the link. It'll look like everything is connected, but certain characters or long packets don't make it thru. For me, the messages have been strange, but the pattern has been repeatable, so it wasn't a 'dirty line' but rather a specific corrupting filter in place. The asyncmap problems have resulted in fetchmail consistently blowing up with a 'protocol error' at the same point in the same message every time. The MTU-too-small error resulted in certain web sites, or pages within sites, simply 'hanging' during the download. Apparently, some misguided firewall writers suppress all/most ICMP messsages, which breaks path MTU discovery, so their sites are only accessable to those who use the default MTU 1500. -- Rick Green "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -Benjamin Franklin
participants (3)
-
Mads Martin Joergensen -
Rick Green -
Sasa Janiska