Retiring domain associated with a DreamHost WordPress site - migrating site content to a new domain

I recently decided not to renew a domain managed and registered with DreamHost. That domain had an associated WordPress site. This is the sequence I followed to preserve the content of the site.

1. Turned off renewal for the domain (domain_old).
2. In WordPress for domain_old I exported the site as a XML file which I downloaded and archived.
3. In DreamHost control panel Manage Websites I clicked "new website". This let me add a subdomain to one of my existing domains.
4. In DreamHost control panel Manage Websites I clicked on domain_old and scrolled down to entry for Domain. That says "change your WordPress site to run under a different domain name". I chose the subdomain I created earlier. This took about 5-10 minutes to run.
5. When I then visited the subdomain I created the WordPress site came up.

The process only took a few minutes the first time I tried.

Google Apps (Workspace) email failing? How to check DKIM and update in your DNS settings if needed.

When I travel every bit of IT in our family starts to malfunction. On a recent trip this included Emily's emails, they were intermittently rejected by Gmail recipients. Once I was home I had to dig up old knowledge; I found the answers in prior blog posts (see references below). It looks like something wiped out our Dreamhost DNS DKIM records a few weeks ago [1]. 

It's hard these days to do email with anything that's not full hosted on the big three.

The refs have more detail but here's the outline of the process:

1. In Google Workspace - Apps - Gmail - Authenticate email get the DKIM text value. You will probably have to generate a new record.
2. In Dreamhost control panel manage websites click on DNS settings for domain and enter google._domainkey as host and the TXT record value. (DH UI makes this look like it appends a suffix to this but it really doesn't.)
3. Once DH says the record has propagated return to the Admin console and click "start authentication"

It can take 48 hours for this to fully propagate but a few minutes after adding the key it did work when I validated as below.

To see if DKIM is working follow the process Google outlines (Usual automated testing services don't work with the way Google Apps do DKIM -- the selector won't work):

Send an email message to someone who is using Gmail or Google Workspace. (You can't verify DKIM is on by sending yourself a test message.) 

In the message header, look for Authentication-Results. Receiving services use different formats for incoming message headers, however the DKIM results should say something like DKIM=pass or DKIM=OK.

If the message header doesn't include a line about DKIM, messages sent from your domain aren't signed with DKIM.

When I looked at view original sent form Emily's account to my personal gmail account I didn't see DKIM=pass or DKIM=OK but I did see two entries starting with:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 

More importantly when I scrolled up a bit (this is in Gmail View Original) I saw a header that's interpreting the email headers (I think this might be a newer feature):

Message ID ....

Created at: Mon, Mar 13, 2023 at 2:59 PM (Delivered after 12 seconds)

From: Emily ....

To: John ...

Subject: test DKIM content

SPF: NEUTRAL with IP ...

DKIM: 'PASS' with domain ...

You can also paste the "original message" headers into toolbox.googleapps.com/apps/messageheader/. That gave similar results.

When I tested on a second family domain that did NOT have DNS TXT entry for DKIM it showed as DKIM 'PASS" in the email header interpretation with an odd domain string -- BUT in Google Apps it showed as NOT authenticating. I cannot explain this. 

Once I updated the DNS TXT DKIM entry for that domain and allowed a few minutes for propagation it did show in the Google Apps admin console as authenticating with DKIM and the headers showed the correct domain name.

DH's note on SPF records says they cannot be updated if we are using Google Workspace. This is new since 2018 and I think that's correct.

- fn -

[1] Eons ago every Dreamhosted domain had a free option to add Google Apps (now Google Workspace). That went away and earlier this year Google said they would discontinue the legacy free Google Apps. That was a thrash but on the edge of doom Google relented. I figured a DH script wiped the records but their first tier support said they hadn't done anything and instead referred to Google automated scripts that might change their DNS records (!).

- refs -

• Google - turn on DKIM for domains
• Google - troubleshoot DKIM issues
• Dreamhost DKIM records
• Check DKIM and SPF records
• Check DKIM records
• DKIM for Google Apps 2011 (easier then because we used a DNS service tied to Google. There's an analogous fix for Google Apps 2023 if you use their DNS. Yeah, I know they don't call it Google Apps any more.)
• Dreamhost SPF 2018 (looks like they were screwing up DKIM settings back then as well)
• How to get Google to DKIM authenticate your domain (2022)
• Dreamhost SPF records: "If you're using Google Workspace, you cannot update the SPF record. The field remains uneditable."

How to leave Google Apps / G Suite / Google Workspace

UPDATE: As of early May 2022 Google has relented and will allow continued personal use of legacy G Suite domains. You need to login to your domain and then use this URL. (The option is described, a bit obscurely, in a support page).

<background>

It's hard to remember now, but there was a time that geeks had some affection for both Google and Apple (but, TBH, never Microsoft). Those were the glory days my friend.

This year's bitter resentment is brought to you by Google ending free Google Apps services. Back in the glory days Dreamhost bundled these with domains, I picked up 7-9 of them. Two of these Google App domains have been heavily used by my family. They are the core of a wide range of daily things we do, including email addresses association with numerous logins, credentials, passwords, and so on. (But not with Google OAUTH identity services, that is not supported for Google Apps email addresses.)

A few months ago, in early 2022, Google told us that these services, once as permanent as gmail (*cough*, they're coming for you), would become quite expensive. For us the costs to maintain our current setup would be hundreds to thousands of dollars a year. Shortly after this announcement we were told that there *might* be a reprieve, that non-business services would continue. This false-hope was never officially withdrawn, but in May 2022 it has been replaced by a bizarre offer to maybe continue but, like, without email or domain?

Google's very limited online guidance does not review how to exit Google Suite. In email communications they mention a 'suspended state' but do not describe what that means.

So now I have to spend several lovely days in May sitting at my computer trying to salvage our digital identities. We will clearly have to pay for at least one of our domains - principles be damned. Charges begin Aug 1, 2022. </background>

The following is a rough guide to what I will do. Much of this requires knowledge from decades ago that I'm having to refresh.

Considerations and discoveries

1. It's difficult to move IMAP emails between services. IMAP emails can be copied to a local store. In mail. app I've had success dragging and dropping emails from one IMAP inbox to another, but I believe this is fragile and unreliable. You can also copy, see this iCloud example.
2. Local store email is barely supported any more. Mail.app, for example, 
3. My domains are managed by Dreamhost which does provide some classic web services though fewer than it once did.
4. Domain based email forwarding is fragile -- many services including google will reject it. See DKIM notes below.
5. Modern email is both essential and a river of spam and Google has good spam filtering (though it was better once)
6. The knowledge of how to manage DNS settings is more esoteric now than it once was, and Google Search no longer works.
7. My Dreamhost DNS and mail forwarding has lots of old detritus. That's on me!

References related to closing Google Workspace accounts

1. Microsoft on switching to Office 365 - cancel subscription
2. Fastmail also has switching options, but price not much less that Google Workspace
3. Google has not provided any migration guidance.
4. You close your account by canceling the subscription: https://admin.google.com/ac/billing/subscriptions/ then deleting the account (see below).

References for migrating to Dreamhost email services

1. Dreamhost email client configuration
2. The Dreamhost custom MX config panel has 'uses Gmail' management links that take you to Google admin (so not terribly useful but at least can tell what to change.
3. Dreamhost used to support both a mailbox and a forwarding action but you can't do that any more (still works for old settings). Dreamhost uses Roundcube Webmail but has not enabled forwarding in that app. You can use forwarding directly from a domain but I think Google treats emails forwarded this way as spam. (At one time we were supposed to have had quite large storage caps with Dreamhost, but I think email overwhelmed them. Similar to the days our Gmail storage was to be unlimited.)
4. A comment on this post mentioned imap sync for moving email: "For transferring IMAP email, imapsync works well. There's a free version you can download and run on your computer (or on your hosting provider if you have ssh access). It's well documented and relatively easy to get your head around, and is fast and reliable. I’ve not got any affiliation, but someone pointed me to it a couple of years ago, and I’ve since used imapsync to migrate email hosts for a small organisation. Highly recommended."

References for migrating to Apple iCloud+ email

Apple supports custom domains with iCloud+ email including family sharing.

1. You can assign up to 5 domains to a family group and for each domain each member can have up to 3 email addresses.
2. Apple will instruct on how to do DNS settings (there's a bug in the quotes apparently) - there's also a tech note on DNS settings.
3. Useful twitter stream on migration to iCloud
4. Detailed twitter thread on migration - Google takeout mbox, import into Mail, then drag from local to iCloud.

My steps to closing an essentially unused account where I didn't worry about forwarding

1. Go to Google admin console for account.
2. Review how many users exist. (typically one)
3. For that user review email to see if there's anything important, sites, docs, etc. Don't forget google  voice!
4. From Google Admin account cancel your subscription. Now pay close attention so you don't miss the next step - delete your account (https://admin.google.com/ac/companyprofile/accountmanagement)

When you choose to delete account you see:

Now return to Dreamhost

1. Go to DNS for domain and delete the Google CNAME records
2. Go Custom MX controls and Choose "make me regular email". It may take hours for this to work.
3. At this point Dreamhost enables webmail. But I wonder if this actually blocks email forwarding even if you set that up! (The lack of warning doesn't give me a happy feeling about Dreamhost TBH.) So disable webmail. Dreamhost also has a control panel for email forwarding that I think is a disabled feature.) - NEED TO TEST MORE HERE
4. Go to Manage Email and set up a forwarding account as needed. This can take a while. Apple picked up the DNS changes within about 15-30 minutes, but Google took 1-2h. (I wonder if DNS propagation in general works as well as it once did.)
5. Enable DKIM if not already enabled.

Migrating from Blogger to WordPress ... again ...

I’ve been contemplating migration to WordPress for almost a decade, but Google kept Blogger good enough to keep that headache at bay.

Alas, the days of good enough are ending. Google is removing their photo management API without recourse. They do support posts with images, but only by using their web interface. It’s a concrete and undeniable sign that Blogger is either dead or going to a bad place.

I though I’d migrate first to wordpress.com then to my Dreamhost open source wp install, but via Twitter Daniel Jalkut tells me he got better results using the open source importer directly.

I’ll do a dry run on one of my big blogs first. The URL won’t change but I’m sure feed subscriptions will have to be redone (ugh).

Update 2019/04/06 - results of the pipdig import process

I tested the Dreamhost free version of the pipdig importer from a Dreamhost wordpress (open source) blog. The results can be seen here for the moment, I’ll eventually delete them. I found:

• It doesn't remap internal links. This is a big disappointment. Links continue to direct to blogger, once that account is gone they will be invalid
• There’s no option to migrate images that I can see.
• It missed at least 4 posts from the source blog — specifically from early on. No idea why and it suggests more are missing.
• It does copy drafts over.
• It requires a LOT of access to your Google account! If you use this utility I suggest creating a new google account, give it access to your blog, then after the import destroy it. 
• The paragraph breaks are missing - line feeds vs <p>. This is an ancient Blogger problem with MarsEdit; a legacy of the original sin of English language text formatting end-of-line standards. I think Blogger is mostly to blame.
• Images were not relocated locally, they remain at their original locations.

Pipdig is better than nothing, but I’m going to try wordpress.com’s import tool next. I wonder if a better solution wouldn’t be a static site that I could archive on my personal web server, then do a web server redirect to handle the links. For now I’m still on Blogger. The porting experience reminds me of the impossibility of leaving Apple’s defunct Aperture photo management app.

(As I write this the wordpress import is processing - result should eventually show up at gordontest.tech.blog temporarily, but we’ll see if it works. It’s taking a long time.)

Update 2019/04/06b

Well, that wordpress migration didn’t go so well:

Your site has been suspended from WordPress.com for violating the Terms of Service. If you believe this was done in error, please contact us as soon as possible to have the suspension reviewed….

I sent a contact inquiry, nothing yet.

Enabling SPF on Dreamhost accounts

Dreamhost writes about SPF:

SPF overview – DreamHost

… Mail servers that receive an email for delivery can check SPF by comparing the sending server’s IP address against the email's envelope sender's SPF DNS record. If the email was sent from a server that is not included in that SPF record, the email is more likely to be spoofed or untrustworthy. The receiving mail server may handle the email differently because of the SPF failure, such as marking the email as spam or rejecting the email…

and

What SPF records do I use? – DreamHost

If you’re hosting your email at DreamHost, no changes need to be made to your SPF records. DreamHost’s SPF records are generated automatically and should work without any issues or additional changes.

IP's in DreamHost’s SPF records include mail servers and the relay machine IP addresses.

Except this isn’t true. When I was investigating my family’s Google email Hell I found that emails sent from DH Webmail didn’t have SFP records in the header. I tested using mxtoolbox.com, Kitterman, and by inspecting emails in Gmail using the ‘view original’ option. I also directly inspected my DNS settings. No SFP.

When I asked DH tech support admitted their documentation was wrong and responded (emphases mine):

If it were, you'd see the SPF setup on the 'Manage Domains' > 'DNS' pageby default for every domain hosting mail with us along with the DKIM
 that's already there, but SPF is NOT set by default (at this time).

… we should start setting it by default, so that info above may be accurate in the future. We’re doing a lot with emails right now, which is still mostly in the discussion phase, so this is likely something that’ll come up as well what with various hosts starting to strengthen their incoming filters to help stop spam.”

For the domain in question, I’ve added the record for you through the 'Manage Domains' > 'DNS' page as a TXT record:

… We have now added the TXT record for .faughnan.com with value v=spf1 include:netblocks.dreamhost.com. Our DNS servers will start serving this
record within a couple of minutes.

My DNS records now show an SFP TXT record:

v=spf1 include:netblocks.dreamhost.com

Unfortunately adding the SPF didn’t help with Google treating my DH redirects as spam. I have a hunch those come from DH’s own SMTP service (homiemail) and that service might have a reputational issue with Google, but I don’t really know what’s going on. I don’t think anyone does any more.

What about DKIM?

DH claims DKIM is set automatically and I can confirm that works, at least for a domain that was relatively recently added to DH. On the other hand when I examine that domain’s DNS settings I see several records not in my older domain. I wonder if DH has never updated DNS settings for older domains, such that they are now obsolete. OTOH, even for a new domain there were no SPF records.

And then there’s Google domain verification (postmaster services). I turned those on my adding their key to a TXT field, but a few days later it wasn’t there any more. I assume DH removed it. I’m kind of losing confidence in Dreamhost.

Error in Dreamhost WordPress one-click installs - missing code in .htaccess causes 404 errors

I’m far from a WordPress expert. I’m not even a WordPress fan — it’s too complex and powerful for what I do. That complexity means it is also very vulnerable to attack.

So take what I write here with some doubt.

As best I can tell the default Dreamhost One-Click installation of WordPress has an error. At least it did for me. My hpmtb.org site was giving 404 errors. I installed the Redirection plugin and it wasn’t doing anything.

A blog post had a fix that worked for me. I used Transmit for macOS to open the install folders .htaccess file and added this code:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

The 404 error is gone now and I suspect the Redirection plugin will work if I need it. I have a hunch that using “pretty permalinks” (not the default of “id=“) might also fix this file — based on some documentation here: 

WordPress uses this file to manipulate how Apache serves files from its root directory, and subdirectories thereof. Most notably, WP modifies this file to be able to handle pretty permalinks.

This page may be used to restore a corrupted .htaccess file (e.g. a misbehaving plugin).

Did I mention that WordPress is too complicated?

DreamHost remixer - a brief trail

I tried DreamHost’s remixer web site dev tool. I was able to create a page with it. Reminds me a bit of Apple’s old iWeb. 

It doesn’t output static files though. It is mapped to a folder on my DreamHost site, but there’s some redirection behind the scenes.

That means it’s transient. When Remixer dies, so will all the content in it. It’s not portable either, I can’t move my Remixer work anywhere else.

Might be a good app for something transient, but the little I do on the web today I like to keep portable. WordPress is as far as I’m willing to go into things I can’t readily move and backup.

Mac web authoring for non-experts: My choices 2015.

In the beginning we wrote web pages in BBEdit and we FTPd them to a NeXT box.

Things progressed quickly. Almost two decades ago, when Microsoft FrontPage 97 was released and Macromedia created Dreamweaver, there were many powerful Windows applications for creating largely static web pages - with dynamic reflow based on HTML tables [1]. Operating systems, like Windows 95, shipped with a native web server. Netscape added Composer, fulfilling TBL’s original vision of the web as authoring environment. Non-technical users worked with server based systems, ultimately producing millions of web pages on sites like GeoCities [3].

Technology has moved in odd ways. There’s nothing quite like mass market FrontPage today, though Sharepoint Designer/Wiki came close and SeaMonkey survives. Dreamweaver is the strongest survivor of the original era, but it has evolved into a high end tool leased for $20 a month. I don’t think there’s a practical way to move Dreamweaver content to another platform, so adopting Dreamweaver is a deep commitment to the Adobe platform.

At one point I thought the Wiki would fill the vanishing mid-market niche [2], but Wiki solutions seem to have stalled out - much like WebDAV technologies. iWeb/MobileMe came and went quickly - an early sign of Apple’s decade (so far) of dysfunctional application development and fondness for destroying customer data.

Today developers hand code web sites in Coda, a programmer’s tool not so different from the BBEdit we started with. Other experts use Adobe's deep lock-in solutions, from Dreamweaver to Muse ($15/month) or open-source server-based WordPress (Less technical users some might use Blogger in a similar way).

For non-experts Weebly’s small business oriented server side authoring platform is an option, but it’s another deep data lock commitment to one vendor. Google Sites, amazingly, is still around, but focused on intranet solutions.

There are two longlived Mac desktop products both sold for $80 on the Mac App Store: RapidWeaver (presumably inspired by DreamWeaver) and Sandvox. I’ve tried both in the past, Sandvox more frequently than RapidWeaver. Neither product supports wysiwyg table authoring. RapidWeaver was last updated in January of 2014 and has three stars in the Mac App Store; it may be in maintenance mode. SandVox was last updated in April 2015 and has recently added a hosting service (revenue stream!), it has 4-5 star ratings. It’s App Store page still references iPhoto and Aperture however. Of these two I think Sandbox is more likely to make it to 2017.

It’s rarely mentioned anywhere, but TextEdit will export to well formatted HTML, and it even has table support (since 2006 at least). You can embed images and export — but only in single file “webarchive” format. As a simple page editor it’s not too bad, and it’s as standard as anything is these days, but the image limitations are a killer. (I suppose one could similarly author in Pages then view in Pages/web and export the code.)

Similarly one could author in Blogger or WordPress (example: free wordpress.com blog) wysiwyg mode, switch to HTML mode, and paste the HTML into a text editor (Coda?) for FTP upload. Or I could author in MarsEdit (as in this post) and similar export the HTML view as a file. Nisus Express and Pro both include HTML import and export; I don’t know how well their table export works and if embedded images are exported. When I last tried them years ago they weren’t a practical HTML authoring solution.

Google Docs work quite well for sharing and editing online, but they’re not useful for a root (www) web document. Very proprietary of course, but in some ways Google Docs are the closest thing we have today to the original view/edit vision of the www. I haven’t tried sharing iCloud Pages web sharing, but it seems like it would work similarly; it also can’t serve as root page of a web site.

Of the options today, what makes the most sense for me? There aren’t a lot of options on the table, so things should filter quickly with a few constraints:

• I’d like to avoid dying products.
• I want to be able to produce a reasonably pretty looking site without a lot of effort (iWeb pretty at least).
• I’d like a solution that works with Dreamhost and it’s (typical) constraints on www/domain mapping [4]. 
• I don’t want to sell my soul to Adobe. 
• I’m not a developer and web authoring isn’t my profession. 
• I really miss wysiwyg HTML tables and table based layout, but they are clearly gone. Still, I’d love basic table support.
• I’d prefer to avoid hard data lock.
• I’d like something that managed a site and updated links when I rearranged web page relationships or renamed pages.
• I’d like to avoid major malware and security issues. Static sites are very nice that way.
• Mac (or course) or Safari if server based.

Based on my review of the options, and applying my constraints, it’s easy to see that my best choice is ….  is …. Ok. Nothing survived the constraints. It’s easy to see why I’ve been struggling with this for about 15 years.

If I relax a few constraints I think my least bad options are WordPress (free) and Karelia Sandvox ($80). So I’m going to try both of those — and maybe, if only to close the long loop, Coda too.

Am I missing anything?

See also

• Vermeer/FrontPage lives in Sharepoint Wiki 6/2008
• Wiki impressions: XWiki 2/2012
• Advanced Web Refs 1998. State of the web a very long time ago.
• nVu - more good news on this FrontPage replacement 4/2005. It died years ago.
• Site Studio: FrontPage LITE for OS X 2004. Didn’t go anywhere.
• The sad state of web site authoring on OS X -- and XP 11/2005. I should have clarified that my complaint was about the mid-market niche, very much like today.
• Sandvox and the return of end-user web site authoring 1/2006. I’ve tried and rejected SandVox several times over the past 9 years.
• Content Management Systems: A Macintouch report 12/2005. 
• Google launches an AJAX web authoring and hosting application 9/2006. Google Page Creator came and went quickly, followed by Google Sites (2008) which, amazingly, is still around.
• Drupal reminds me of Google Page Creator 3/2009.  It’s still around, but the Dreamhost wiki page captures my sense of it: “WordPress … is less confusing and more stable..”. It’s not available as a “one-click install” on Dreamhost.
• iWeb doesn't do tables - and OS X HTML Editor alternatives 11/2009. 
• Components of a knowledge share solution 10/2011. Not much change since then.
• WordPress doesn't have a built-in table editor 1/2012. Still doesn’t.

- fn -

[1] I think we took the wrong road when we entirely substituted CSS for dynamic tables; no modern tool approaches the table management power of FrontPage 98. Perhaps this happened because it was insanely difficult to manage table authoring by hand, it was really a job computers did better than humans.

[2] Speaking of vanishing mid-market, remember when personal finance software was big? Intuit is trying to find a buyer for Quicken and its future looks quite bleak.

[3] The immolation of GeoCities, echoed on a smaller scale with the 2012 death of MobileMe’s iWeb based web pages, should not be forgotten.

[4] The odd handling of the www domain is, I think, a legacy of early net development. It is a pain in the butt.

Update 4/29/2016

Sandbox can be used free for up to 5 pages. I gave it a good try with a book site I’m working on. The lack of both drag-and-drop placement and tables made me give up on Sandbox. 

Of course RapidWeaver doesn’t do tables either, but I’m going to try it anyway.

It’s obvious that tables are insanely hard to implement; I wonder if CSS support made the challenge even greater. I wouldn’t mind an editor that handled CSS tables, but no tables at all reminds me of all the software functionality and value we have lost over the past 15 years (yeah, Apple Aperture, I miss you.)

Oh, and vendors, please stop trying to tell us we don’t really want tables or that HTML tables are fine. You are just insulting our intelligence. Just say something like “tables are extremely hard to do …”

Domain registrar transfer pains - something broken between eNom and Dreamhost (or me)

I've transferred several eNom domain with associated Google Apps services to Dreamhost. This is the first time I've been really stuck.

I'm trying to move kateva.org from eNom to Dreamhost. Dreamhost already provides DNS services, so it's "simply" a registrar transfer. I've done several of those.

This time the process is failing after I get an "authorization key" (EPP) from eNom/Google and I complete the Dreamhost authorization key submission. Instead of receiving a Google email (takes 1-2 hours):

STANDARDIZED FORM OF AUTHORIZATION
DOMAIN NAME TRANSFER - Confirmation of Registrar Transfer Request ...

I get radio silence. Tech support tells me Dreamhost's system shows a transfer status of denied ...

kateva.org Canceled - Invalid EPP/authorization key - Please contact current registrar to obtain correct key

We've been through this twice now with two keys. So I think something is broken (yes, user error cannot be ruled out, this is a complex process).

Unfortunately level one tech support doesn't know the details how this status shows up in their system. (They also can't explain why Dreamhost doesn't expose this status in the user accessible control panel or generate an email. I think there's a hole in their workflow process, but this could also be a bug in their system.)

At this point I'm hoping I can escalate to tier 2 support. Then I can interview somebody who should know how the status code is generated, and whether the bug is with Dreamhost (already known to have a process problem) or eNom (gonna be hard to talk to) or me (always possible).

Frustrating, but other than lost time worst likely outcome is I renew with eNom for another year. Then try again in 6 months and hope whatever is broken gets fixed.

Update 6/5/2015: Dreamhost tells me they're getting a formal transaction from eNom: "Invalid EPP/authorization key - Please contact current registrar to obtain correct key". So now I have to contact eNom at 425-274-4500. May the Force be with me.

Transferring eNom domain with associated Google Apps services to Dreamhost: 2015 Edition

It’s hard to imagine now, but once upon a time Google gave big stuff away. Until Dec 2012 anyone could get extended family Google Apps services and a companion domain for a pittance — $10 a year.  Today I still have most of the features of Google’s $50/user/year ’Apps for Work’, but I only pay for domain registration. [4]

Naturally I acquired quite a few Google Apps services, either directly from Google or through Dreamhost (referral link) [1]. Today I still have 10 Google Apps suites. 

The ones I got directly through Google were registered with eNom. This worked reasonably well until Google ended their first generation payment systems, so each eNom account had its own payment data and was completely independent from all others. Since then I’ve been slowly migrating accounts from eNom to Google.

Very slowly! I last moved a Google Apps associated eNom domain in 2009. Yeah, six years ago. [2] Over the past few weeks I’ve moved two more, enough that I’m getting the hang of it. The process is similar to what I wrote about years ago, but there are some added security steps.

I’m going to try to document what I did here — as much for me as for anyone else. Don’t trust what I write though — read Google’s documentation as well, they include registrar specific advice as well:

• Your domain host - Google Apps Help 
• Access DNS records from a partner host - Google Apps Help 
• Transfer your domain to another host - Google Apps Help
• Add a CNAME record - Google Apps Help
• Avoid bounced messages from new MX records - Google Apps Help
• Set up MX records - Google Apps Help
• Set up MX records (host-specific steps) - Google Apps Help

Key Concepts 

If you understand these concepts things are a lot simpler:

1. There are 3 independent services involved in this process:
1. Google Apps services
2. DNS services (primarily CNAME and MX, the latter is email specific and is particularly old and crotchety).
3. Registrar services (ex: management of kateva.org, including pointing to DNS services for Kateva.org wherever they might be.)
2. One business could provide all 3 services [3] or each service could be with a different service. Throughout the process below Google provided Google Services, but I started out with eNom providing both DNS and Registrar services. Then I moved DNS services to Dreamhost. Seven days later Registrar services completed their move to Dreamhost.
3. The things that connect a Domain to Google Apps are…
1. Google stores the name of the domain in its records
2. DNS entries that point to ghs.google.com. When you enter a URL the Domain Name Server sends the request to ghs.google.com, it looks up the domain name and handles it. (Similar magic for MX records).

Steps to follow

This assumes you’re paying for full featured Dreamhost hosting [1]. Quick steps here, more notes below.

1. Go to eNOM domain settings on Google Apps. Confirm contact information email works. Don’t use contact email that belongs to the domain you’re moving.
2. Go to Dreamhost, add the domain you’re going to move to Domains Hosted per DreamHost CNAME record instructions as a fully hosted domain under your Dreamhost username. Yes, you can and should do this before you actually move the domain. You’re setting up DNS services at Dreamhost and soon you’ll tell eNom to use those instead of eNom’s native services.
1. Go to Manage Domains and “Add Hosting” choose Fully Hosted. I put everything under my one username.
2. Click the box for Google Apps. Dreamhost will configure standard CNAMEs and especially MX records.
3. Add additional CNAMEs as needed: calendar, docs, drive, blog based on what you see in your eNom records. Don’t need to repeat DomainKey entry used to verify with Google (?). The A record that Dreamhost creates is used to redirect the naked domain to ‘www’.
3. Go to eNom settings and change eNOM DNS information to use Dreamhost. (ns1.dreamhost.com, etc) Once you do this eNom is now only your registrar.
4. Confirm DNS still works and can send email to address in domain. I’m not sure how long this takes, 
5. NOW, Request unlock of the eNom domain by email (see example below. Yes, by email and include your eNom password!). Once this is processed you’ll get two emails from Google, one with authorization key (EPP key).
6. Go to Dreamhost Reg Transfer, request transfer using the EPP key and complete form. Pay for new registrar service, seems to vary from $10 to $10 depending on domain. Initiate transfer. You’ll see a notice that a 7 day countdown has begun. Dreamhost shows something like this:
    
7. About 30-40 min later you’ll get an email from Dreamhost at your official domain email contact that you verified above. Click the link. Go to approval page. Agree. See “your response has been recorded”
8. Receive notice from Google in 1-2 hr (no action required unless wish to cancel)

   STANDARDIZED FORM OF AUTHORIZATION
   DOMAIN NAME TRANSFER - Confirmation of Registrar Transfer Request

9. Receive notice after 7 days that is complete. Now go to Dreamhost. Lock the domain. Enable auto-renewal. Test email and google services.
10. LAST: Google tries to renew registration, fails, sends note domain moved. However, Google never fixes up its Domain settings on the legacy account, they always show “enom” (sic) as registrar.

Sample of eNom letter

GoogleClients@enom.com

Please unlock this domain, disable Google ID Protect, and send authorization code. Thank you!

Domain : yourdomainame.com
Password : u5yhtt5p965965 (your eNom pw, not your Google pw. Get this from Google Apps Domain Settings.
Customer service PIN : (if you know it, optional)

This is what eNom sends if you ask how to proceed.

 Greetings ,

To transfer your domain, you're going to need the domain to be unlocked and the authorization code for the domain. I can assist you with both of those if you can give me the domain password that Google supplied you. (Note: this is NOT your Google Apps login password.)

When you registered the domain, Google set up a privacy protect service and I will disable that in order for the transfer to be successful.

Also, please be aware that in order to transfer the domain, it needs to be 60 days after registration. This isn't an eNom-specific rule - this is a rule for all registrars set by ICANN.

Please e-mail me back with the domain name and password and I can get started on getting you the information you need.

If you don't know your domain password, follow these steps to find it:

Enter your domain name at the access login screen (http://access.enom.com), with AAA as the password, then copy the verification code. Click "Log In" to submit the information.

Put the name in again and then click on the "forgot password" link and it will be emailed to you at the address on file with Google for your domain name.

***IMPORTANT: Remember log into your domain manager at http://access.enom.com to ensure your Registrant and Administrative contact information is valid BEFORE transferring the domain name***

Alternately, IF YOU DID NOT CHANGE THE PASSWORD, you may also recover your Google domain password using the following steps:

To access your Advanced DNS settings, please follow these steps:

Log in to your account at admin.google.com.
Click on the Domains icon on your Admin console dashboard. You may need to click on More controls at the bottom of the screen to find the Domains icon.
Click on the Advanced DNS settings link associated with your Primary Domain.
To make changes to your DNS settings, sign into your DNS console with the login information provided on this page.
When you access Advanced DNS settings, you'll be directed away from Google, and to the domain registration partner that registered your domain name. This is currently available in English only.

Regards,

Google Advanced Domain Support

Provided by eNom, Inc.
email googleclients@enom.com

and this is what you get from eNom after you unlock:

Thank you for proper verification of domain ownership by supplying the domain password.

The domain has been unlocked, ID Protect has been disabled for transfer and your authorization code has been sent to the following email address in a separate e-mail. Please check your spam folder or filters as this is often captured.

***IMPORTANT: Remember log into your domain manager at http://access.enom.com to ensure your Registrant and Administrative contact information is valid BEFORE transferring the domain name***

YOUR EMAIL HERE

If the above email address is invalid, please log into the access control panel (http://access.enom.com) and update the contact information. Once the email address has been updated please reply back at your earliest convenience so that we may resend the EPP/ Authorization code.

Your domain is ready for transfer.

As a note: the transfer process does take 5-7 days for the domain to arrive at the gaining registrar. Once started by you, there is nothing you need to contact us about again. You can however ask us to confirm if the domain is pending transfer should you need to check.

DNS Result after setting up in Dreamhost as fully hosted with Google Apps services

Additional Custom CNAME (copied from eNom) that I added (some, like ‘sl’ are really exotic. Don’t worry about it.)

Miscellaneous artifacts

Some sample email excerpts:

-

We have requested your domain.com to be transferred to DreamHost! First, your admin contact will receive an email with a link to approve the transfer from us. They will then receive another email from the current registrar with instructions on how to approve the transfer from their side. Typically, transfers take about 7-10 days to go through. You will receive an email from us when we've learned if the transfer has been approved or denied. Note: If you'd like to also host with us, please visit "Manage Domains" now.

-

Domains must be "unlocked" at their current registrar or the transfer will fail. Domains may not be transferred within 60 days of their initial registration or their most recent transfer! You should do any name server changes (e.g. to ns1.dreamhost.com, etc) before transferring! You must make sure you have access to the admin contact email currently listed for your domain! You will receive an email from do-not-reply@dreamhostregistry.com with instructions on how to complete the transfer to DreamHost. If you do not receive it in a few hours, please check your spam filter. The entire process may take 7-10 days or longer before it is complete!

- fn -

[1] Dreamhost has worked well for me for many years. I you sign up and use my PROMO code of KATEVA you get $50 off the 1st  year (I get $47.)

[2] That freaks me out a bit, I vaguely remember when 6 years was more than yesterday. 

[3] Recently Google began providing domain services itself, but i don’t know much about it.

[4] Ok, so you can still get Google Voice (thought it’s a bit trickier than it once was). That service has saved me thousands of dollars on mobile phone calls to Canada.

DreamHost transferring its domain reseller/registrar business to eNom

File this one under deep sigh.

I started using Dreamhost for web services and domain management in 2008. I've been reasonably satisfied with them, though these days the main thing they do for me is host my share blog and manage domains, including some I moved from eNom/Google Apps. So I didn't expect any problems when I renewed one of those domains.

Alas, Dreamhost has moved their Domain registrar services to eNom. It's not clear exactly what his means, as they may always have been a reseller of someone else's domain management. In any case I had to go through a multi-step transfer process, which was not helped when Dreamhost's outdated UI told me I was transferring to LogicBoxes - which I'd also not heard of.

I contacted support seeking an explanation. They responded (I've fixed up the english, I don't think my support person is a native speaker):

Thank you for contacting Dreamhost Support. We are a registrar (reseller), we used to use LogicBoxes (still do for some  domains), but we are transferring most of the domains we can to eNom because we have had issues with logicboxes in the past.

The email you confirmed was to have the domain move from LogicBoxes to eNom, but the domain will still be registered through Dreamhost … Nothing will change on what you see, you will still manage it renew it, and everything through us. The change will actually be on the administrator side which we will see... 

I'm a bit concerned about the sloppiness of the process -- and that it was a surprise to me. I assume times are hard for this kind of hosting service -- much of the value they once delivered has moved to other businesses. 

Update: I realize I'm not getting anything from LogicBoxes, so this email dependent process may not be working. I'll see what Dreamhost support says.

See also:

• Transferring a Google Apps eNom domain: Awkward! 3/2009
• Dreamhost - registrar and hosting - still like 'em 1/2009 - discount code KATEVA

Legal Gmail for kids under and over 13 with Dreamhost Google Apps or Google Apps for Business

In the US, Google Account owners must be over 13, in the Netherlands it's 16 [1]. It's common to lie to get accounts for younger kids, but this can cause an account lockout and 30 day deletion. [2]

So how do kids under 13 get personal email? All services have similar rules.

The exception, of course, is Google Apps for Education. They provide Google services, including calendar and email for children of all ages. The trick is that this group is excluded from Google's predatory business model [3]; the services are paid for and the school district assumes liability.

Is there something similar that's available outside of Education?

Well, there are Google Apps for Business (and on-profits) of course. I was unable to find any age requirements for businesses that buy Google Apps for Business, nor any requirement that the business had to be, you know, a real business. Google isolates business data from its ads and data mining so I expect US laws on protection of children from being packaged and sold do not apply. 

At $50/user a year though, Google Apps for Business is a bit dear for a family of 5 (though the phone support is no little thing).

Unfortunately Google Apps for Nonprofits is not an option; you really do have to be a legal nonprofit.

Six years ago our family grandfathered into Google Apps through the now-defunct free option, and those users have since acquired full range of Google Services [4]. Alas, that's not an option any longer.

I think the cheapest legal option is to sign up with a hosting service that provides Google Apps for your registered domain. I can personally recommend Dreamhost for this, based on my 6+ years of experience and the (unusual) fact that they handle Domain registration for their customers [5].

At approximately $100/year ($50 for first year or $97 for two years if you use my code [7]) Dreamhost's Google Apps service for a family of five is less than half the cost of Google Apps for Business -- albeit without phone support. On the other hand, Dreamhost also provides other web services including web hosting, Wordpress (ex. kateva.org/sh), web apps, etc [6].

There are other hosting services that provide Google Apps for potential family use, but Dreamhost is the one I know.

 - fn -

[1] YouTube has an 18+ requirement for some videos, and Google Wallet is 18+. I don't believe either one is practically enforcable on most devices; maybe on Android or Chromebook depending on parental controls.

[2] It is noteworthy that Google's requirements for reversing account lockout are much more robust than their account recovery options. This says something about the power of laws and what Google could do to manage identity if they were forced to. The effective workaround is that a parent authorizes a credit card transaction on their own account, thereby technically committing fraud and assuming liability. The liability assumption is what matters.

[3] It's not that Google is particularly evil, this outcome is an inevitable outcome of their business model. They can no more resist this outcome than a species can resist Natural Selection.

[4] Not G+ though. It was once 18+ and is now 13+ regardless of Google Apps.

[5] Most hosting services have another party handle domain registration, and many of those deliver poor service.

[6] Admittedly more of a specialized interest these days.

[7] Just enter KATEVA when asked for a registration code. I set it up so users get the maximal $50/97 discount; I get a kickback but I set my kickback to maximize the user discount. Dreamhost supports Google's mutlifactor authentication framework, so I authenticate using Authenticator.app on my iPhone.

Components of a knowledge share solution

Both at work and at home i've been studying our current toolkit for sharing knowledge. At work I'm supporting our software development, at home I'm looking at a ways to share knowledge to support lifelong education of persons with cognitive disabilities, including formal public education and home schooling. Naturally I'm looking at similar technologies in both environments.

I've summarized a few of the components I'm thinking about in a table. I compared best of breed solutions to the best (not free!) suite I know of and to Google's offerings.

Function	Best of breed	Atlassian Confluence	Google
commentary, notices	Wordpress	yes	Blogger
Q&A	StackExchange	no	no
collaborative hypertext document	TWiki?	yes	Sites
PDF, other	FTP/HTTP server	yes	Docs, Share
Calendar/event	Google Calendar	no	Google Calendar
Social, networking	Facebook	no	G+
Subscribe/notify	RSS	RSS	?

Looking at this solution set it's clear that each has its advantages and weaknesses.

Atlassian Confluence is the best integrated knowledge sharing and collaboration solution I know of. It's not at all free, but it's inexpensive for 10 or fewer users and anonymous users can have read only access. I give Atlassian extra marks for actually publishing an easily discoverable price list. Unfortunately I don't think I can get Confluence running at Dreamhost, my net hosting provider.

Google, like Atlassian, is free for a small number of users and provides high performance anonymous access. Sadly, Sites is a great disappointment. On the other hand, I'm not impressed with any of the currently available open source wiki solutions. In many ways FrontPage 98 was better.

Lastly the best of breed solutions have advantages in terms of data freedom and ease of switching providers or changing knowledge base ownership. An integrated approach can also leverage StackExchange -- the net's best technology for question/answer based information sharing. Likewise a Facebook Page can engage customers and provide a secondary notification solution in addition to RSS/Twitter.

Any thoughts? Comments are most welcome.

PS. I've been looking at collaboration technologies for about 20 years -- starting with BBS software and a long string of innovative solutions. The functional list would have had answers 20 years ago. What's different is that the audience today is vastly larger.

Transferring the mnspecialhockey.org domain - what remains of Google Apps

The last step of the mnspecialhockey.org migration took place at DreamHost. The provide an optional mixed hosting service. I had some files in a traditional ftp site on a DH server, but also Gmail and Google Apps via Google.

From their control panel I turned off the Gmail and Google Apps connection. (See the posts list below for my prior action).

Then, since DH was also the registrar for mnspecialhockey.org I switched to the new DNS servers. I'll update this post if I learn what really happens to the data that was at the old site.

See also (note, some are old)!

• Closing a Google Apps domain: document liberation and more 2010
• Closing a Google Apps project: downloading sites 2010
• Transferring a Google Apps eNom domain: Awkward!
• How to create a google apps custom domain and move your blogger blogs to your new domain (2007)
• Gordon's Tech: Migrating a domain with related Google Apps and hosting files to a new service (2008). How I configured mnspecialhockey.org Google Apps after moving from Lunarpages.
• Gordon's Tech: Google Apps: Configuration for a non-Google managed domain (2007) - original mnspecialhockey.org Google Apps

Update 8/29/10: After the transfer

The mnspecialhockey.org domain now points to a new site. What happened to the old content?

• sites: they still exist! The URLs are of the form: http://sites.google.com/a/mnspecialhockey.org/sites/system/app/pages/meta/dashboard 
• docs: they still exist! The URL is of the form: http://docs.google.com/a/mnspecialhockey.org/#all
• mail: it still exists for my account (I removed the others) with URL: http://mail.google.com/a/mnspecialhockey.org/?tab=om#inbox

In fact, I can still manage the domain using the URL

https://www.google.com/a/cpanel/mnspecialhockey.org/Dashboard

So I have, at least for the moment, answered the question about what happens to Google Apps content when the original Google App Domain is gone. Turns out, it persists. Even the Domain settings persist (Google Apps thinks the domain is still mnspecialhockey.org, even though it no longer references this site).

If this remains true, it shows there's only a loose coupling between a domain-associated Google Apps suite and the domain itself. 

That's rather nice to know. It's not completely surprising however.

Closing a Google Apps domain: document liberation and more

I'm closing down a Google Apps domain because the domain name is moving (donated) to a new owner. Since I don't know what happens to the data after I transfer the domain name I've so far:

• Exported the "Sites" pages using a Data Liberation Tool
• Deleted all the existing site user accounts

My next step is to get a local copy of all the documents. Again, the DLF has directions. This turns out to be built into the Docs framework. On export you can specify a file format, I chose RTF for documents, Excel for spreadsheets, and native for the rest (PDF).

I also made sure so share all the documents with my personal account, but I wasn't able to transfer ownership. Currently that's not supported in Google Apps.

We had the non-profit version of Google Apps (free from Google) so we had all the yummy pro features, like the ability to associated a secondary domain. I have some I could use and I considered doing that to provide a way to access data post transfer, but I decided to skip that step in the interests of time.

Closing a Google Apps project: downloading sites

When MN Special Hockey signed up with a web hosting project, I needed to transfer the domain.

The domain was managed through my Dreamhost (love 'em - click here to evaluate my discount on their ISP services) accounts. There it has associated Google Apps services. I really didn't know what would happen to the account data when I switched away the host name, so I decided to see what I could backup.

Naturally I turned to Google's Data Liberation Front - my heroes. They provide a Java app for this purpose. It can allegedly be used to move a site from one location to another! 

Sites - the Data Liberation Front

A site can be downloaded using the open-source tool available at the Google Sites Liberation Project Page. Note that this tool requires Java 1.5 or later. Once the tool has been downloaded, double-click on the JAR file to launch the application. 

It opened easily on OS X 10.6.

You will need the documentation. Instead of www.mnspecialhockey.org (didn't fit their model) I tried sites.mnspecialhockey.org and I found two sites to copy:

• http://sites.google.com/a/mnspecialhockey.org/www/
• http://sites.google.com/a/mnspecialhockey.org/mn-special-hockey-site/

From their documentation I think the values are:

• host: sites.google.com (optional)
• domain: mnspecialhockey.org (optional)
• webspace: www and mn-special-hockey-site (two webspaces)

There's an option to download revisions, but I didn't care about that. I was fine with the latest version.

It worked, but the result was not pretty! Without style sheets it renders poorly in Safari, and  some of the character encoding was off. Still, the bulk of the content was there including associated PDFs that were a part of the site.

The Java app is pretty simple. You have to quit and restart to do a second site. Still, did I mention it worked?

Cautionary tale about Google Apps for business

Bad outcome with using free Google Apps for business operations.

A few quick comments:

• Dreamhost is the best way to use free Google App. They give you document hosting, domain registration and control, support and service, and associated Google Apps. (see my kickback deal with promo code KATEVA). I use 'em, I like 'em. Unusual company.
• The connection between Google Apps and domain name is tenuous. App content and services will survive domain divorce.
• Gmail has the same problem. So do all Google services, including identity management. There is no support. That scares me.
• Google Apps pricing is a great deal for a school or even a modest business, but it scales oddly and it's too much for a paid Google Apps family account. I'd like to see Google offer more price/service options.

Dreamhost - apparently the kickbacks work

I moved all of my web hosting services and most of my domain registrations to Dreamhost* a year ago (a few are with Google Apps hosting partners). This was a reasonably complex process that you can read about on Gordon's tech (dreamhost tag - look at the start).

I've been very pleased with them. I'm sure there must be cheaper ISPs and hosting services, but they have caused me no pain at all.

Today I went to pay a $10 registry fee -- and I discovered I had almost $200 in credits on my account. Evidently the kickback scheme works. I assume these come from a post I did a year ago ....

Gordon's Tech: Dreamhost - registrar and hosting - still like 'em:

... Last August, after years of moderate dissatisfaction with my domain registration and site hosting arrangements, I signed up with Dreamhost.

I've been quite satisfied with them as a hosting service and even happier with their registrar services; you can see this from posts over the past six months. I was disappointed with their weak implementation of webdav services, but that's been a minor problem. Of course you need some geek genes to work with them, but less so than most alternatives.

If you want to keep things simple, DreamHost is a better Google Apps partner than Google -- especially now that Google is trying to hide the free stuff.

Dreamhost offers members kickbacks to facilitate recruitment. So you need to take my recommendation with more saline than usual, but if you independently decide to sign up you can use my promo code of KATEVA (our dog) and get $50 off your 1st year fee (and I get a kickback if you pay up). Be sure to check out other promo code deals however, the one on their home page looks remarkably good....

Evidently some people used the "KATEVA" code. This link is supposed to do the same thing.

I've configured my promo code to give 50% off the first year of use. This means I get $47 for a new customer instead of $97. I think by promo code standard this is a pretty competitive deal, but do look around for better deals.

I'm a complainer at heart, so Dreamhost is doing pretty well to go unmentioned.

* Founded by Harvey Mudd grads. I went to the tech school up the road and we respected that brand. It's an employee owned company ...

--My Google Reader Shared items (feed)

Drupal reminds me of Google Page Creator

My now moldy vintage 1994 personal web site [1] was created using Microsoft FrontPage, especially FrontPage 98. That was an impressive piece of software for working with document-oriented web sites, unfortunately there's nothing like it around today. The closest thing to FrontPage today, curiously, is Microsoft's Sharepoint 2007 wiki.

FrontPage 98 still runs. In fact, I recently connected it to the XP SP2+ IIS-based personal web server. Unfortunately, it doesn't run on my current platform of OS X (save in emuliation of course).

So I've been looking for replacements, albeit sluggishly. Since even Dreamweaver seems to be a relic of another age I thought I'd look at Drupal, an open source "content management system" -- meaning a web app for authoring web pages.

It was easy to add to one of my DreamHost domains - it's a free one click install there. I had it up and running in (really) less than a minute.

Alas, even though DH claims that they'll keep it current it's already one big security update behind (so no links from here!).

Still, I was able to play with it. It reminds me of the late midly lamented Google Page Creator -- except that there's no rich text editor. In fact, the Firefox editing window I'm typing this into is far more powerful than a Drupal editing window.

I'll keep poking around, but I sure do miss FrontPage ...

[1] In one form or another I've maintained a continuous Internet presence since 1994. Holy cow.

Transferring a Google Apps eNom domain: Awkward!

[Updated from the original, it's not as bad as I first thought.]

I'm in the midst of correspondence with several eNom support people. The upshot is that I recommend against the "easy" default path of registering a domain through the Google Apps process.

Instead I recommend working with DreamHost (my most recent blurb on them, with discount code). They will provide a full service registrar function and any desire mix of Google Apps and standard web and web app services.

It all started when I registered a Google Apps domain for a specific project. I then realized I needed a true web server with the domain, rather than Google's moribund and dysfunctional "Sites" service.

No problem, I've done something this before, though this time I simply chose the DreamHost web+Google Apps option. I then changed the DNS settings at eNom and everything just worked (DNS propagation meant a full switch took about 10 hours, but there was no service discontinuity). I had the standard Google apps and my domain name now pointed to a web server.

[Update: Normally when you change DNS settings at a registrar I think you can enter either the IP address or the readable name (ex: NS1.dreamhost.com). Not so with eNom. The IP address won't work. Sheesh.]

Then it occurred to me that there was no obvious way to unlock the eNom managed domain name and request a domain transfer.

So I asked customer support.

I must say they answered quickly, but the answers were very confusing. I think after parsing them out (updated here, I had this wrong before) they can be moved after 60 days post-registration but the process is pretty manual and documentation is hard to find:

This is the best official documentation I can find ...

Unlock domain (GoDaddy and eNom) - Google Apps Help

...eNom

To unlock your domain with eNom, please contact the eNom support team to request this action. You can reach eNom.com support via email at googleclients@enom.com, or via phone at 425-974-4623. These channels are dedicated to Google Apps administrators who registered a domain with eNom during the signup process...

Messy. I think I'll gradually consolidate my eNom domains with DreamHost. (To be clear, I don't speculate in domains -- I use 'em all!)

Update 3/8/09:

eNom does have a process for transferring domains, but it's not publicly documented.

The following is translated from what I was sent by eNom customer service. They're very responsive but I'm pretty sure they aren't native English speakers. If you email keep things very short and simple. I think the phone number option is preferable.

... in order to transfer the domain, it needs to be 60 days after registration...

... This isn't an eNom-specific rule - this is a rule for all registrars set by ICANN.

If a domain name has been registered for more than 60 days, email with a request. Include the domain access password for verification. (This isn't your Google pw -- NEVER give that out.)

The domain access password business can be tricky.

Remember that in the Google Apps domain admin page there's an "advanced DNS settings" link that will display your eNom domain access password (and a link to the eNom admin page, but that's not relevant here.)

If you haven't changed the eNom domain access password Google generated you just need to include this password in your email.

If you've changed the original pw using the eNom admin page and haven't lost your new password, that's the one you put in the email (frankly I suggest phoning instead).

If you've lost your revised pw here's where you're reminded how critical it is to retain control of your email accounts (read this as a reminder!)

simply put in your domain name at the access login screen and then click on the "forgot password" link and it will be emailed to you at the address on file with Google for your domain name.

Yikes. You really don't want to lose control of your Gmail account.

Once you've submitted the unlock request, in a day or so your domain will be unlocked. At that point you can initiate a domain transfer request from DreamHost (or any other registrar).

I don't know what happens next, but I suspect eNom sends you an email when they get the domain transfer request and you have to validate that. Either that or the domain transfer. Or something. I think I'll do this sometime in the next few weeks, so wait for the next update ...