There’s been a lot of discussion recently about GMail’s two-factor authentication thanks to the Matt Honan hack publicity. I’ve been using it awhile and figured I’d share my thoughts and experiences. I had been using it for an account that I just used for email so it wasn’t much of a hassle. But I recently added it to a second Google account and it’s been more of a hassle. It’s probably needed more on this account, since it’s used for more than just email so I’ve kept it enabled. In the case of Google the two-factors are a password (something I know) and something I have (my phone).
Here are my notes from using Google’s Two Factor Authentication. For the record, I used my own domain with Google Apps accounts in both cases.
There’s plenty of backup available should I lose or break the phone with the authenticator app:
I have the Google App on my iPhone so I don’t need a cellular connection to get the code.
As backup I have another phone set up to get the code via SMS.
As another backup there’s also printable one-time backup codes. The assumption is that Google can keep these codes secure.
If an app or device doesn’t recognize Google Two-Factor authentication there are Application Specific passwords:
“Application Specific” is more a description of the intent, rather than a technical requirement.
The Application Specific passwords can be used on multiple devices and applications. I’d prefer they be locked to the first app or device they’re used on.
If you use the password in a malicious or poorly written app the password can be used my someone else to access your email. So common sense still needs to be used when using the application passwords.
While 16 characters is a long password it’s not as complex as it could be, All passwords are 16 characters and there seems to be a limited character set. While this could be more secure, it would still be extremely hard to crack and isn’t a reason not to use them.
The application specific passwords only provide limited access to the account, even if compromised, such as accessing email.
Application specific passwords are easy to revoke so they can be used to try out a new app and then revoked if the app isn’t used.
I’ve had some issues where my iPhone email (for example) decides it needs a new app password and I have to re-enter it. This is a pain as I have to go to the website and generate a new one then type it into the iPhone.
While I can see the last time the application password was used, I can’t tell where it is used, so if the password is taken I wouldn’t notice, unless I stopped using it.
The initial setup is a bit of a pain. When two-factor authentication is turned on all the existing logons will break and have to be redone.
PCs can be made “trusted” and then for the next 30 days it won’t be necessary to enter the code when logging on.
If Google Sync is used (in Google Chrome) it’s necessary to use a encryption passphrase specific to Google Sync, the account password can’t be used since an application specific password is required. Well actually, an app specific password can be used, but it would have to be remembered and used as the app password for all Google Chrome logons, which goes against the design of the application passwords.
Anyone else using Google two-factor authentication? What’s been your experience?
I use Google App for Your Domain for my email, both my personal email and as email for the websites I run. I decided it was finally time to set up Sender Policy Framework (SPF) records and Sender ID. For differences between SPF and Sender ID you can read this. While they aren’t the same, the syntax and similarities make the steps for setting up each identical for our purposes.
What is SPF? From the OpenSPF website:
Even more precisely, SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together: (1) the domain owner publishes this information in an SPF record in the domain’s DNS zone, and when someone else’s mail server receives a message claiming to come from that domain, then (2) the receiving server can check whether the message complies with the domain’s stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.
What is Sender ID? From Microsoft’s Sender ID page:
The Sender ID Framework is an e-mail authentication technology protocol that helps address the problem of spoofing and phishing by verifying the domain name from which e-mail messages are sent
It’s important to note that while I have my own domains none of my servers send email, everything I send is from an email client. I don’t need to configure any other servers, just Google’s. So I can use Google’s instructions as the starting point for setting up the records. The important piece is: v=spf1 include:aspmx.googlemail.com ~all.
Google recommends using ~all which indicates a “soft fail” if the sender doesn’t match the record. This means the receiving service should apply extra scrutiny but not reject the email immediately. It’s up to the receiving service what the extra scrutiny is and some of my reading indicated some services (like Hotmail) are prone to reject soft fails. The most logical reason I read was that is someone isn’t confident enough in their settings to use a hard fail then the receiving service isn’t likely to trust anything other than a pass result. So I’ll be configuring a hard fail which is –all. (hard fail is a dash, soft fail is a tilde) I did use the soft fail during testing and you may want to do the same.
The Sender ID record is the same except for the policy statement at the beginning.
[Update July 14, 2012: As Terry pointed out in a comment, Google’s SPF record has changed to ” v=spf1 include:_spf.google.com -all”.]
My SPF record will be:
v=spf1 include:aspmx.googlemail.com -all
While my Sender ID record will be:
spf2.0/pra include:aspmx.googlemail.com -all
[Update July 14, 2012: It seems Sender ID is rarely used, mainly by Microsoft. The record listed here will be redirected but work, despite being technically wrong. See this.]
All that’s left is to add the records for the domain. The method varies by registrar. The SPF and Sender ID records get added as TXT records. Most of the domains I have in GAFYD use Slicehost DNS and they already have a good write-up on how to setup SPF records at Slicehost. I’ve added the procedures for some other registrars that I have access to.
After the SPF and Sender ID records have been added and allowed time to propagate you can use one of the testing tools to validate the records. I used the tester supplied by Port25 and sent an email to check-auth [at] verifier.port25.com. A response is returned with the results of the tests.
These procedures assume GAFYD is already configured to send and deliver mail for you. Google provides good documentation on how to do this and I wrote up how I setup Google App for My Domain back in August of 2007.
Adding SPF and Sender ID at GoDaddy
Fire up Domain Manager and go to “Total DNS Control” for your domain.
Click the “Add New SPF Record button under the TXT section.
Select “an ISP or other mail provider” and click OK
Click the Outsourced tab
Type aspmx.googlemail.com into the text box for domains. Click the “Exclude all hosts not specified here” for a hard fail (-all). Click OK
You’ll be asked to confirm the record that was generated. It should look like the SPF record I have above. Click OK to save the record.
Now click the “Add New TXT Record” button to begin adding the Sender ID record.
Type “@” (no quotes) into the TXT Name file
Type (or paste) the Sender ID record into the “TXT Value” field.
Change the TTL if you want, keep the value low for testing, you can change it from the default 1hr if you want. Click “OK” to save the record.
Wait for the change to propagate. I my case I could test after a few minutes, but in some cases it can take awhile.
Adding SPF and Sender ID at Bluehost
Bluehost automatically adds SPF records that point to their servers but use the ?all mechanism. From Bluehost help:
We do allow customers to request custom TXT entries in order to help fight against spam.
So it appears you’ll have to open a support ticket and have them add the records. (I did not do this so I can’t confirm they’ll do it or if it works properly.)
Adding SPF and Sender ID at NameCheap and NameCheap FreeDNS
I believe these procedures should work but don’t have an email account that I can test with. FreeDNS is a service provided by NameCheap that allows you to manage DNS for domains registered elsewhere.
Go the “Manage Domains” and either select “Your Domains” or “FreeDNS –> Hosted Domains” depending on which service you use. Then click on the Domain Name in the list. If the Domain is registered at NameCheap you’ll need to select “All Host Records” from the left menu bar. For FreeDNS you already see the All Host Records screen. From this point on the process is the same.
Enter the information as shown below. The record is partially obscured due to its length, but it’s the same SPF and Send ID records we’ve been using.
Once you save the settings you’re done.
Adding SPF and Sender ID at Enom
I believe these procedures should work but don’t have an email account that I can test with.
Enom provides a “Add SRV or SPF Record” button button I found that using this only allows the addition of one TXT record for the @ host. I found that both records could be added by simply typing them on the main screen. Use “@” as the host name (no quotes).
You’re done once you click Save.
SPF and Sender ID at 1 & 1
It doesn’t appear SPF or Sender ID can be used for domains registered at 1 & 1. The DNS configuration is very limited and I found the following in their FAQ under “What is an SPF record?”
There is currently no implementation of these
policies planned for 1&1 domains.
If you need SPF on a domain registered at 1 & 1 it appears you’ll either need to transfer it or use a third party DNS service.
SPF and Sender ID at Moniker
I believe these procedures should work but don’t have an email account that I can test with.
Log on and go to “My Domains”. Check the box next to the domain you want to manage and click the “IP” tab.
Click on the domain name.
Under “Add Zone Records” select TXT as the record type, enter @ as the host name and put in the spf or sender ID record for the address then click Add. Do this for both the Sender ID and SPF records.
Most hosts should use a process similar to one of the above.
I’d been holding off implementing SPF because I thought it would be a pain and cause problems. While looking into it I saw that Sender ID was easily implemented at the same time. In fact, because Sender ID will use the spf1 record is no spf2 record exists it’s recommended that Sender ID also be implemented at the same time (even if it’s only a record to say it’s not set up) because the spf1 record can cause problems with Sender ID. I previously linked to a detailed description of the differences which includes and explanation of why this is the same.
It’s also recommended that SPF records be added to domains that don’t send email. These records should indicate that the domain doesn’t send email in order to avoid it being spoofed by spammers.
SPF and Sender ID are complicated items but are easy to implement for someone like me who just uses GAFYD with desktop (or web) email clients.
This article is obsolete. Images and broken external links have been removed.
I’ve completed my move to Google Apps and now all my mail goes into my inbox there, one way or the the other. In Part 1 I’ll cover the domain setup and IMAP mail migration using the migration tool, while in part 2 I’ll cover the features that are available to all GMail users.
My reasons for moving to Google Apps were:
Sometimes they can be a bit creepy but I trust them as much as I trust any other ISP or mail provider.
I want to provide email to family members.
My current setup has my mail provided by Bluehost as part of my hosting service. This pretty much puts me in charge of the email server. I just don’t want to have to worry about backups and email problems. It was OK when I was the only one using it, but if I’m going to bring other’s on board it’s just a disaster waiting to happen.
EMail is not tied to an ISP.
GMail has the best spam filter I’ve ever used.
Google Apps includes Mail (including Talk & Calendar), Docs & Spreadsheets, Personal Start Page and Page Creator. There are two versions, free and Premium. Free allows 2GB for email and is ad supported. Premium allows 10GB for email and allows the ads to be turned off. Premium also has a 99.9% email uptime guarantee, along with mail migration tools and integration tools a business may look for. My only interest in Google Apps is for email.
I started with the free edition but quickly signed up for the 30 day Premium trial so that I can use the IMAP mail migration tools that’s included.
The domain I use for email is my primary domain with my Bluehost account but there’s no website associated with it. While I *should* be able to use the same domain as the primary domain with Google Apps I decide to be cautious since I’ve never done this before. I registered a new domain with 1&1 and use it as the primary domain with Google Apps. The domains I’ll use are (not the real names):
myfamilyblue.com – this is primary domain with Bluehost and the domain I use with email. I want to use this domain for email addresses.
myfamilyga.com – this is a new domain I’ll register and use as the primary domain for Google Apps. This will be available for email addresses and deliver to the same mailboxes as the other domain, but I won’t hand out the domain name.
In addition, while I can change MX records myself with Bluehost I have to go through tech support to change CName records. With 1&1 I can change both MX and CName records. This means I can make changes myself without having to go through tech support. This will be less annoying to me and less annoying for them if I decide to undo changes.
For the subdomains I’ll want mail.myfamilyga.com to access mail but I’ll use the default URLs for the other tools. You don’t need to use subdomains since Google Apps will give you URLs but I wanted the sub-domain for easy access to the frequently used mail. I can setup redirection for the subdomains of myfamilyblue.com to redirect to the Google App URLs.
There are additional restrictions if you buy the domain from Google, such as not being able to cancel Google Apps for a year. I’ll use my own domain that’s already registered.
Setting Up the Domain
I registered the new domain, myfamilyga.com, at 1&1 and waited for the DNS to replicate.
Then I registered with Google Apps for Domains. I set up the first user during registration and this will is the admin ID.
Google does create a test address so you can test email before changing your MX records. The address is displayed when you first set up Google Apps.
I need to verify the domain with Google before the services will actually start working. Google provides a couple of ways to do this. Either copy a specific html file to the site or create a CName record. I went the CName record route since I wanted one anyway. Google provides instructions for various domain hosts and I used the ones they provided for 1&1. In the case of 1&1 I needed to create a sub-domain then go in and create a CName record for that sub-domain and point it to ghs.google.com. I didn’t have to wait for this to replicate before I could continue, although it does need to replicate before email can be fully used.
Note: It’s a bit hidden in the help but Google also allows a MX record to verify domain registration. So if your mail system is ready to go you can just create the MX record. Remember, mail deliver will go to Google once the MX record is created so make sure all users are created if they have mailboxes on another server. My domain verification seemed slow so I created an MX record and then verification completed immediately. It may have been a coincidence.
The next step is to set up the users which will also create the mailboxes. I already created a user name for myself while setting up Google Apps. So I set up nicknames for all the other mailboxes and forwarding addresses that I had set up on the old myfamilyblue.com.
The next step is to change the MX records for the domain. As soon as the MX records are changed all the email will start going to GMail so you’ll want all the users set up before making the change. In my case I have a new domain so I changed the MX records immediately so they have time to replicate. The MX record information provided by Google is here. The setup may vary depending on your domain host. Just make sure the entries are in the order listed by Google and that the priorities go from higher to lower. My setup for 1and1 MX records is shown below (click for full screen).
Since I wanted multiple domains reporting into Google Apps I went into the “Domain Settings” section, “Domain Names” tab and added the myfamilyblue.com domain as an alias. Then I went to Bluehost and changed the MX records. Here’s how to set up the MX records at Bluehost.
Test mail delivery to the users that have been set up. It may take time for the MX records to take effect.
You can use this NSLOOKUP(kloth.net) tool to see if the CName and MX records have changed on your DNS server. Enter your domain in the domain field and enter the DNS server (from your hosting/DNS provider) in the server field, then select the record type from the dropdown list. If you registered a new domain in step 1 it may take time for the change to replicate through the internet. For the first 48 hours the query may show your DNS server has the correct information but the rest of the internet may not know that your domain info is on that server.
IMAP Mail Import
I registered for the free-trial of the premium version so I could use the IMAP migration tool. My Bluehost email was in IMAP mailboxes and was the bulk of my EMail.
The IMAP email migration tool is under the “Advanced Tools” tab (premium edition only). I set up the server connection to Bluehost. For server software I picked “Cyrus” (first choice for trial and error) no security and port 143. Some mail systems may require an “IMAP Path” such as “Inbox”. I told the wizard I’d specify a few accounts and then I entered the user id and logon information for the accounts to migrate. I was pulling everything into my one new GMail mailbox.
The migration took some time, about 45 minutes in my case, and is dependent on quantity and size. A progress bar displays the status or you can click into the details and see how many emails have been migrated. As the mail was pulled in the migration tool added two tags, one was the email address of the old mailbox and the other was the full folder path that the email was in. The tagging was an unexpected and nice bonus.
My AOL My eAddress mailboxes are also IMAP mailboxes. I tried the migration tool on them but always received errors soon after the migration began. I only had about 100 emails in those mailboxes and only a couple of folders. So after a few migration failures I went to plan B. The My eAddress mailboxes were already set up in Thunderbird so I created a new IMAP mailbox on Bluehost, added it to Thunderbird and dragged the AOL email to the new account. Then I used the IMAP import utility to pull it into GMail.
At this point I had GMail working in my own domain. I really don’t have an interest in the other Google App pieces.
Some things to keep in mind:
I have two domains. When I set up a user ID it gets one mailbox that is addressable with both domains. So ray -at- myfamilyblue.com and ray -at- myfamilyga.com deliver mail to the same user mailbox.
Nicknames can be set up for users. I consolidated all my myfamilyblue.com mailboxes and forwarding addresses into one GMail mailbox by setting up a nickname for each one.
In part 2 I’ll cover importing mail from POP accounts (such as my other GMail accounts) and consolidating all my email in this one mailbox. All things which are available with regular GMail accounts.
It’s only been four days since my last log entry but I want to get on a weekly cycle with these and weekends seem to be the best time to do it. So here goes…
I continue to use Google Apps and like it. Really all I use it for is email, but it’s allowed me to consolidate all my email addresses into one mailbox for delivery. I finally got the hang of using search and labels (aka tags) rather than folders and it makes things much quicker and more efficient.
I never thought I’d see the day but I no longer use a desktop email client, it’s all web based. That does scare me a bit so I’ll probably set up Thunderbird or Mail.app to suck down the email on a regular basis so I have a local copy.
My Mozy Mac backup software had been a solid performer until I updated to the latest version on the 9th. Today the backup hung up in a “Backup Started” mode. It’s been that way for 10 hours. I just clicked cancel and it’s still hung up. If this is the same problem I had several version ago it’ll stay that way until a reboot (or I manually kill and restart all the processes.)
Blog at WordPress.com
My new blog is going along well. Looks like I haven’t been wasting my time and will probably make it public next week. Because WordPress.com hosts the blogs they are restrictions on what can be changed and added. The boundaries are good for me as it keeps me from going down the ratholes of themes, plugins and widgets. This blog is for the ratholes.
I subscribed to .Mac again. It’s one of those things I couldn’t stay away from. Now that I have a laptop that I use a lot it’s beneficial for me to sync with it. Standalone Sync software costs $50 or so. .Mac is an extra $30 or so (don’t buy it from Apple unless you get it bundled with a new Mac). The extra disk space, now 10GB, helps a lot since I can use it as a data directory for just about everything I want on the laptop and it will automatically be backed up and synced with my iMac. I’m still liking Yojimbo and will probably keep it so the .Mac sync for Yojimbo is a real plus.
My copies of iLife ’08 and iWork ’08 arrived late in the week. I haven’t had a chance to really dig into the software.
For iPhoto ’08 the Events seem to be simply rolls renamed. Except now they make sense and the new features make them more useful. Of course I was burned. Rolls were so useless that I simply combined all my photos into about a dozen rolls of over 1000 photos each. Getting them into events may be more trouble than it’s worth. I haven’t had a chance to dig into anything else.
For iWork (yea, I broke down and bought it) I like Pages now. It seems more accessible to someone like me who just needs a simple document every now and then. Numbers seems really cool. In typical Apple fashion they seem to be emphasizing looks. There’s 18 templates most of which are heavy on the eye candy. The UI elements that stand out are related to styles and formatting.