It’s easy to use email to send SMS messages to a mobile phone. SMS via email is a useful way to send alerts to yourself. (I use it to notify myself of e-commerce orders.) This method of sending SMS messages is appropriate for non-commercial and low-frequency activity.
Because the SMS is sent via email to mail servers at the mobile operator, the operator has an opportunity to filter your message as SPAM or otherwise choose not to forward it to the subscriber. This is Good Thing for consumers, who want to opt-out of spam, especially in a mobile context.
However, any SPAM filter can be misconfigured or made overly aggressive. I learned this the hard way when I recently moved from Verizon to Sprint. (The pull of the Palm Pre!) Verizon forwarded my automated SMS messages but Sprint flagged them as SPAM. After a two-hour customer service call, Sprint created an engineering work order to add my domains to their SMS whitelist. Sprint, if you are reading – thanks!
SMS Email Formats for US Operators
If you know the mobile phone number and operator, then you can construct a target email address for the device.
This table describes how to construct an SMS email address for mobile phone numbers at US operators:
Where <phone number> is the full 10-digit phone number, i.e. firstname.lastname@example.org.
For operators outside the US, check the SMS gateway entry at Wikipedia, this list of operator formats for text messages or contact the operator and request the format.
Comply with Mobile Marketing Best Practices
If you want to send SMS via email for commercial purposes, make sure that your SMS campaign complies with the of the Mobile Marketing Association. The Mobile Marketing Association (MMA) is a mobile industry group established to provide best practices and industry guidelines for opt-in mobile marketing campaigns. MMA members are ad agencies, operators, advertisers, mobile device OEMs and service providers.
The Mobile Marketing Association publishes three major policies and guidelines documents:
Mobile META tags can be used in XHTML-MP and HTML markup to tag the document as optimized for mobile devices. Mobile search engines, mobile browsers and even desktop web browsers look for mobile META tags to identify and render mobile-optimized markup.
Mainstream mobile web content is identified using the markup document’s DOCTYPE or document type declaration. If the DOCTYPE declares the document as XHTML-MP or WML, then by definition, the content is mobile-optimized.
Mobile META tags can be incorporated into mobile-optimized HTML documents to identify the document as “made for mobile”. Here are several common mobile META tags and their interpretations by mobile browsers, mobile search engine spiders and robots.
The MobileOptimized META Tag
Microsoft invented the MobileOptimized META tag to control the layout width for mobile markup rendered in Internet Explorer Mobile (i.e. Pocket IE). The content of the meta tag is an integer width in pixels. In IE Mobile, the presence of this META tag forces a single-column layout at the specified width, preventing the browser from modifying the layout to “fit” the mobile screen. See this META tag reference at Microsoft for the tag’s interpretation in Windows Mobile 5.
<meta name="MobileOptimized" content="width" />
Some non-MS mobile browsers may also use the tag to force single-column layouts. Mobile browsers and mobile search engine spiders also use this META tag to identify mobile-optimized HTML.
The HandheldFriendly META Tag
The HandheldFriendly META tag was originally supported by AvantGo mobile browsers in Palm devices to identify mobile-optimized markup. Today, it is widely interpreted by mobile browsers and spiders as an indicator of mobile markup and a directive to display the web document without scaling. The value of the META tag is “true” for mobile markup and “false” for desktop-optimized HTML.
<meta name="HandheldFriendly" content="true" />
The Viewport META Tag
Many smartphone browsers scale Web pages to a wide viewport width, one appropriate for displaying desktop-optimized markup. These browsers allow the user to zoom in and out of scaled Web pages. For example, Opera Mobile uses a default viewport width of 850 pixels, and the iPhone uses a default width of 980 pixels.
The Viewport META tag controls the logical dimensions and scaling of the browser viewport window in many smartphone browsers, including Safari Mobile for the iPhone, Android browser, webOS browser in Palm Pre and Pixi devices, Opera Mini, Opera Mobile and BlackBerry browsers. The presence of the Viewport META tag indicates that the markup document is optimized for mobile devices.
Here is a simplified version of the Viewport tag that sets the browser viewport width at 240 pixels and disables user scaling of the content:
<meta name="viewport" content="width=240,user-scalable=no" />
The content value of the Viewport META tag is a comma-delimited list of directives and
This example <meta> tag lists all Viewport directives and example values:
<meta name="viewport" content="width=240, height=320, user-scalable=yes,
initial-scale=2.5, maximum-scale=5.0, minimum-scale=1.0" />
This table lists the meanings and values of all supported directives of the Viewport META tag.
|Viewport META directive
|Logical width of the viewport, in pixels. The special device-width value indicates that the viewport height should be the screen width of the device.
|Logical height of the viewport, in pixels. The special device-height value indicates that the viewport height should be the screen height of the device.
|Specifies whether the user can zoom in and out of the viewport, scaling the view of a Web page. Possible values are
|Sets the initial scaling or zoom factor (or multiplier) used for viewing a Web page. A value of 1.0
displays an unscaled Web document.
|Sets the user’s maximum limit for scaling or zooming a Web page. Values are numeric and can range from 0.25 to 10.0. The value of this directives is a scaling factor or multiplier applied to the viewport contents.
|Sets the user’s minimum limit for scaling or zooming a Web page. Values are numeric and can range from 0.25 to 10.0. The value of this directives is a scaling factor or multiplier applied to the viewport contents.
For more details about the possible directives and values of the Viewport META tag, see the Supported Meta Tags section of the Safari HTML Reference.
Mobile MIME types identify the format of mobile web content: textual mobile markup documents, binary viewable and playable content like ringtones, wallpaper and videos and binary executable mobile applications intended for mobile devices.
Common Mobile MIME Types
Here are the most common mobile MIME types:
||Mobile web pages
||Mobile web pages for smartphones
||CSS1, CSS2 and Wireless CSS
||Cascading style sheets for mobile web documents
||Lightweight mobile web pages for older or low-end mobile devices
||Wireless Bitmap Image
||Black-and-white image format used for older or low-end mobile devices that support only WML in the microbrowser.
||Scripting language used with WML
||Java Application Descriptor
||Metadata about a Java ME application for mobile devices. Contains URI to a JAR file that is the mobile application binary.
||Archive of compiled binary Java class files. Used as packaging format for Java ME mobile applications.
||MIDI Audio File
||QCELP Audio file
||3GP Video File
||3GP encoding for mobile video files
||MPEG4 Video File
||MPEG4 encoding for mobile video files
||Nokia Widget Archive
||Home screen widget for Nokia mobile phones
||Binary MMS in MMS Encapsulation Protocol format
||Viewing and sending MMS messages
||Older file format for Symbian application installers
||Newer file format for Symbian application installers
How Mobile MIME Types are Used in HTTP
MIME types are used in several ways during a HTTP transaction between a mobile web browser and web server:
Mobile Web Browser: The mobile web browser sends a list of supported MIME types as the value of the Accept HTTP request header. The Accept request header value advertises the mobile content types supported on the device. Web servers optimized for delivering mobile content use the header’s value (and also a device database) to determine the best content to send in the HTTP response.
Web Server: The MIME type associated with a web document is used as the value of the Content-Type HTTP response header. The web server is configured to associate file extensions of mobile content with mobile MIME types. (Web servers generally do not come pre-configured to support mobile MIME types. The webmaster must manually add the MIME types.) When the web server sends a file to a mobile browser and uses the correct mobile MIME type, the mobile browser client knows how to interpret the file: as a web page, mobile application, wallpaper, ringtone, video, etc.
Web Server Template Languages: The MIME type associated with for a document can be manually overridden using a server-side template language like PHP. Here is a PHP example that uses the built-in header function to override the MIME type for a HTTP response:
It is important to correctly configure mobile MIME types on the web server because the mobile browser uses the MIME type (value of Content-Type HTTP response header) to determine whether the web file is viewed in the browser or by launching phone UI (to set a GIF as wallpaper, etc.) or by launching a native application (playing a video in the video player, etc).
Read more about web server configuration for details about adding MIME types into Apache and IIS web servers.
In HTML, there is a very simple way to advertise a relationship between a desktop web page (or site) and the equivalent page (or site) on the mobile web. Very few desktop web sites implement this practice today. I have no idea why not, because the change is trivial and the benefits are broad.
Use link relationships to express that a particular web page is the mobile equivalent of a desktop web page. Link relationships can also be used to express that a mobile web site is the mobile equivalent of a desktop web site.
Link to Mobile Version using HTML Link Tag
Here is an example HTML link tag embedded in the header of a desktop web page to declare a relationship with a mobile web page:
<link rel="alternate" media="handheld" href="http://m.example.com" />
- The href expresses a page-to-page relationship when its target is the exact equivalent mobile web page, i.e. a mobilized version of a news article.
- The href expresses a site-to-site relationship when its target is the entry point of the related mobile web site, as in the sample.
An added benefit of using link relationships for mobile web discovery is improved mobile SEO. Desktop web crawlers look for HTML link tags to define page relationships. The crawler obtains the mobile web URL from the href attribute and knows from the media attribute that the content is mobile-friendly.
There are two other easy ways to increase mobile web discovery. These approaches are effective for mobile site discovery but don’t express direct relationships between a desktop web document and its counterpart mobile web document.
List Mobile Web URLs in a Google Mobile Sitemap
Use a Google Mobile Sitemap. A Google Mobile Sitemap is a sitemap file containing only mobile web URLs. The sitemap uses an additional XML namespace and a new tag to declare a URL as mobile content. Advertise your mobile sitemap in /robots.txt or submit it directly to search engines using webmaster portals.
Here is an example Google Mobile Sitemap:
<?xml version="1.0" encoding="UTF-8" ?>
Specify Mobile and Desktop Entry Points in Meta.txt
Use a /meta.txt file in the root directory to define PC and mobile entry points (and other metadata) for the website.
Here is an example of a meta.txt file that would be found at http://example.com/meta.txt:
description: example.com is a widely used example website
keywords: example, demo, demonstration