Getting sporadic errors when deleting emails on server live

[george_c]

Hi:
I use Pop3 Scan Mail for Windows to browse and delete emails live on the server before downloading them (a program Futurequest once recommended here I believe). Starting this month, I sometimes will get the error:

"Protocol Error : (25). I said DELE 2 and the POP3 server responded: -ERR Connection timed out"

and the program halts (not freezes). If I try a few more times reconnecting, it works. I've never gotten this error before. Any insight?

Thanks,

[Bruce]

POP3 server responded: -ERR Connection timed outAs a result of some rampant POP and IMAP service scans, we have needed to reduce the timeout on these services to a relatively short interval. Specifically, the POP server will wait no more than 30 seconds for a command from the client, after which time it will issue the above message and drop the connection. Most likely the software you are using (Pop3 Scan Mail) took longer than 30 seconds to respond after retrieving a message.

[george_c]

Thanks Bruce, that makes sense. Only problem I can see if if I'm reviewing tons of emails on the server that may take longer than 30 seconds before I can delete some of them. But in general I think I should be fine.

[Bruce]

Only problem I can see if if I'm reviewing tons of emails on the server that may take longer than 30 seconds before I can delete some of them.I'm not sure I understand this. See, the timeout is 30 seconds per command, and each message takes one command each to download and delete. So, unless the mode of operations for this program is to download everything and then scan, it shouldn't normally hit the 30 second limit (assuming that it takes less than that per message to scan).

[Wassercrats]

Does that 30 second limit apply to the time I have to reply to an email sent to my domain that I'm viewing in Outlook Express? I have to check for new email right before I send because I've been getting many authorization (or something) errors and unsent emails when I haven't.

[Bruce]

Does that 30 second limit apply to the time I have to reply to an email sent to my domain that I'm viewing in Outlook Express?No. That time after POP or IMAP login during which your IP is allowed to relay was and remains set at 15 minutes.

[george_c]

I'm not sure I understand this. See, the timeout is 30 seconds per command, and each message takes one command each to download and delete. So, unless the mode of operations for this program is to download everything and then scan, it shouldn't normally hit the 30 second limit (assuming that it takes less than that per message to scan).

I'm running into the 30 sec limit this way in ScanMail I believe: Lets say I have 500 emails in the inbox, and I use ScanMail to list them first on the server. No problems so far. I then take more than 30 seconds to glance over the subject of each email (without further interacting with MailScan). I then check the emails I want to delete, and when I actually try to delete them (by disconnecting from MailScan), 30 seconds have expired (idle time), and this results in the error I'm seeing. At least that's how I believe I'm getting this error.

[Bruce]

I have just patched the POP (and IMAP) front ends on the POP toasters to separate the login timeout and the normal timeout. This has allowed me to keep the short login timeout needed to prevent port scans from turning into massive POP toaster DoS attacks, while allowing long legitimate connections to stay operational. These timeout problems should no longer be an issue. :yeah:

[manish]

I was getting similar timeouts when I was using pine with imap to the mail server. It seems that after I log in, every time I leave the connection idle for about a minute, the connection is dropped.

Pine says "Mail Folder Inbox closed due to access error".

Manish

[msiege2]

I was getting similar timeouts when I was using pine with imap to the mail server. It seems that after I log in, every time I leave the connection idle for about a minute, the connection is dropped.

Pine says "Mail Folder Inbox closed due to access error".

Manish


I too am having this problem in Pine, just since the past 2 days or so. At first, I thought I had a client open connecting to my inbox concurrently with my pine session, but I have determined that is not the case. My IMAP session seems to be timing out on a very very short interval.

How can we go about fixing this so that it works like it did previously?

[Bruce]

I too am having this problem in Pine, just since the past 2 days or so. At first, I thought I had a client open connecting to my inbox concurrently with my pine session, but I have determined that is not the case. My IMAP session seems to be timing out on a very very short interval.

How can we go about fixing this so that it works like it did previously?The revised POP and IMAP front ends put into place to fix the other timeout problem set up a 30 second authentication session timeout. This means, after 30 seconds the connection is dropped no matter if there has been activity or not. Unfortunately, this timeout (enforced via an alarm) was not cleared when the back end, used for actually accessing your email, was executed. So, the back end would get killed after 30 seconds minus however long it took to log in. :BPG2:

I have patched the front end software to clear this alarm before executing the back end, and have verified that the session does not drop after 30 seconds any more. Our apologies for this mixup.

[msiege2]

The revised POP and IMAP front ends put into place to fix the other timeout problem set up a 30 second authentication session timeout. This means, after 30 seconds the connection is dropped no matter if there has been activity or not. Unfortunately, this timeout (enforced via an alarm) was not cleared when the back end, used for actually accessing your email, was executed. So, the back end would get killed after 30 seconds minus however long it took to log in. :BPG2:

I have patched the front end software to clear this alarm before executing the back end, and have verified that the session does not drop after 30 seconds any more. Our apologies for this mixup.

Excellent! It's working just fine again. :) Thanks for taking care of this problem.