dotMobi Switch On! Email Guide

Version 1.0
Revision 5
Status Final
Date 29-June-2007
Ronan Cremin (dotMobi),
Britt Lysaa (dotMobi),
Serge Haumont (Nokia)
Lauri Hirvonen (Nokia),
Ritva Siren (Nokia),
James Pearce (dotMobi),
Britt Lysaa (dotMobi),
Christian Breitschwerdt (Vodafone),
Hubertus Wortmann (Vodafone),
Daniel Appelquist (Vodafone),
Klas Guenter (Vodafone),
Carl Taylor (Three),
Pasquale Quitadamo (Telecom Italia)
Fernando Soriano Vallejo (Telefónica),
Jorgen Odgaard (Ericsson),
Darren Edwards (Wham Brands),
Michele Catania (Matrix)

1. Document Information

1.1 Status

This document has the status "Final". The lifecycle of the dotMobi Switch On! Guide is discussed in [Lifecycle]

1.2 Time Limits

There are no time limits associated with compliance to this document.

1.3 Document History

This is version 1.0 Rev.5 "External Draft" of this document. A statement of policy regarding updates to this document can be found at

The latest version of this document is available at

This version can be found at

1.4 References

DotMobi Switch On! Guide
dotMobi Switch On! Guide Lifecycle:
LEMONADE Profile RFC 4550:
LEMONADE Profile Update Draft:
OMA Open Mobile Alliance:
OMA Email notification:
OMA-MEM, Mobile Email Requirements V1.0:
OMA-MEM, Mobile Email Architecture V1.0.1, 14 Jun 2006:
DomainKey - DKIM:
DomainKeys Web page :
IETF DKIM Work Group:
About DKIM:
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM):
Identified Mail (DKIM) Signatures RFC4871:
Sender Policy Framework SPF:
Sender Policy Framework - SPF:
SPF Best Practices:
Sender ID:
Sender ID overview:

RFC 2822 - Standard for the Format of ARPA Internet Text Messages:
RFC 2821 - Simple Mail Transfer Protocol:
RFC 1939 - Post Office Protocol (POP) Version 3 :
RFC 2449 - POP3 Extension Mechanism :
RFC 3501 - Internet Message Aaccess Protocol version 4rev1. (see also RFC4466, RFC4469, RFC4551):
RFC 2177 - IMAP4 Idle command:
RFC 2505 - Anti-Spam Recommendations for SMTP MTAs, best current practice to prevent spam:
RFC 2554 - SMTP Service Extension for Authentication:

1.5 Copyright

This document contains information proprietary to Mobile Top Level Domain Limited ("mTLD" or "dotMobi"). You may not modify, copy, reproduce, republish, upload, post, transmit, or distribute in any way any material from this document including code and software without the express, written consent of mTLD.

This document as a whole is copyrighted as a collective work, and individual works appearing on or accessible through this document are likewise subject to copyright protection. You agree to honor the copyrights in this document (including the selection, coordination and arrangement of the contents of this document) and in the works available on or through this document. In addition, trademarks and tradedress belonging to us or to third parties appear on this site or are accessible through this site. The fact that we have permitted you access to this site does not constitute authorization to reproduce such trademarks for any other purpose.

Copyright © 2006–2007 Mobile Top Level Domain Limited

2. Oare

2.1 Purpose of Switch On! Guides

DotMobi Switch On! Guides are a set of guides governing certain technical protocols and services in the ".mobi" (dotMobi) domain. These guides are a combination of mandatory rules and best practices that, when applied to content and services associated with the domain, ensure a good user experience for users interacting with the domain and its services via a mobile device. The rules mentioned in Switch On! Guide documents are specifically designed to be:

DotMobi Switch On! Guides are primarily oriented at domain registrants, since registrants are the owner of content and services hosted at any domain, but are also useful for tool vendors and solution providers whose products and services may be involved with dotMobi.

2.2 Mandatory Rules Audit, Notification & Enforcement Process

DotMobi domain name registrants agree to implement the mandatory registrant rules listed in this document whenever they publish an email service linked to a dotMobi name on the internet. It is strongly recommended that registrants also ensure that their applications also comply with the Highly Recommended Best Practices to improve the end-user experience.

2.3 Registrar's Obligations

Registrars are obliged to make registrants aware of all Switch On! Guides associated with the dotMobi domain in advance of any registration taking place. Registrars must either make a copy of these documents available to the registrant or point them to the authoritative versions on the web site.

3. Introduction to Switch On! Email Guide

3.1 Scope

The dotMobi domain is intended as a sign to users that services associated with the domain are especially suitable for use on mobile devices. Service providers are expected to make sure that their dotMobi email service works well with mobile devices.

The dotMobi Switch On! Email Guide is the authoritative source of rules governing email services hosted on a dotMobi domain. It contains guidelines that aim to provide best possible user experience for mobile email services. It is therefore primarily targeted for dotMobi email service providers who aim to provide mobile-compliant email services e.g.

The extent to which the email service provider follows the dotMobi Best Practices depends on the choice of the email server implementation and its configuration possibilities/flexibility. Consequently, the email guideline may also be helpful for implementers of mobile email servers that can be used by service providers of mobile email services.

3.1.1 Internet and Mobile Service Standards

Internet email and related protocols are specified in a number of RFC documents from the IETF of which some are listed above. After internet services entered the mobile space a new standardization organization called the "Open Mobile Alliance (OMA)" was founded (in 2002), which consolidated a number of previous industry initiatives such as the WAP Forum, SyncML Initiative, MMS-IOP, Wireless Village and the Mobile Wireless Internet Forum (MWIF). OMA promotes end-to-end interoperability across different (mobile) devices, geographies, service providers, operators, and networks. Typically, OMA specifies mobile services and application based on existing definitions or standards mainly from IETF, ETSI and 3GPP.

OMA's Messaging Working Group (MWG) on email and has produced first specifications about the implementation of an email service in a mobile environment (see OMA EMN). However, the work is not finalized yet and a second quite relevant Work Program called OMA MEM is under way, picking up IETF activities such as LEMONADE (RFC 4416) as well other OMA topics such as DS and DM.

As this guide is not intended to establish a further mobile email standard, it rather acknowledges the work of OMA as a suitable reference for the detailed technical specifications for mobile email.

3.2 Use Cases Covered

The Switch On! Email Guide covers the use case of interacting with a dotMobi email service from a mobile phone, PDA or other hand-held device. This guide specifically does not cover use cases involving desktop PCs or other device types, nor does it cover other Internet-based applications such as browsing or instant messaging.

This guide does not cover email provisioning which is covered in a separate document.

3.3 Definitions

Push email: An email solution where the email server sends upon reception a new incoming email or part of it (e.g. only the header) to the email client. For example, the IETF LEMONADE working group recommends a push email solution based on IMAP.

Keep-alive message: When push email is used with In-band Notification, the client sends regular keep-alive messages to maintain the connection open between the client and the server. For example, IETF LEMONADE recommends using the IDLE message at least once every 29 minutes.

Polling: Polling is the process of a client asking from the email server if new emails have arrived, and if so, retrieving them to the mobile device. Contrary to push email the message will not be notified immediately but only after the next poll from the client. For example, the POP email retrieval protocol is based on polling.

In-band Notification: Server to client notifications of email server events, which are transported via the mobile email protocol. For example, e.g. IMAP server may notify of the arrival of a new mail sending the RECENT message directly to the client.

Out-band Notification: Server to client notifications of email server events, which are not transported by the Mobile Email protocol but via other channels. Such channels may involve: SMS, MMS, WAP Push, SIP Push, etc. For example, OMA has standardized an Out-band Notification based on WAP-Push.

Email Proxy: An email proxy is deployed between an email client and an email server. Email proxies are commonly used for security (spam prevention, virus detection). They may also be used to provide inter-working if the email client and the email server use different email protocols, or to provide NAT traversal. For example, in the OMA architecture, the MEM (Mobile Email) server is an email proxy providing the inter-working between the Mobile Email protocol used by the mobile email client, and an existing email protocol used by the Email server.

3.4 Mobile email overview

The email service provider will face a number of choices when deploying their services, and may use standard or proprietary email solution.

The internet standard "LEMONADE profile" [RFC 4550] recommends a set of requirements, extensions and restrictions that allows clients which are constrained in memory, bandwidth and processing power to efficiently use IMAP4.1 [RFC 3501] and SMTP [RFC 2821] submission to access and submit mail.

While full LEMONADE support is not yet commercially available in clients, many mobile devices already have an IMAP 4.1 email client, often supporting push email using the IMAP IDLE procedure as well as the OMA email notification protocol. Using the standards-based solutions will help ensure compatibility with a wide installed base.

On the other hand, adopting a proprietary solution might require specific mobile device and/or email client. POP is another open standards-based email protocol that is widely supported by email servers and mobile devices but POP is not optimized for mobile usage, for a number of reasons.

Another possibility is to deploy a web email solution using only the mobile devices's browser. The web interface should then comply with the Switch On! Web Developer Guide.

A mobile operator can offer a number of services to the email service provider:

Typically mobile devices are connected to Internet through a mobile operator or, in some cases, through a Wireless LAN. A mobile email solution may be deployed completely independently from the mobile operator. The service provider should be aware that the mobile device is likely to have a private IP address, and that not all cellular subscribers have unrestricted Internet access. Some subscriptions allow only browsing and MMS traffic. Some operators may also terminate the Internet data connection after a certain time of inactivity, and this time varies widely. Data charges incurred while sending or receiving email will be charged according to operator data plan: typically the sender will pay for sending the email (and attachments) and the receiver will pay for the download of the email (and attachments) on the mobile device.

A business model has been proposed where the sender of an email message would pay in advance for its delivery in order to ensure that the receiver can receive the message at no charge on the mobile device. This model is similar to that of many existing mobile telephony services such SMS or MMS. This business model will need further evaluation by involved parties such as the GSM Association, mobile operators and ISPs to determine its feasibility.

The Registrant's Best Practice section of this document provides guidance to select a good solution for mobile email.

3.5 Structure of the Best Practices

DotMobi-specific best practices are identified as follows:

The text of a dotMobi rule or best practice.

Best practices are ranked in order of desirability.

4. Registrant Mandatory Requirements

4.1 Self-Declaration of Supported Functions

Service providers offering public email services in a dotMobi domain must declare information of the mail server via the domain's DNS records.

4.1.1 What it Means

Service providers that offer free or paid public email services must declare proper MX records in the authoritative DNS server for the domain. Presence of MX records indicates that the domain has a functioning email service. Services that are in testing or that are down for maintenance are not required to have MX records in place for the domain.

5. Registrant Best Practices

5.1 Interoperability with Standards-Based Internet Email Systems

Services should support bi-directional interoperability with standards-based internet email systems.

5.1.1 What it Means

Users of a dotMobi email service should be able to send email to, and receive email from any other internet email service that supports RFC 2822 in its interaction with external mail systems, subject to the other best practices mentioned in this document. RFC 2822 is supported by most open source and commercial email servers. Furthermore, proprietary email systems can be configured to communicate with RFC 2822 compatible email systems via a gateway.

5.2 Automated Delivery of Email

Services should support a push email solution.

5.2.1 What it Means

Push email solution provides timely delivery of new email. It should support the option to push only part of the email (e.g. the header). It should support configuration of what type of email should be pushed to the client (e.g. urgent email, specified sender, ...). The push email solution may use in-band or out-band notifications.

An email solution based on polling is not preferred for mobile. A short polling interval creates unnecessary traffic and affects the mobile battery life. A long polling interval does not support a timely delivery of email, and so provides a poor user experience.

If an e-mail client does not support push email, the service provider should provide the option to send a notification to the user with SMS or MMS to inform about the arrival of new emails.

(see also 5.5 Delivery Configuration)

5.4 Spam and Abuse Prevention

Services should offer a method to prevent abuse and spam.

5.4.1 What it Means

Unsolicited bulk email is serious problem with existing desktop-email services and is even more acute and intrusive on a mobile-oriented email service due to the personal nature and the limited resources of mobile devices, and their ability to interrupt you.

Services should follow best practices to prevent spam and offer spam protection tools to reduce the impact of this problem. The service should implement security policies and guard against unauthorized mail relaying and unsolicited bulk mail.

As the mobile user pays for the download of email, spam will increase data expenses and is likely to diminish the user experience and therefore also will impact the success of mobile email.

5.4.2 Prevention

Authentication of the clients (users) is vital to prevent spam from originating within your own domain (see 5.6 User Authentication). Allowing spam to originate from your network will damage your reputation as a service provider, and your domain might be blacklisted by other providers, preventing your users from communicating with users outside your domain.

Users access to personal spam filter and virus tools are important for users to have some control with incoming spam. A user should be able to easily maintain the client's own spam-filter, by setting up blacklists, white-lists, grey-lists, buddy-lists, etc. and define rules for actions to be performed based on the status of the incoming mail. A large amount of spam originates from innocent users who have been victims of virus attacks. Virus filters should be implemented on the server side and could be offered as a free or paid service.

5.4.3 Abuse Reporting

The service provider should provide a consumer friendly, practical procedure to report abuse. What it Means

When users receive spam or are attacked by viruses they need a method to report the abuse.

There are several ways to do this. Some examples are:

These examples are from standard PC based mail and used as illustrations only. The service provider in the dotMobi domain should implement a reporting procedure suited for mobile users.

Spam reporting could be made easy for the consumer by offering an automated service which can, on explicit request from the user, forward spam-tagged mails to a responsible address, for further processing.

5.5 Delivery Configuration

Services should support the configuration of criteria that support selective delivery of messages to the mobile device.

5.5.1 What it Means

Delivery configuration allows users of the email service to configure rules to ensure that only the most relevant emails are delivered to their mobile devices, to make the best use of the mobility premium offered by a mobile email service. Delivery configuration should offer the ability to selectively restrict emails delivered to the mobile device based on attributes within messages. The following criteria should be supported:

5.6 Sending User Authentication

The user sending email should be authenticated before granting access to the email service.

5.6.1 What it Means

The mail server must implement a method to authenticate and authorize the user when the client connects to fetch or submit mail. Unauthorized access should be restricted and activities should be logged (for a limited time).

The LEMONADE Profile refer to the mandatory-to-implement authentication mechanism for SMTP submission [RFC 2554] and the mandatory-to-implement authentication mechanism for IMAP [RFC 3501].

The SMTP Extension for authentication is appropriate for the submission and performs an authentication protocol exchange to authenticate and identify the user.

The optional authentication parameter (AUTH, RFC 2554) to the 'MAIL FROM' command allows cooperating agents in a trusted environment to communicate the authentication of individual messages. (see also 5.7 for more details)

An Message Transfer Agent (MTA) that also has the ability to handle mailing lists and expand to a number of recipients, needs to be able to authorize senders and protect its lists from spam.

5.7 Sending Server Authentication

Services should provide a means to allow themselves to validated as an email server for their domain(s) and should validate that the originating server for email is a valid originating server for the domain of the sender.

5.7.1 What it Means

Sending user authentication means putting in place practices to ensure that the originator of an email can be trusted. Sending user authentication has two distinct components:

The message transfer agent (MTA), should support the best practices for spam preventions. Some examples of capabilities are:

An MTA that also has the ability to handle mailing lists and expand those to a number of recipients, needs to be able to authorize senders and protect its lists from spam. (See methods for preventing spam discussed in RFC 2505, Anti-Spam Recommendations for SMTP MTAs best current practice.)

The first line of prevention is for the MTA to check the host and domain names of the incoming connection. e.g. verify that the translation address->name corresponds to name->address. However, it must be used with care, since it is can be forged, either by false cache information injected in DNS servers or spammers running their own DNS with false information in them. (With Secure DNS, RFC2065 this will improve,since spoofing (of .IN-ADDR.ARPA) will no longer be possible.)

In addition to the above, the MTA might implement several other mechanism for prevention of spam. Some examples of different approaches are Sender ID, SPF and DomainKey (which can coexist with each other and/or with other solutions):

DotMobi strongly advise the service provider to implement a method which allows the authentication of the sending server of the original mail, and the possibility to trace a message back to the original sender.

See also: Authentication and Online Trust Alliance (AOTS):

5.8 Alternative Access to Mailbox

Services should provide alternative modes of access to mailboxes.

5.8.1 What it Means

Services should provide a means for users to access their email in a way that does not require the mobile device. This allows users to view their email when they are unable or unwilling to use their mobile device, and also allows users to view emails that they have chosen not to have delivered to their mobile device and manage other aspects of the mobile email service.

5.9 Adaptation of Incoming Emails

Services should offer the option to adapt incoming emails before delivery to the mobile device in such a way as to make them work better on these devices.

5.9.1 What it Means

The handling of message parts, especially attachments, represents a set of challenges to limited devices, both in terms of the bandwidth used, and the capabilities of the device.

Email Server requirements

The server should support:

In all cases, the original email should be kept on the server, as it may be latter downloaded through a different device.

Client Requirements

The user should be able to configure:

5.10 Enhance User Experience

Service providers are encouraged to take advantage of the facilities provided by LEMONADE Profile, for an enhanced user experience.

5.10.1 What it Means

Email clients which implements the LEMONADE Profile allows the mobile user to benefit advanced capabilities which improves the user experience. Those capabilities are known as "forward without download" and the ability to compose mail on the handset, which includes links to larger documents stored on the server, and which will be included in the message when the mail is submitted from the server - without the need of download it to the handset.

The Service provider should facility such capabilities as newer mobile clients becomes commercial available, as it should positively impact the mobile users experience.

5.11 Personalized Email Addresses

Service providers should consider additional service options for users with personal dotMobi domain names.

It is recommended that email service providers should allowing personalized dotMobi email addresses to be linked to their users' accounts, available as a service option at their customers choice.

5.11.1 What it means

An increasing number of users have (or want to have) their own (personal or business) domain name independently of their email service provider [Example: Joe Smith might want to have the personal domain, and an email address of].

This is a reality for many PC users, who can subscribe for services which allows them to maintain their own email identification through easy accessible user-interfaces, and thereby have mails addressed to their personal domain name, to be delivered to their email service provider, where they actually fetch and submit their emails.
(The redirection is typically done by the domain name service providers hosting the DNS MX resource records for the domain and reroute the mail to user's real mailbox.)

For mobile users in the dotMobi domain, these value-added services might become even more useful, as the mobile user may be looking to always consume the best mobile email service for the most attractive price. In turn, this also enables email service providers to offer users of legacy email services to change to a new mobilized email service while keeping their normal personal address and at the same time to compete on the mobile email service delivery aiming at making mobile email a unique compelling user experience.

5.12 Minimize Impact on Battery Life

Service providers should select an email solution where keep-alive or polling messages are carefully configured in order to preserve the mobile battery.

5.12.1 What it Means

If polling or keep-alive messages are sent too frequently, they exhaust the mobile battery quite quickly. The impact on the battery is highly dependent on the technology used (e.g. 2G, 3G, HSPA) and on the operator settings. Example: 15 minutes keep-alive should have a small enough battery impact in all cases.

In addition, frequent polling or keep-alive messages do use a disproportionate amount of operator resources (e.g. establishment of a dedicated channel, change of mobility management states). Depending on the billing model, frequent polling or keep-alive messages may also be costly for the end user.

Valid XHTML 1.0 Transitional