Mail Server Issues

[meva]

Simon,
Friday has come and gone, email has been recovered and I still have almost unusable imap service (imap.idnet.com). I have tried three email clients on different PCs and different email addresses (Outlook 2010, Thunderbird, Windows Live) and have the same symptoms which is that I can download headers but I get server timeouts or long (infinite) waits depending upon the client to download the message bodies of all but the smallest email messages. I can send email with large attachments (4Mb) no problem - so smtp server seems fine. Webmail client is fine.

Thank you Simon, Steve, Ray and everybody else helping to get idnet to focus on this problem.
Martin

[Simon]

Hi Martin,

As you'll most likely be aware, support is limited over the weekends with IDNet.  I think you will need to contact them directly on Monday about this problem.  Just a thought, though, assuming you are using an IDNet connection, have you tried imap.idnet.net?

[Simon]

Incidentally, I'm using imap.idnet.com without any problems. 

[Steve]

We'll continue to persevere ,It's odd that Simon  as the only servers I'm aware of for both POP3 and IMAP are mail.idnet.com and securemail.idnet.com which is confirmed by the setup guides. Perhaps I'll give the IMAP one a try.

[Simon]

I may have got it wrong, but I'm sure I was told that either could be used.  It'll either work or it won't. 

One other thing, can you access your mail via webmail, Martin?  How much is sitting there?  Are there any particularly large emails waiting to download which might be blocking others?  I've had that once or twice. 

[Steve]

I may have got it wrong, but I'm sure I was told that either could be used.  It'll either work or it won't. 
 

Certainly it exists Simon but sadly for me it exhibits the same extremely slow throughput. Perhaps I'll try with the spam filter off

[Simon]

Another thought - if you can access via webmail, check that your inbox, and / or other folders aren't full of old or duplicate emails following the recovery.  The max mailbox size is 100Mb, max individual item / attachment, 10Mb.

[Steve]

Turning the spam filter off made no difference at all.

[Simon]

How full is your mailbox, Steve?

[Steve]

It was deliberately empty Simon , well until it received the email I really don't think there's anything anyone can do until support have a look at it again.

[Simon]

Well, if the above is right, it was my idea.  If it's wrong, it was Rik's. 

[meva]

Simon,
I've been managing my email using the webmail client which works fine. So I know there is no large message at the "front" of the queue holding up the email queue as I've been deleting emails. My email usage is at about 5%. I'm not getting much spam - rarely do on my idnet addresses as I don't use them for registering on web sites / forums etc.

Seems to me to be a specific problem accessing imap server on port 143. Makers no difference if I use mail.idnet.com or imap.idnet.com - same issue.

Three of us at least seem to have this problem - you, Simon, seem to be OK. So I wonder whether there is some problem between the BT/idnet connection and the imap server associated with accessing port 143 - load balancing or different routing dependent upon geography / ip address?

Thanks,
Martin

[JB]

Friday has come and gone, email has been recovered and I still have almost unusable imap service (imap.idnet.com).

I have a problem retrieving email via pop3. I am using a pop3 client called CMailServer which polls a number of pop3 mailboxes, retrieves the email and then filters it to the users in my house. It has worked perfectly with IDNet pop3 until the mail server problem. It continues to work perfectly with a number of other pop3 retrievals but not with IDNet.

For some strange reason, although it logs perfectly in to the IDNet pop3 account, the email is not retrieved and then is deleted, presumably by my client which thinks it has retrieved it. Here is a test sequence I have used:-

1) From GMail I send myself (xxxx.xxx@idnet.com) a test message.
2) I log into my IDNet mailbox via webmail and I can see and read the message perfectly.
3) I allow my CMailServer to poll the IDNet pop3 account to retrieve that email. This logs in perfectly but no email is retrieved.
4) I then log back in via webmail and the message has been deleted.
5) I send myself another message from GMail.
6) I set my CMailServer option to 'retrieve but leave the messages on the server'. I poll again, connection is fine but no message is retrieved.
7) I log in again via webmail and the message is still there but refuses to be retrieved.

I know this sounds a bit complicated, but it appears to me that my CmailServer thinks the message has been received and (when allowed to) issues a delete command.

Maybe this is a different problem to what is being discussed above or maybe it is another symptom of the same issue. I do know however that this setup worked perfectly with IDNet until the mail server was replaced and continues to work correctly with pop3 retrieval from a number of other providers.

I'm at a loss to know what else to try. Because of this I have had to move my incoming email away from IDNet.

[Simon]

Simon,
I've been managing my email using the webmail client which works fine. So I know there is no large message at the "front" of the queue holding up the email queue as I've been deleting emails. My email usage is at about 5%. I'm not getting much spam - rarely do on my idnet addresses as I don't use them for registering on web sites / forums etc.

Seems to me to be a specific problem accessing imap server on port 143. Makers no difference if I use mail.idnet.com or imap.idnet.com - same issue.

Three of us at least seem to have this problem - you, Simon, seem to be OK. So I wonder whether there is some problem between the BT/idnet connection and the imap server associated with accessing port 143 - load balancing or different routing dependent upon geography / ip address?

Thanks,
Martin

I'm just clutching at straws really, trying to make suggestions.  I am accessing imap.idnet.com on port 143 without any trouble, and as we've only had a small number of people on here who are experiencing problems, it has to be assumed that it's not a widespread issue.

I can only now suggest that anyone affected by this contacts IDNet, either by email any time, or by phone on Monday, but do keep us posted here as to what's happening.

[ElectricTrev]

Unfortunately evey time someone comes up with a theory someone has to shoot it down. On this occassion it is me. I am using POP3 on port 110. duggy has never specified what he is using. Although only a small group of us are reporting problems here I suspect the problem goes wider.

At present I feel that idnet are so shell shocked by the events of last week that this additional problem has not registered with them. A number of us have contacted them, on more than one occassion, but as far as I can see they have yet to make a serious attempt to track the problem down.

[Steve]

This is a blank email with a 375kb attachment to a IDNet POP3 account,enabling logging on the Apple Mail.app you can see precisely how long it takes to download i.e. 183 secs or just over 2Kb/sec.



28/01/2012 22:59:14.091 [0x0-0x3ce3ce].com.apple.mail: [LogPOPFetchTimes] Time to retrieve all 1 messages = 183.244 (183.24430 s/msg)



A temporary solution for those that are suffering from poor email performance is to forward all mail intended for an idnet.com address to another non idnet email account,this can be setup via the message filter option on the IDNet customer portal. I think that's why I didn't realise I had a performance issue until I turned off some mail forwards from idnet.com email addresses. 

[Simon]

Trevor, you could be right that the problem goes wider, but unless people report it, we don't know.  It's obviously not affecting everyone. 

I would hope that IDNet will look into this properly on Monday.  They only usually deal with 'no connection' issues out of normal support hours. 

[zappaDPJ]

I have also been having issues since the outage, particularly sending/receiving emails containing large attachments (1mb-10mb via Outlook). However that problem has now been resolved for me and as far as I can tell, everything is working as intended.

[duggy]

Trev, I am also using POP3 on port 110.

[Steve]

Mines  still receiving at the same rate as yesterday

29/01/2012 17:51:26.577 [0x0-0x481481].com.apple.mail: [LogPOPFetchTimes] Time to retrieve and route messages = 239.357


That's 239 secs for a 650k attachment =2.7Kb/sec

[ElectricTrev]

Zap,
If you solved the problem can you tell us the cause and solution please?

Trevor

[ElectricTrev]

The error message doesn't give much away to me, but it may do to a more technical eye.  Have you forwarded it to IDNet?  If you address it to brian[at]idnet.net he should know what it's about, as I spoke to him earlier about it, which you can mention if you like. 

Other possibility - Thunderbird issue?  Reinstall? 

I sent the information as suggested. Brian has responded

mail logs show a number of 'connection reset by peer' messages suggesting Thunderbird is hanging up the connection to the server.

He suggested increasing the timers on Thunderbird. I have rejected this as it does not address the core issue. Clearly the reason Thunderbird hangs up is because it is getting nothing from the server and it won't hang around forever. As we know this is an issue for a number of agents not just Thunderbird.

I still feel that this issue is failing to get traction within IDNet.

[Simon]

From my communications with IDNet, I can assure you that they are continuing to investigate the issue, but unfortunately, can currently see no obvious problems, hence no obvious solutions. 

They did say that several users got blocked for trying continuously to send mail via the pop/imap server, which they resolved on Saturday afternoon and several users are currently temporarily blocked for invalid password attempts, which will automatically reset in around 15 minutes.

Sorry if that doesn't help you.  Hopefully they will find something today. 

[brian_idnet]

We recognize a few users are having this issue and are still investigating, however, this is taking a little longer to try and find the cause as any in-house tests we have run so far have failed to replicate the issue. Please bear with us while we continue to investigate and run some further tests.

Brian

[Glenn]

Thanks for the update, Brian