Posts Tagged Gmail
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 protected] 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.:
[email protected] # 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
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!
If you set up your Google account using your Android phone, or you added contacts to your phone but didn’t set them as Google account contacts, you will find they’re not synced to your Google account. This means that they’re not available as contacts when composing messages, and worse, you’re not using your Google account as a backup in case your phone is lost or damaged, or you swap phones.
You can easily fix this by doing the following steps from your Android phone:
- Open Contacts
- Hit menu > Import/Export
- Export to SD card, then hit OK to confirm.
After a few moments, your data will be exported.
Next, we delete all contacts, to prevent confusion
- In Contacts, hit menu > delete > Select All > delete
If you don’t have this option, try Delete All Contacts from Android Market.
(If you’re concerned about deleting your contacts before re-importing them, you can always import them, then resolve the duplicates manually, but you will have stale contacts in your phone. Deleting your contacts then re-importing them a second time will take care of that.)
Lastly, re-import all the contacts to your Google account
- Hit Import/Export again
- Select Import from SD Card
- Select Save contact to… (your Google account) NOT phone
After a few moments, your data will be re-imported, and synced with your Google account online. Note that it may take up to a few minutes for the contacts to start appearing in your Google account.
If you mistakenly import multiple times, you may end up with duplicates in your online Google account. To fix this, simply open more > Find and Merge duplicates from your Contact manager as shown below:
Yes, I really do have 329 contacts.
Note: It is not possible to preserve group information during an export/import. It’s not supported by Google.
Questions and comments are welcome below, thank you!
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?
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 protected] designates IP as permitted sender) client-ip=IP; Authentication-Results: mx.google.com; spf=pass (google.com: domain of [email protected] designates IP as permitted sender) [email protected]
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.