Our outgoing pop attempts should back off quite a bit after a while, though I don't think we disable completely. The errors should be visible if they ever log in.
I would think that clients should make such login errors fairly prominent. Our intrusion detection system gets the password hash as part of the check, so we can ignore failure attempts that keep trying the same password. It also has access to account status and can ignore disabled accounts as well. Also, with most popular clients switching to oauth2 for access to Gmail, we can deny at the refresh token request instead, and I think the response there is more obvious to clients that a user prompt will be required. I can imagine some day when they get to be significant enough, though so far computers get reinstalled or replaced fast enough. With mobile devices now doing more complete backups and restores than most people ever had for computers, it could become more of a problem... Software updates are also more likely, so we can probably work with clients on solutions of it becomes a major issue. Brandon On Feb 15, 2016 9:56 AM, "Al Iverson" <[email protected]> wrote: > I run a combination system that uses Google Apps, Gmail accounts, and > Fetchmail/scripts to send, receive and process mail for around 400 users. > (It's a sort of wanted bulk mail "ham" tracking system, not a personal > message platform.) Occasionally somebody changes a password and thus > Fetchmail can no longer connect to their Gmail account. Sometimes I catch > it, sometimes not. Google has not seemed to have noticed fetchmail knocking > on those doors for days or weeks. > > Thus, I don't see this as much of a real issue, to be honest. > > But if you're looking for ideas on how to ease your personal pain: > You could null route the connecting IP just to keep the noise out of your > logs, if the connecting IP is unchanging. > You could re-enable the account to be able to check mail, but not receive > mail, to keep from alerting, but to prevent the user from getting value > from the account. > Or you could update your intrusion detection to ignore references to these > accounts. > > Regards, > Al Iverson > > > > -- > Al Iverson - Minneapolis - (312) 275-0130 > Simple DNS Tools since 2008: xnnd.com > www.spamresource.com & aliverson.com > > On Mon, Feb 15, 2016 at 9:12 AM, Andreas Schamanek < > [email protected]> wrote: > >> >> Hi fellow mailops, >> >> Often when user's mail accounts get canceled they do not remove or >> update their MUAs' configuration. Hence, I see a lot of repeated login >> attempts. >> >> Apart from the fact that this is a waste of a number of resources, >> these attempts also trigger my intrusion detection system (which for >> now does not check whether the username is one of an old account or >> not). >> >> I was wondering how others deal with failing login attempts related to >> deleted accounts. Is there a particularly good way to convince old >> users to update their configurations? >> >> -- >> -- Andreas >> >> :-) >> >> >> _______________________________________________ >> mailop mailing list >> [email protected] >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> > > > _______________________________________________ > mailop mailing list > [email protected] > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > >
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
