Posts Tagged Google
If all you really want from your Ubuntu Server is to be able to send you email if something goes wrong, or the occasional email to a trusted partner, friend, colleague, etc, then you want a simple solution. Although Postfix or sendmail, etc, will work in a satellite configuration, it’s still too heavy and over-the-top for this type of setup.
apt-get install ssmtp
/etc/ssmtp/ssmtp.conf in your favorite text editor and, to get it working on an example gmail account, set it up like so:
email@example.com mailhub=smtp.gmail.com:587 AuthUser=username AuthPass=password UseTLS=YES UseSTARTTLS=YES AuthMethod=LOGIN
Save the file, and you’re done.
Example for Amazon SES users. Be sure the sending domain is verified or mail will get rejected.:
firstname.lastname@example.org # from SES SMTP settings mailhub=email-smtp.us-east-1.amazonaws.com:587 AuthUser=username AuthPass=password UseTLS=YES AuthMethod=LOGIN
Important: You’re leaving your Gmail account password in a plaintext file. Make sure you’re using strong passwords. Even better, use Google 2-factor authentication so you can use an application-specific password for sSMTP.
UPDATE: Lastly, update the permissions
chown root:mail /etc/ssmtp/ssmtp.conf chmod 640 /etc/ssmtp/ssmtp.conf
Unprivileged users who have a need to send mail using sendmail must be a member of the mail group, or they will receive the following error:
mail: Cannot open mailhub:25
This was written for Ubuntu Server 12.04 64-bit.
- sSMTP- Debian Wiki – http://wiki.debian.org/sSMTP
If you want to subscribe to an iCal calendar using Google calendar, here’s how you do it.
First, go to your calendars so that you see ‘Other Calendars’ appear at the bottom of the screen. Click the down arrow next to it:
From the menu that appears, click ‘Add by URL’
The following dialog box will open, asking for the URL of your iCal feed.
Note that Google does not handle URLs that begin with
webcals:// at all. If you have an iCal URL that begins with one of these, change it as follows:
Paste your iCal URL inot the box and hit ‘Add Calendar’. The calendar will then appear in your calendar screen.
Sharing Google calendars between Google users is easy, but what if you want to create and share a Google calendar with someone who doesn’t use Google?
It’s actually not very difficult at all, and I’ll explain how to do it using your calendar’s private link. This will enable your viewer to see all event details, but due to the technical limitation of using iCal, they won’t be able to make any edits. This may be a good thing or a bad thing, depending on your specific situation.
So here’s how it works.
First, go to your Google calendar and locate the calendar you wish to share on the left side. In this case, I want to share my ‘work’ calendar. Hover over the calendar name and click the down arrow that appears next to it:
On the menu that appears, click ‘Calendar Settings’:
Scroll down to the bottom to where it says ‘Private Address’
In this case we want the iCal address link. You can either right-click the green iCal button and say ‘Copy Link Location’ (depending on your browser), or click it for a pop-up that gives you the link you can copy and paste, like so:
Now, if you want to ever revoke access to that calendar’s private link at a later date, just use the ‘Reset private URLs’ link which appears next to the private links.
Since Google is discontinuing it’s ActiveSync services, which allowed iPhone (and other handhelds) to sync account data using ActiveSync, you may want to reconfigure your devices now, or simply remember how to do this for the future. Note these steps are iPhone-specific, but can be easily adapted for other phones.
I’ll explain how to delete the ActiveSync setup, then how to add an IMAP account configuration for mail and calendars, and a CardDAV setup for contacts. If you only want to add a new setup, simply skip the first section here.
Deleting the existing ActiveSync setup
You can delete the existing ActiveSync setup by going to Settings > Mail, Contacts, Calendars and locating the account under Accounts. Touch the account name, then scroll to the bottom and click Delete Account. This will remove the data associated with the sync from your phone.
Creating the sync accounts
You’ll want to create both a Gmail IMAP account (for mail, calendars, and notes) and a CardDAV setup (for contacts). If you want reminders as well, you’ll have to create a CalDAV setup.
Creating the Gmail IMAP setup
Creating this sync account is very easy on the iPhone. First, in Settings > Mail, Contacts, Calendars, touch Add Account…. Next, touch Gmail, and enter your account information.
Creating the CardDAV setup
Similiar to the above. Go to Settings > Mail, Contacts, Calendars, touch Add Account…, then scroll down and touch Other. Touch Add CardDAV Account. For Server, enter
google.com, and continue with the rest of your account information.
For CalDAV, choose Add CalDAV Account instead of CardDAV, and follow the same account information.
If you use two-factor authentication for your Google account, be sure to use your application-specific password instead of your account password.
Google Apps setup is exactly the same as a standard Google account, just substitute your full email address for the username.
This is the first part in a two-part series in password security practices and storage. Be sure to click here to read part two if you haven’t already!
If you — like many people — are in the habit of using simple passwords, or even the same password over multiple sites, you’re setting yourself up for disaster.
Let me briefly explain: If you’re using a simple password it becomes much easier for a hacker to brute-force your password and gain access to your account. You should always use the strongest password — lower- and upper-case letters, numbers, and special characters — that any particular website supports.
If you’re already using strong passwords, good for you. However, if you’re using that same password — or a variation of it — on multiple sites, you’re undercutting the security of it. If one website that you use it on becomes compromised and that password is revealed or released, any other website that you use it on has also become compromised.
One example of this disaster is the RockYou hack. In January of 2010, Imperva released data regarding passwords exposed in the RockYou.com breach. In this attack, 32 million accounts were compromised and led to the disclosure of the top ten most used passwords, which potentially led to countless more accounts being compromised which used passwords that were on that list. This list was later updated to the 25 most often used passwords, as listed on Yahoo Finance.
Another example of this disaster waiting to happen is a phishing attack. This type of social engineering attack starts with a convincing-looking email that leads you to a website where you will “log in” or provide some other account details. The site that you’re directed to — while looking like the real site — is often a fake, designed to get you to provide your account information. Once the site has it, your account information can be used to log in to the real site. From there, a hacker can seize control of your account (changing the email address, password, and security questions), and attempting to use that information to log into other sites. Again, if you’re using the same password on multiple sites, the hacker now has access to all of those other sites.
Think you can identify a phishing email? Take a few minutes and take the SONICwall Phishing IQ Test now. I got 100% on this test, feel free to post your score in the comments below! You can also try the OpenDNS phishing quiz. I scored 14 out of 14 on the OpenDNS quiz. Feel free to post your scores and feedback in the comments below.
The implications of this are almost limitless if an attacker manages to take control of your email account. Once that happens they can start issuing password reset requests on other sites, and start taking control of them as well. For that reason, protecting the security of your email account should always been first and foremost. Google for one agrees, and offers users the option of 2-factor authentication, which provides a very strong level of security. If you have a Google (Gmail) or Google Apps account, I recommend you go and set this up immediately. It only takes about 15 minutes.
Do you have any other password security practices that you would recommend? Do you have a story to share about an account being compromised? Do you have anything to share that I didn’t cover above? Please feel free to share in the comments below! Also — check back for part two of this article, coming soon!
Google and Apple each brought their own services which allow users to upload their music library and stream it to their devices in the form of Google Music and iTunes Match, respectively. But how do those services compare?
Let’s take a side-by-side comparative look at some of the features:
|Feature||Google Music||iTunes Match|
|Number of songs||20,000 songs not purchased from Android Market||25,000 songs not purchased from iTunes|
|Supported devices||Works on common browsers on Win / Mac / Linux / Android / iOS (1)||Works on Win / Mac running iTunes; iOS devices supporting iCloud|
|Sync||Automatically sync music to Google Music using Win / Mac / Linux client||Automatically sync music to iTunes Match using iTunes|
|Sync Selection||Select which songs to upload using sync client||All songs from iTunes library are synchronized.|
|Local Storage||Save music to your Win / Mac / Linux / Android device for offline playback||Save music to your Win / Mac / iOS device for offline playback|
|Uploading||Every song must be uploaded||Matching is performed prior to upload; Only unmatched songs are uploaded|
|Supported file formats||Mp3, AAC (m4a), wma, flac, ogg (source)||Same as iTunes|
|Excluded formats||None||24-bit audio; Bitrates under 96 kbps; File over 200MB (source)|
(1) Although Google Music is reported to work on iOS devices,
As you can see, Google Music is aimed at the Android crowd, while iTunes Match is aimed at the iOS crowd. However, a few of the major points in Google Music’s favor that I see are that it supports playback from a web browser, has a Linux client, and is free.
Two-factor authentication finally comes for Google accounts, including Google Apps.
Using 2-step verification will help prevent strangers from accessing your account with just a stolen password. When you sign in with 2-step verification, you’ll verify your identity using both a password and a code that you receive on your phone. Learn more
The one-time-password (OTP) that you receive on your phone can come from one of two different methods: Either a time-based password using the Google Authenticator app for your smartphone (BlackBerry, iPhone, Android), or as a text message. Google also provides you a set of codes that you can print out, in case you don’t get your code or your phone is lost. Keep them in a safe place, because if you lose your phone and your codes, getting access to your account is a royal pain — but that’s the way it’s supposed to be:
You’ll need to fill out an account recovery form to verify ownership of the account. Take time to answer each question to the best of your ability. The form was designed to ensure that no one can gain access to your account except you. Since Google doesn’t collect a lot of information about you when you sign up for an account, we will ask you questions like when you created your account, what Google services you use, and who you email frequently (if you use Gmail) to make certain you are authorized to access your account.
Two-factor needs to be turned on in your Google Account settings, and Google has an excellent walk-though on how to activate and test two-factor during the setup. Google calls their two-factor authentication simply “2-step verification.”
To access your account settings from your Gmail or Google Apps mail screen, click Settings in the top right, then click the Accounts tab, then Google Account Settings. then click the “2-step verification” link.
Google says that setting up their 2-step verification takes about 15 minutes, and it’s a good estimate. Budget longer if you’re less savvy or want to be more careful. There’s a testing step involved, so there’s little risk of locking yourself out of your account.
There are major security advantages to using two-factor authentication. One of the biggest simply being that if your password is compromised, there’s still a barrier preventing someone from logging in and having their way with your account.
Along with this, Google introduces what they call “Application specific passwords.” These are workaround passwords for applications (IMAP/POP/SMTP clients, Google Talk, etc) that can’t present the OTP passwords required for two-factor authentication. Instead, you generate a different password — one for each resource if you like — and enter that in your application instead of your normal password. Sound confusing? It’s not, really. This has the added advantage that if someone gains access to your applications configuration files (e.g. Outlook) and pulls your password out, they can’t use it to log directly into your Google account. You can also go into your Google account and revoke these generated passwords at a later date if a resource does become compromised.
After enabling 2-step authentication, you’ll receive an email with information which includes information about application specific passwords:
IMPORTANT: What to Do If Some Applications Stop Working
Some applications that access Google data do not accept verification codes. They
only accept usernames and passwords. Examples include:
-Smartphones (e.g., Android, iPhone)
-Mail clients that use IMAP/POP (e.g., Outlook Express or Thunderbird)
-Chat clients (e.g., Google Talk)
-Picasa desktop application
Now that you have signed up for 2-step verification, these applications will
temporarily stop working. You can get them working again by entering an
application-specific password into the password box, instead of your regular
password or your verification code.
That email will contain a link to generate those application-specific passwords.
Security-minded individuals will no doubt embrace these changes to Google. I for one appreciate that Google is going to such great lengths to provide easy-to-implement security tools that benefit the consumer. I believe that Google may have done something really great here — users who are really concerned about security in Internet resources may now seriously consider creating Google account. Less technical consumers may still use Google using conventional username/password combinations if they so desire.
What do you think of Google decision to add two-factor authentication to accounts? Are you, or will you be, taking advantage of it?
Having been frustrated by some of the recent regressions in Firefox 4, particularly those involving Flash graphs, I’ve picked up Chrome and so far couldn’t be happier.
Moving my bookmarks over wasn’t too hard either. Here’s how to do it.
In Firefox 4, click Bookmarks > Show All Bookmarks (or press Ctrl-Shift-O)
Then choose Import and Backup > Export HTML…
Save that file somewhere you can find it for the next step.
Now, in Chrome, open the Bookmark Manager. You can find it by clicking the wrench icon, then Bookmark Manager.
Now choose Organize > Import Bookmarks from the Bookmark Manager and import that HTML file you just exported from Firefox.
Readers may also want to consider trying the free service Xmarks, which features automatic bookmark syncing across multiple browsers using a plug-in. Supports Firefox, Chrome, Internet Explorer, and Safari (Mac OS).
This was done using Firefox 4.0.1 and Chromium Browser 10.0.648.205 (81283) on Ubuntu 11.04. Questions, comments, and feedback are welcome and appreciated!
Google has added support for DomainKeys Identified Mail (DKIM) in Google Apps. This adds one additional layer of authentication to prevent forged or spoofed mail which could appear to come from your domain. This is an excellent compliment to having DNS SPF records.
Spammers can forge the From address on mail messages so that the spam appears to come from a user in your domain. To help prevent this sort of abuse, Google Apps enables you to add a digital “signature” to the header of mail messages sent from your domain. Recipients can check the domain signature to verify that the message really comes from your domain and that it has not been changed along the way. (If your domain has an SPF record, recipients can also verify that the message came from an authorized mail server.)
Set up consists of generating the key and adding it to your DNS records as a TXT entry.
To activate DKIM authentication for your domain email, sign into your Google Apps dashboard and go to Advanced tools. You should see a heading Authenticate email.
For more information, see Google Apps Administrator Help > Authenticate email with a domain key.
Sender Policy Framework (SPF) is a DNS record that’s used to authenticate who is allowed to send mail appearing to come from a specific domain. It is used to help prevent email spamming and spoofing, and works by making available a list of what domains, mailservers, and IP addresses are authorized to send mail from a domain, and what to do with mail that does not match those rules.
SPF is a DNS text record, and is added to your DNS records for the domain that matches the part after the @ sign in the email address. For example, for @example.com, the SPF TXT record should be added to the example.com domain.
I’m not going to cover every possible SPF setup, simply the ones I use most often and the rationale behind them. You can check the documentation links below my examples if you want to build more elaborate or specific SPF records.
In the below examples, substitute
with your web server’s IP address in dotted-quad format without a space. E.g.
IP:10.1.2.3. You can also specify a CIDR range such as
Allow from the domains IP, it’s listed mailservers, and a specific IP. Soft-fail all others (Messages that return a SOFTFAIL are accepted but tagged). The recommended configuration for most dedicated/VPS web server environments. Used when you send/receive mail at your domain, and software on your domain may send mail out as you, but no other mail server or mail exchanger will send mail as you. Users of shared hosting environments will probably want to ask their web hosting provider for the recommended SPF record to use.
v=spf1 a mx ip4: ~all
Include Google’s SPF records, if you use Google Apps as your domains mail. Add
include:_spf.google.com, similar in rationale to the above, but used if you use Google Apps for email, and your software on your web server may also send mail as you.
v=spf1 a mx ip4: include:_spf.google.com ~all
Fail all mail. Used only if you send no mail. Example: a parked domain or a domain that is not used in email at all.
In all the examples above except for the last, I denote soft-fail (
~all) instead of fail (
-all). This is because you may inadvertently make a mistake or misconfiguration, and soft-failing will not prevent mail from being delivered, it will simply flag it in the email headers. You can also specify neutral (
?all) as an alternative.
Here’s an example email header from Gmail which includes the SPF record’s lookup result. I’ve edited the email address and IP, of course.
Received-SPF: pass (google.com: domain of email@example.com designates IP as permitted sender) client-ip=IP; Authentication-Results: mx.google.com; spf=pass (google.com: domain of firstname.lastname@example.org designates IP as permitted sender) email@example.com
By this example, you can see the SPF record matched and was passed.
SPF records are a good tool for many reasons. They give mail servers the ability to authenticate your email to your domain, which helps keep it out of recipient’s spam folders, and they help prevent others from spoofing your domain in email, which could cause serious trouble.
Also, SPF records do not decide whether or not to accept mail for delivery — they only serve as an authentication mechanism for who is allowed to send mail appearing to come from that domain.
- SPF Project Overview
- The SPF Setup Wizard (Wizard to build SPF records quickly and easily)
- MediaTemple – HOWTO: SPF – All Purpose (Pre-built SPF records for MediaTemple customers)
- Wikipedia – Sender Policy Framework
- SPF Record Testing Tools
- SPF Records – Google Apps Help
Questions, comments, or feedback about the above SPF records or how they’ve been explained? Please share your thoughts in the comments below! Thank you.