Wednesday, May 16, 2012

eNom Doesn't Care about their Credit Card UI

Almost 12 months ago we reported to eNom that their user interface had a bug. The issue causes an inconvience for users but, it's not fatal. Sadly, it's an easy fix too - but eNom just has done nothing. Lazy.

The eNom Bug

On the account refill page users are presented with form, which includes some account, including phone number. Notice, and this is the bug, that the phone number is mangled on this form. Other parts of the eNom system display this phone number correctly, including their WHOIS data.

Not a serious bug right? The problem is that, when using the refill form customers (like us) don't pay much attention to that field. Why would we? The phone number was set when we created the account and our number has been the same the whole time. But it mangles our data when we save.

Also, how lame is it to have a broken form on your website? Lame. How lame is it when that form is the credit card form? Double lame. Hard to have confidence in a company that cannot manage something so simple as phone number data.

Friday, April 13, 2012

See You in Hell Blogger

Blogs are dead, or at least this one is. It's so "2000 & late" to be blogging so we're dropping it.

The fad known as blogging is over, "it's dead Jim". The functionality that it used to offer is now replaced by Twitter (worthless), Facebook, Tumbler and Google+ streams (among others). So, stop blogging and start stream-posting! (streamcasting?).

It was kind of nice to be able to replay the Blog feed to our home-page, which is not possible from Google+ (unless using Blstr!) but that was only a marginal gain.

We'll continue to publish useful information about Linux on our Praxis site, about coding web-applications on our Radix site, performance monitoring on Custos and other useful information on our primary site.

Blogging is dead, moving on.

Thursday, March 22, 2012

Google Plus Stream as Atom/RSS Feed - Nope!

It's not possible! Dang! Their system, for some odd reason doesn't expose a users public stream as an RSS/Atom or other consumable content.

It's odd, so many other services provide this. With Google Plus however you cannot, they simply don't offer it.

There was an offering on http://plusfeed.appspot.com/ but that service is now offline.

And are many other's talking about this exact same issue.

There is also a service provided by Yahoo that converts pages to XML or other feed types. But lately it's been throwing some 500 level errors.

We've come up with a solution however, you can use the services at Blstr! Plus Feed to make this work.

Tuesday, March 6, 2012

Symantec / GeoTrust Can't Parse CSR - Force SSL Renewal

Clearly someone doesn't know how to properly parse a CSR; and furthermore their organization is crap at communicating with customers. This article documents the situation; names and emails have been changed to protect the innocent.

On the 5th of Feb we were issued a new wild-card certificate provided by GeoTrust (Symantec) purchased via eNom. We submitted the CSR and responded to their confirmation emails. The certificate was installed as has been operational across dozens of sites for about 30 days.

On March 06 we recieve an email which notifies us that the certificate will be revoked because:

The organization name verified with your business registration documents indicates Company, Inc, it is not the organization name listed in your CSR which is host@company.com.

Everyone reading this should know the difference between a company name "Company, Inc." and an email address. But clearly, someone/something in the Symantec/GeoTrust/eNom system does not.

Symantec/GeoTrust Processing Failures

Now, one may assume from this reading that perhaps we submitted our CSR wrong; I mean how else could a company name and email get confused? So I instantly went to inspect our CSR, the relevant portions are shown (but changed to protect the innocent)

Subject: C=US, ST=New Mexico, L=Albuquerque, O=Company, Inc, OU=Engineering, CN=*.company.com

No problems there, the "O" is properly set to our company name. So, how did the address get mangled?

I went to our sites to take a look at what the Subject on our certificate was listed as and imagine my surprise when I discovered that someone had parsed it so incorrectly that our email address was now our organization.

Subject: C=US, ST=New Mexico, L=Albuquerque, O=host@company.com, OU = Engineering, CN=*.company.com

Guesses on Causes

Somehow, after submitting a proper CSR and then clicking the link in the email they sent us mangled our CSR so badly that GeoTrust has to revoke that one and issue a new one. The only point where the email address was introduced to the process was on the "other end&quo;. That is, eNom, GeoTrust or Symantec added that to the mix, not us. So, to my mind that means they caused it.

Impossible Tasks

So, on March 6th we were notified that our certificate would be revoked on the 7th and we need to re-enroll. A task they gave us less than 24 hours to complete. Unfortunately their certificate generation takes more than 24 hours. Their incompetence causes our certificate to be revoked w/o ample time to respond to the issue.

Customer Communications Fail

The email they notified us comes from elizabeth_olaya@symantec.com, but it's about GeoTrust - they should be using a consistent company name - especially when dealing with security issues.

The phone numbers listed on the email don't ring back to Symantec or GeoTrust - Elizabeth you need to fix your message signature to point to the proper phone number!

Update #1

After wasting more than an hour on the phone with both GeoTrust/Symantec and eNom (at the same time) the issue was finally resolved. GeoTrust has extended our revocation date while we re-order. Then GeoTrust issues refund to eNom who should then issue the refund to us (but only as credits in their system).

Just for grins I'm using the same CSR that I used from the previous request. However, this time I'm not submitting via eNom; we're using GeoTrust directly. So, we'll see if the organization & email address get mangled again.

Friday, February 10, 2012

How Wells Fargo Cost my Business $5000

We've been banking with Wells Fargo since Edoceo started in 2001. Some recent incompetence by Wells Fargo ("WF") has caused us to re-evaluate that position.

Mis-Represented Fees

When we started there and opened the three standard accounts (Checking, Savings, Line of Credit) they were all linked together. We were told that if we had enough assets (or liabilities) with WF that fees for these accounts would be waived. Naturally, this appealed to us.

So, the owners personal banking moved to WF, a second business interest also created accounts there. The sum total of these accounts was well over their minimum threshold to waive the fees. It met the requirements we were told about: the assets of this one natural-person exceeded the base-line set by WF.

However, the fees were not waived. We had few in-branch visits, brought this to the attention of the tellers, who said it would be resolved. They manually reversed fees; but next month they were back. This process continued for a few months.

Then, on one visit we were told that we didn't meet their minimum asset requirements; It isn't the sum-total of assets from one natural-person; it's measured per account operator (Edoceo, the Owner and one other business interest). So, despite meeting the requirements stated to us by in-person bankers we're still charged fees.

We were told that if we did an automatic transfer that fees would be waived; so we set that up. Guess what? Still charged fees.

Those account fees, bill-pay fees have a sum-total over $2000. That number doesn't include any penalties or other charges - it's just account fees.

Failure to Auto-Pay

When our three business accounts were created we had them all tied together - as advised by the banking staff. The Line of Credit; attached to our checking was subscribed to auto-pay (a very common practice). That process worked properly for quite some time. In about 2008 that stopped for some unknown reason. As a result we missed two payments against that LoC; which caused the rates to sky-rocket and cost fees.

We went into a branch, spoke to a teller who apologised for their mistake. Told me they were re-enabling the auto-pay feature and that all would be OK. Auto-pay then worked properly for 2008 and 2009 but again magically stopped towards the end of 2010.

Talking to the bank about it again we were told it was never configured to auto-pay (but how did it for the previous nine years?). We were asked to fill out and sign some form, in the branch, to re-enable auto-pay. We've done that (twice now) and auto-pay is still not working properly.

The Address Debacle

This one has cost the most head-ache; Wells Fargo cannot seem to get our address correct.

When the office moved in 2008 we dutifully went to the on-line banking application and update our address in their system. As of 2012 the old address is still floating around their system (and impacts us later). In 2011 our statements and other forms suddenly reverted to the previous address, w/o warning. And, oddly, a change of address was sent to notify us - but that notification also went to the pre-2008 address. We missed statements and other necessary business information due to this error by WF.

Going back into the on-line banking system we again corrected our address. Change notification was sent, and we thought all was well. Until again in 2012 we noticed that WF was issue tax documents for our business that again had that four year old address. It also contained the WRONG COMPANY NAME.

We've spent more than 10 hours in the branch or on the phone with WF to attempt to correct this issue. Each time the representative from WF said it would be fixed once-and-for all. Imagine our surprise when, just yesterday, we received forms from the bank - which again had the wrong company name and address.

This clearly demonstrates that Wells Fargo cannot even manage even the simplest set of data for their customers.

Unauthorised Account Creation

This was the biggest disaster (so far). Towards the end of 2011 we received a call from a banker at Wells Fargo. Paul told us there was a way that we could reduce our account fees if we simply switched our account package from A to B. We told him we were interested.

A few days later we discovered that we had six, yes six, new accounts a Wells Fargo - two new checking, two new savings and two new LoC accounts. What was really odd is that the account numbers for these new account were different by only five numbers. As if this guy Paul created new accounts for us; then repeated the process. I hope those six new accounts helped put him over his new account quota for the month.

We've had to cancel/close those accounts; but not before paying some fees for those accounts - which we never authorised in the first place. Not to mention the fact that it took three requests (one phone, two in branch) to get those accounts to properly close.

Bottom Line

Mis-representing their products and disabling the auto-pay has increased our fees and charges with the bank. Repeated mistakes with our address has cost us time & time & time. Expensive time; missing bank-statements because they went to the wrong address (again and again) costs a small business time and money they don't have. And those unauthorised new accounts, cost again time and money to get resolved.

It's not a stretch; by any measure to conclude that we've spent not only a good deal of cash-money dealing with their incompetence but also (and more importantly) we've had to use our valuable time to correct their mistakes. For a small business operator that time is valuable - every hour spent in branch or on the phone to fix what WF broke is time we cannot bill for.

So, yes, obviously, after reviewing our situation it's unlikely that we'll continue with WF; nor would we recommend their services to anyone. It appears that the small-local banks might be the better option for your small business.

Monday, January 2, 2012

The Trouble with NetSol

One of our clients hosts their domain and DNS with Network Solutions ("NetSol") (their first mistake).
For those who don't know: NetSol is the oldest, more arcane domain services provider.


Today, we wanted to update some DNS records (A, CNAME). An easy task with other providers such as eNom or GoDaddy.
Here is the story.
For references "@" is the domain name in question, a common


Cannot Delete A Record for www.
Our first step was to remove the A record for the www. entry, which we wanted to replace with a CNAME.
In the DNS manager provided by NetSol we check a box labelled "Delete" and press save.
The record was not deleted, the IP address portion was, but the entry it-self was not.
The result was that a lookup for "www.@" was simply empty. WTF?


We contacted support, and after more than 20 minutes of navigating the IVR and waiting we were connected with a CSR who mumbled and didn't know a freaking thing about DNS.


We explained to them our issue, which they didn't understand.
After repeating 'We want to delete the A record for WWW' about a dozen time they got it.


The CSR then looked at our account, made some adjustments and asked us to verify.
All the entries were gone! What the FUCK?!
Except, that the 'A' record section of their manage won't allow us to remove the entry for 'www', it's hard coded.
What an epic fail.


So, now we had to re-create all the A records the previously existed.
Good thing we had documentation.


So we tried the whole process again.
Checked the "Delete" box next to www again and selected delete.
Waited for their slow caching system to referesh the data (five minutes) and saw the same results.
The A record persists, with a blank entry, and prevents us from creating a CNAME record for www..


In short, the DNS "Manager" provided by NetSol is a flaming pile of crap.


How to Fix It

Firstly, NetSol, could improve their system so that it actually functions, uses caching properly and allows the user to manage A, CNAME and other records with full authority.

Another option is to choose an alternate DNS provider - such as that provided by eNom or GoDaddy (or dozens of others).


For us, we assisted the customer with migrating their domains out of NetSol.

Friday, December 16, 2011

Moving Mail via IMAP from Account to Another

Most of the hosting providers these days provide for IMAP access to your mailbox.
This is great, but what if you want to move messages from one IMAP account to another?
We wrote this little tool for it: imap-move.


The IMAP Move tool was written with a few, very specific, intended purposes but there could be others.


  1. Archive messages from IMAP into a local directory
  2. Move message from one Mailbox to another Mail Account

The tool keeps track of the moved message (by mail message ID) so it can be run over and over on the same source mailbox w/o having to repeat it's work - this can save time when you have 40k+ messages.


List the Source Folders/Labels

imap-move.php -s imap-ssl://user@domain:password@imap.gmail.com:993/ --list

Source: user@domain
01 Follow up; 0 messages 0 bytes
02 INBOX; 1080 messages 108104263 bytes
03 Misc; 0 messages 0 bytes
04 Priority; 0 messages 0 bytes
05 [Gmail]; skip [container only]
06 [Gmail]/All Mail; skip [skip list]
07 [Gmail]/Drafts; skip [skip list]
08 [Gmail]/Sent Mail; skip [skip list]
09 [Gmail]/Spam; skip [skip list]
10 [Gmail]/Starred; skip [skip list]
11 [Gmail]/Trash; skip [skip list]
11 Folders, 1080 messages, 108104263 bytes

Copy to Local Directory

Please note, this is not a MAILDIR (or, at least I don't think it is)

imap-move.php \
  -s imap-ssl://user@domain:password@imap.gmail.com:993/ \
  --copy /path/to/storage

Copy one IMAP Account to Another

This can take a long time, the application has a lot of spew, maybe use |tee or something.

imap-move.php \
  -s imap-ssl://user@domain:password@imap.gmail.com:993/ \
  -t imap-ssl://noob@domain:password@imap.gmail.com:993/ \
  --move \
  --copy