Using 22.4 at my work and:
1. Changed network password
2. Attempted to log into something a few minutes later
3. Found my account was locked down as something (popfile :p) had been hacking away with the wrong password.
Is this fixed in the 1.0 versions? I'll have a look later (upgrading used to be difficult for me for some reason, so I'll leave it for the mo).
IMAP is one of the things that has seen the most development in recent releases. Version 1.0 changed the IMAP module a lot, here is the info from the release notes:
The IMAP module will now use only one connection to the IMAP server,
instead of one connection for each watched folder. This means that
when using IMAP mode, POPFile will be much lighter on the server and
will even work with IMAP servers that are restrictively configured or
if you have many buckets. As a consequence, you should now be able to
let POPFile sort your email on Google's Gmail.
Yeah, I read all that, but even with only one connection, it will still eventually lock out my account if it has the wrong password.
The IMAP connector should stop processing (and present an error in the ui if possible), if it gets an authentication error. The POP connector should do the same.
Popfile IMAP logs into the server, if you change your password, but don't change it in popfile, popfile will keep trying to login with your old password. it won't take very long to lock you out.
I would suggest stopping popfile before you change your password.
we could try to add logic to tell the difference between a server failure, connection failure, or password denied with the idea being that we don't try to reconnect as frequently if the password was denied, but that will just delay the lockout, not eliminate it.
the only way to eliminate it would be to have popfile stop trying to access a server if the login fails, but there are many cases where the server could have a glitch and cause it to fail temporarily, so we would be trading one failure mode for another.
That's exactly the way I see this issue. Let me add two points, though:
1. With IMAP it is quite tricky to detect the cause of a failed log-in. Sometimes the server may say so, sometimes it may not and if it says so, it might say it in quite different ways.
2. This is the first time something like this pops up. The reason may be that the setup at the server side is really unusual. I can understand firewalling someone who seems to be trying to guess a password. But reset the password? That also means that anyone who knows your login can kill you email access within a matter of minutes. Sure, you might say that this is secure, but it's also quite dangerous.
Ok - so it's difficult to pinpoint the reason.
Can we get UI warnings (top right corner) to say that the IMAP connection is not behaving as it should? Surely there's something that can be done to help the user diagnose. Do Bayesian training on the significance of error messages and have a standard corpus download for it.
It's not unusual to have lockouts for a certain number of times in a specified time window. (5 fails in 10 mins). After this it unlocks again (didn't mean to say reset). This is somewhat necessary if users do not change their passwords (significantly) to stop password cracking velocity.
Most of the time, users don't have the POPFile web interface open. When using IMAP, you rarely need it open since you can reclassify by moving the messages in your IMAP client. It could be days or weeks before anyone sees the warning in the web interface. How often does the incorrect password have to be entered for the system to lock you out? Can you set POPFile to check for messages (imap_update_interval) with a long enough gap in between checks that it won't set off security?
Awesome - thanks. I could do that (but I like really responsive filtering :) ). Our company has 5 fails in 10 min. I'll increase update time while changing passwords in the future until everything is stable.
If no the ui, then the systray in windows? Yeah, I run my home account on the server, so that won't show either. I try to clear out the popfile history every day to ensure someone new hasn't somehow had some important mail end up somewhere else.
Anyhow, some sort of warning system would be nice to have, especially for POP users. Pro-active in helping solve problems.
OT: In the end, the worst password locking culprit was eclipse's Mylyn JIRA Soap plugin. It sat there not working, and because only one infrequently used workspace used it, I didn't notice :).
In the normal POP setup, POPFile doesn't know you POP password and it doesn't decide how often to check. Your mail client does that. So you should get "cannot connect" messages from your client.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.