This bug really burns me, because it’s been around forever, and Apple just isn’t doing anything about it.
Anyone who has used Apple Mail for more than a week has seen the following dialog box:
Of course, the natural response is to obey and type your password.
Don’t do it.
There are a half-dozen or so reasons why a mail transaction will fail. The mail server may be busy, hung, or dead. Your Wi-Fi may be down or your ethernet cable may be loose. There could be a network interruption in the greater internet somewhere between you and your mail server. Or, you could actually have supplied the wrong password for the account.
Unless your mail account is brand new, or you recently changed your mail password, the probability that this last choice is really your problem is vanishingly small.
However, that’s not Apple Mail’s opinion. “Couldn’t contact the server? Oh no, it has to be a bad password!” So Mail puts up this dialog box, inveigling you to type in your password again.
There is no upside to complying with this request.
There are two probabilities here that absolutely dwarf all others: you will type in your password correctly, which won’t solve anything because your password was never the problem; or you will type in your password incorrectly, at which point you have now compounded your original problem by layering a worse one on top of it.
The real joker in the woodpile here is that one of the biggest reasons for typing in your password incorrectly is because you have actually forgotten your correct password. Now, a lost mail password can be retrieved using Keychain Access on your Mac… unless of course you have just overwritten it with a bad password because you responded to this idiotic query from Mail. 😡
The good news is that if you avoid thrashing at this juncture, you can still recover. Mail stores the POP/IMAP (incoming) account password separately from the SMTP (outgoing) account password, and in almost all cases known to man, they are the same password. Use Keychain Access to view the one you haven’t yet damaged, and beat this particular reaper.
[May 21 addendum: I’ve corrected this posting to identify the email service as Cox, not Gmail, and to append some additional information on defeating this bug.]
On this one, I suspected poltergeists.
A client called me complaining that she was periodically unable to send mail using her Cox account. We arranged a remote service session, and I found that the port and authentication type parameters for at least one of her outgoing server configurations were incorrect for Cox. I repaired them and verified that the result worked.
The next day, the client wrote to say she was having the same problems. I logged in again, and found that one of the port numbers had changed back to the same incorrect value, and the authentication setting had changed from “password” to “MD5 Challenge-Response.” I asked her if she changed those, and she said no, so I changed them back again and told her there would be no charge for the session.
Two days later, she reported to me that her service has been sporadic. Sometimes she could send mail, and sometime she couldn’t. Sometimes she could send it by switching to the SMTP server on her husband’s account, and sometimes she had to do the reverse.
I got back onto her system, and I found that the configuration values on her account have been changed again, and to values (like port 25) that don’t even work with Cox and never have.
I changed the broken account back to its proper value, whereupon the other one — which had just tested as working — immediately went out of whack!
I switched to it and found that the port had changed again… during the ten seconds that I was working on the other one.
Several times I ping-ponged back and forth, ports and authentication methods mysteriously changing themselves to the wrong values repeatedly during the course of a minute or so.
At this point I began to suspect malware, as improbable as that was. While I was downloading ClamXAV onto her system, I did a fast Web search on the symptoms. I was almost immediately rewarded with a posting describing exactly the same symptoms, and the fix for it.
It seems that in Yosemite, in the advanced section of the e-mail account configuration, there is a new checkbox called, “Automatically detect and maintain account settings.” Yosemite sets this on by default.
The downside is, it’s entirely brain-damaged. It’s just as likely to break your configuration as to maintain it, and is perfectly capable of doing either dozens of times a day, behind your back.
I turned that pesky option off, and again locked the port and password fields to working values. I’m hoping I’ll hear no more of this problem (at least from this client) until Apple finally fixes their buggy code.
[Addendum, May 21: Since posting this, I’ve heard from several other users with exactly the same problem. Informed speculation has it that it is Cox themselves who are feeding these erroneous values back into Mail, and not an Apple bug at all.
[Additionally, Yosemite also added a second “Automatically detect and maintain account settings” checkbox in the “Edit SMTP Server” area itself. If you don’t turn off both this flag and the one in Account / Advanced, the hits will just keep on coming. Make sure they stay off, as at least one user reports the one in Account / Advanced mysteriously turning itself back on right after he turned off the one in “Edit SMTP Server.”]
Every so often, a technical tidbit just flabbergasts me.
In the course of a client housecall last week, all the software updates I was attempting to download were taking unreasonable times to complete. I asked the client what speed DSL service she was paying for, but she didn’t know offhand (not unusual, as CenturyLink invoices typically describe their DSL service levels by package titles instead of actual speeds). I ran a test and measured the download speed at about 2.5Mb/sec, with an upload speed somewhat faster (very unusual).
After making sure no other devices in her home were leeching bandwidth, we got on the phone to CenturyLink, who informed us that the contract speed was 12Mb/sec. Indeed, the modem showed it had trained in at 15Mb/sec, but was still delivering a mere fraction of that. The business office transferred us to Repairs.
Lynn, the service agent, ran through her boilerplate and had us check the cabling (requiring the moving and replacing of much heavy furniture).
Next she said something that raised my eyebrows: “I see that this modem has been running continuously for 270 days, so I want you to disconnect the DSL modem from the wall cable, disconnect power from the modem for two full minutes, plug the power back in, wait for the power indicator to go green, then plug the wall cable back in.”
We did this… and the speed jumped back up to 12Mb/sec.
This is the sort of procedure that would have struck me as superstitious voodoo had I not witnessed its success myself.
I said to Lynn, “I wouldn’t think continuous uptime of 270 days would be that unusual. Are you telling us we’re supposed to power-cycle our DSL modem every couple months?”
“Oh, no,” she said—“you need to power-cycle your DSL modem every two weeks.”
Wow. And here I thought that having to change my HVAC air filters every month was burdensome.
I have to say, this maintenance “requirement” was total news to me. I’ve never owned a DSL connection myself, but I’ve installed dozens of them for clients. Not once have I seen any mention in the CenturyLink literature that the customer was expected to power-cycle his DSL modem twice each month.
I can’t imagine how one could even design equipment that requires this. I have networking equipment out in the field that has operated continuously for years without rebooting, much less power-cycling.
What say you, DSL users — were any of you out there aware of this?
In October of 2014, discovery of the POODLE exploit caused financial institutions around the globe to disable the SSL 3.0 communication protocol practically overnight, effectively killing Intuit’s Quicken 2007 for the Mac, insofar as users who needed to be able to download transactions from their financial institutions.
Intuit, whose reaction to problems in their Macintosh software was always glacial at best, showed practically zero interest in solving this new problem, given that they could finally point users to their new Quicken 2015 product. Their response to POODLE boiled down to, “buy Quicken 2015, or go back to fetching all your downloads by hand (WebConnect).”
Given that my accounting records consisted of three separate Quicken files, one going back a decade, the conversion was bumpy at best. Dozens of times, I ran into the lack of familiar features that I took for granted in Quicken. Still, I was willing to push through the process because IGG Software offers responsive support, including direct e-mail and online chat. (Compare this to Intuit’s deadly lame offering, which is to refer you to an online knowledgebase, and when that fails to work, to dump you into a forum of other users, whom they expect will solve each other’s problems with zero effort on Intuit’s part.)
So here I will endeavor to present one Quicken defector’s experience with the iBank product, in order to give fellow Mac users some ideas of what issues they may encounter if they decide to defect as well.
Things that won’t convert at all
iBank won’t even attempt to convert Quicken scheduled transactions. If you make abundant use of scheduled transactions (I had over 100 active in one file), you will have to reenter them all by hand in your new iBank file. (See below for why the “automatic” creation feature for scheduled transactions isn’t a good substitute.)
Account reconciliation records are also not transferred from the Quicken file. This forces you to do reconciliations over again, especially in the hunt for bogey transactions (described below).
Similarly, no attempt is made to convert stored reports into their iBank equivalents.
Taken together, these three lapses translate into a lot of manual work for the defector. In my case, it took about one and a half full work days to get my iBank files up to the same content and quality as the Quicken files from which they were derived.
Another feature lapse hit me relatively hard. Quicken 2007 knew how to figure out and apply loan amortization, both for loans you took out and for loans you made. One of the advantages that iBank touts over Quicken 2015 is that it can do loan amortization, while Quicken 2015 can’t. This bullet point led me to believe that iBank could handle the writing of loans — after all, if you’re taking out a loan, knowing the amortization is nice and all, but if your calculations disagree with those of your creditor, his rule and yours drool. On the other hand, if it’s you writing the loan, then you have to be able to provide accurate amortization calculations to the borrower, and track the incoming principal and interest properly for the taxman.
As it turns out, iBank has no clue how to handle your writing a loan. If it sees loan asset accounts in a Quicken file to be converted, it doesn’t recognize them as loans or even allow you to specify that they are loans. This is going to force me to do additional manual work each month until this feature can be added to the package, and is probably the major basic shortcoming of iBank with respect to the accounts I have to manage. Apparently, a lot of users have asked for this feature, so hopefully it won’t be long in coming.
Things that won’t convert correctly
The “cleared” indicator of every transferred transaction was set, regardless of whether or not it was set in the original Quicken file. Thankfully, mishandling of the “cleared” indicator seemed to be limited only to the conversion process.
Like Quicken, iBank urges you to categorize every transaction. However, Quicken allowed you to leave most securities transactions uncategorized because it supplied an automatic categorization implied by the transaction type. For example, a long-term capital gain distribution had the transaction type “RL”, and Quicken automatically supplied and entered the category of “•Long CapGnDst”. Somehow, these categorizations get lost in the conversion process, such that every securities transaction ends up uncategorized. iBank doesn’t complain about this, but you start getting bizarre report results (e.g., a pie chart showing that the fifth largest component of your annual income is “Uncategorized”). This forces you to manually edit every transaction in every securities account (at least for the current year, if not more) in order to keep the tax man happy.
In Quicken, it’s possible to use the name of the current account as a category for a transaction, so that you can avoid selecting (or creating) a specific income category without leaving the category field blank. For example, in your Discover account, you could categorize rebates to your bill from Cashback Reward transactions as “[Discover]”.
Such transactions give iBank the vapors. Attempting to “do the right thing” accounting-wise during the conversion, iBank will invent and insert into your account a compensating transaction for the inverse of that amount. Of course, this causes your account not to balance any longer. You have to find these bogey transactions by hand, recategorize all the original transactions, and delete the added ones.
After the conversion process, I also found a number of other strange bogey transactions that were unrelated to the category name issue. These also have to be rooted out by hand, typically by performing years of account reconciliations to narrow down where these transactions have been inserted (because your old reconciliations were not transferred).
In creating these bogey transactions, iBank will sometimes insert an account name as if it were a category name, at which point it will add a “1” to your account name and complain about “duplication” if you try to remove it. Despite what one might expect, I discovered that the transaction that triggered this behavior was not even one that had the account name in brackets in the category field, but one that had an entirely blank category in the original Quicken file! Again, you have to manually re-categorize these transactions, then delete the offending category, before you can correct the account name.
(In the process of searching for transactions that contained non-account “categories” created from existing account names, I used both the “Smart Account” and “Reports” feature to locate such transactions, and discovered a bug where neither feature would identify any transactions that were split transactions, which is how iBank created most of them.)
Operational and Preference Issues
Quicken allows the user to define single character “operators” to modify transaction amounts. For example you could define the letter “t” to signify multiplication by your local tax rate, and “m” to signify multiplication by the standard IRS mileage allowance; then have Quicken compute the deduction for an 85 mile trip simply by typing “85m” in the amount field.
Similarly, Quicken has a set of defined abbreviations for date fields, such as “t” for today, “m” and “y” for the beginning of the current month or year, and “+” and “-“ to nudge a transaction date forwards or backwards.
I couldn’t find support for anything like these in iBank, and I miss them sorely.
It’s worth mentioning that iBank does offer the same basic feature of “calculator math while entering amounts” that Quicken does.
A Need for Speed
Compared to Quicken, iBank bogs down. Enter, change, or delete a transaction, and your machine freezes up for one to 15 seconds before it listens to you again. (It’s not because I’m running marginal hardware; my hardware is maxed up.) Type the first letter into the category field of a new transaction, and your entire machine grinds to a halt while iBank looks through the list of all defined categories. (Seriously, I don’t have that many—use a hash table, guys?) It doesn’t even echo the character you typed until the hang is over!
Some of this speed differential may be due to the fact that unlike Quicken, where account names in category fields were indicated by surrounding square brackets, iBank puts categories and account names in the same namespace. This increases the number of strings that will match the first letter or two of user input in a category field. This is neither good nor bad, but may contribute to the speed issue.
But some of it is just poor prioritizing. Ten minutes into an iBank session, it suddenly decides to “update all accounts.” It pegs the CPU meters (I’ve seen 120%) while almost totally ignoring user interaction. When it’s in this mode, and you’re trying to enter a new manual transaction, it keeps asking you if you want to save your changes—if you say yes, it closes your current entry with whatever incomplete data you already had in it.
If you open iBank with the intent of entering a manual transaction or two, be prepared for iBank’s default processing to get in your way. First, it will download everything from all your financial institutions (even if it’s already done that earlier in the day). If it’s the first time you opened iBank today, the scheduled transactions will appear and demand to be processed, derailing your train of thought. Only after all iBank’s bookkeeping is done can you finally get around to yours. This is what I usually refer to as the “Microsoft model” (“what our software wants to do with your computer takes priority over what you want to do”), and I’m not a fan of it.
iBank’s report feature allows you to specify which categories should be included or excluded, and provides you a handy button to “flip” all the checkboxes. It also allows you to specify which accounts should be included (default is all, and you can’t choose “excluded” instead), but fails to provide the handy “flip” button. This means that if you want to create a report on one or two accounts only, you have to scroll down and click off every other account line. Similarly, the choices for reporting period are rich, save for the absence of one crucial one—”all transactions”—forcing the user to type in a “custom date range” instead. All of this slows down the interface, and should be trivial to address.
User interface issues
This is by far the largest class of issues. Each one is small, and none of them is a show-stopper, but hopefully we will see some of them fixed soon in an upcoming release.
Which hand giveth?
In Quicken, whether a transaction is a deposit or a withdrawal depends entirely on what column you put the amount in, and you are free to use either column when entering a new transaction. In iBank, each transaction is additionally marked individually as a “deposit” or “withdrawal,” which is not only redundant, but often contradictory. In many of my iBank ledgers, I have transactions marked as deposits whose amounts are in the withdrawal column, and vice versa, along with other transactions whose types match their columns. This is true of both converted and new transactions.
For now, I have given up predicting whether my manual entries in any given ledger should be characterized as deposits or withdrawals — I try both to see which one opens up an amount field in the proper column, and then stick with that one.
Time to move on
Like Quicken, iBank will show you the possibilities to complete what you’re typing, but unlike Quicken, if you hit tab to accept one of them, it will simply finish the entry and leave you in the same field, instead of finishing the entry and moving you to the next field. This is a less-then-optimal choice that slows down the typist, and occurs in a number of other contexts as well.
On a similar topic, iBank is not at all consistent in providing you with a useful cursor focus. For example, when you are attaching an account to an online financial institution, iBank asks you to type the name of your bank, and supplies a field. You begin typing, only to hear “plonk! plonk!” because your cursor is not actually in that field; you first have to hit tab or click inside the field, an unnecessary effort. Similarly, you are in “no field” when you create a new manual transaction, and in a number of other iBank interactions.
Some windows are more equal than others
Quicken allows you to bring up windows for several accounts on your screen. iBank allows you to pull up auxiliary windows for additional accounts, but they don’t have the same functionality as the “main” window. For example, you can delete an existing transaction only in the main window–the auxiliary windows will ignore you if you try it.
In fact, the delete operation is even more problematic: even if you select a transaction in the main window and try to delete it, you will be ignored unless you have actually placed your cursor inside an individual field in that transaction—then the transaction will be deleted.
Spread (out) sheet
Quicken has always suffered from an annoying “menu bar” across the top of the screen that limits where you can place any of their account windows, even when it is not the frontmost application. This limits your screen layout flexibility when you are trying to compare a Quicken account with some other ledger (like a screen shot from another account file).
iBank’s “Open in separate window” has a much smaller no-man’s-land area in this regard. Unfortunately, each iBank ledger line is about 50% taller than its Quicken counterpart, so fewer of them fit on a page, making ledger comparisons more unwieldy after all.
Strictly lunar logic
Earlier, I mentioned that scheduled transactions won’t convert and have to be reentered by hand. Now, iBank does have a shortcut method of allowing you to choose existing transactions and convert them to scheduled transactions, but the results are often less than satisfactory unless the bulk of your scheduled transactions are monthly.
The shortcut simply adds one month to the original date, and schedules the transaction every month. If you have a significant number of annual, twice-annual, or quarterly repeating transactions, it’s almost more effort to correct the resulting entry by hand than it would’ve been to type it in from scratch.
Let automatic be automatic
In Quicken, it’s possible to create scheduled transactions in a “just do it and shut up” mode, whereby the transactions are automatically entered on the correct date without requiring any human interaction. Unfortunately, iBank requires human interaction for every scheduled transaction. It allows you to choose how far in advance this human interaction will be solicited—if at all—but if you don’t remember to go in manually and process them, they won’t be processed.
Quicken also allows you to indicate that a transaction is due periodically, but that the amount will vary, so it will ask you for the correct amount before entering it. iBank has no concept of varying amounts– if you schedule a transaction, it will be for a constant amount.
Quicken’s approach to downloading information from your financial institutions is that you request a session manually, after which it presents you with a list of new transactions it found, and asks you to do the proper thing with each of them.
iBank provides a lot less handholding — it automatically downloads your information every time you open an account (somewhat less efficient), but then depends on you to remember to perform the necessary post-processing.
Dude, where’s my transaction?
iBank’s approach to searching is much less comprehensive than Quicken’s. If you want to find all transactions from “John Cooper,” you type that into a search field at the top of an account window. But if he appears in more than one account, you have to open each account individually and do this for every one. And some windows, like “Scheduled Transactions,” have no search field at all, so you are stuck searching by eye (resorting by payee helps). Quicken, in which you can just hit command-F and search pretty much everything and anything, gets the nod here.
Please sir, can I have no more?
To signify that there are new downloaded transactions that require your attention, a number appears next to each account name with new transactions you need to review. Unfortunately, there’s currently no way to indicate to iBank that you have acknowledged or approved any given transaction — so if you are conscientious about addressing accounts with non-zero numbers, you will often find yourself reviewing, over and over, the same acceptable transactions you have already reviewed. The numbers next to the accounts won’t reset until the next day’s download.
Similarly, in the Quicken world, each individual transaction was downloaded exactly once. Once you decided what to do with a downloaded transaction, you never saw it again.
In iBank, if the recipient of a check waits several weeks to cash it, iBank won’t “match” it to your manually-entered transaction from several weeks earlier, but will present it as a new transaction.
If (using the Quicken method) you delete the “duplicate” downloaded transaction to make it go away, it will keep reappearing every time you download transactions. You have to drag it down to the original transaction to “merge” it and keep it from reappearing. (This is a handy feature, it’s just that the connection between using it and making a transaction stop appearing over and over is non-intuitive.)
Quicken enters automatically-scheduled transactions in alphabetical order of payee, an aid to certain tracking strategies. iBank enters them in no particular order. (But a bonus: iBank allows you to drag transactions within a given date to rearrange their order, which Quicken doesn’t.)
iBank’s scheduled transactions let you choose a period of weeks, months, or years… but not days! If you have a biller who bills every 30 days (he says, “this is a normal business standard,” but I’ve never seen another biller do this), you’re out of luck.
Here are the aspects in which I find that iBank shines compared to the old regime.
For online connectivity, iBank is the champion. It can communicate with every financial institution I deal with, including PayPal and one credit card holder that Quicken has never been able to talk to, plus an investment firm that Quicken hasn’t been able to talk to for about six months. True, some of these institutions are reachable only through IGG’s “Direct Access” pay service, but I find the annual subscription rate reasonable for the work I save and the 100% connectivity I achieve.
iBank has a control that allows you to view only the “uncleared” transactions in an account, which is a great timesaver. It would be an even better feature if it recomputed the “totals” column to reflect the uncleared total, instead of just reprising the useless account total figure from the original transaction position.
Similarly, iBank allows you to “reconcile” any account you define; as opposed to Quicken, which only let you reconcile bank, credit card, and securities accounts. I’ve wanted this capability forever, and will be making good use of it now.
iBank’s “check number’ field is long enough to store the “transaction codes” and “validation codes” you get when making online payments or transfers. Quicken 2007’s fields are tiny—inadequate for today’s e-commerce environment.
In the same manner, iBank can handle bank password requirements as they are defined today. Many institutions are now imposing longer minimum lengths and minimum numbers of digits and/or symbols in your passwords. Quicken 2007 is still apparently enforcing the limitations these banks had back in 2007, which were much more modest. When choosing passwords, people who still use Quicken 2007 are being squeezed by the ever-eroding common ground between the requirements of the bank (“it can’t be too short or simple”) and of Quicken (“it can’t be too long or complicated”).
iBank allows you to have more than one account file open at the same time. How many years I wished that Quicken could do that, but it was utterly incapable. I keep separate files for two family-owned businesses as well as my personal accounts, and whenever I had to transfer money between them, the resulting ethnic fire drill was ludicrous.
Finally, iBank offers you a 30-day free trial period of both their software and their “Direct Access” service. Intuit wouldn’t do that for Mother Theresa.
It should be clear to anyone who has read this far that iBank is far from a “Quicken clone.” IGG Software has constructed their own unique philosophy of what approach works best for bookkeeping, and it has significant differences from Intuit’s.
Expect a non-trivial learning curve and a non-foolproof conversion process, but look forward to an experience mitigated by the refreshing ability to get the immediate support that you never, ever could from the purveyors of Quicken.
Making OS X—and occasionally iOS—just a little clearer for you.