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:

• Useful

• Achievable

• Measurable

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 mtld.mobi 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. joe@example.mobi.

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:

• The service provider may implement the mobile specific adaptation directly in their email server, or in a proxy in front of the email server. For example, an IMAP email proxy may be deployed in front of an existing proprietary server.
• The operator may also provide an email proxy which handles mobile specific optimization, NAT traversal and possibly provide specific billing models or authentication solution.. Such email proxy is part of the OMA architecture. The operator may provide OMA email Notification over WAP push or an SMS sending service to send notification to the user.

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:

Best practices are ranked in order of desirability.

4. Registrant Mandatory Requirements

4.1 Self-Declaration of Supported Functions

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

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

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

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

5.4.3.1 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:

• Filling in a form provided by the service provider:
  Example:http://help.yahoo.com/l/us/yahoo/abuse/abuse.html

• Sending mail to the abuse address provided by the service provider
  Example: send full mail including mail header to abuse@mydomain.mobi.

• Reporting through an external service for abuse reporting.
  Example: http://www.spamcop.net/ (see Report Spam).

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

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:

• Spam designation (see 5.4 Spam Protection)

• Subject

• Sender

• Email size

• Urgency

• Attachments

5.6 Sending User Authentication

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

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:

• Ensuring that any user who sends email from the service is authenticated before they are allowed to use its services. (see 5.6.1 for more details) This also helps to solve the problem of open relays, where a person or process can send an email through an email server without any form of authentication. Open relays have been major contributor to the spam problem.
• Ensuring that originator addresses in emails can be trusted so that that email address masquerading does not take place. This helps to ensure that people can trust that an email is really from the claimed address.

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

• restrict unauthorized use of Mail Relay
• provide "Received:" lines with enough information to make it possible to trace the mail path
• refuse mail from a host or a group of hosts, a specific user or an entire domain
• able to limit mail flow
• able to verify originator domain (using DNS or other means)
• provide local, spam and relaying log information that makes it possible to trace events assure traceability back to the sending host (which may be a firewall/gateway)

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):

• Sender ID (SenderID) is a framework which verify the domain name from which e-mail messages are sent. Sender ID validates the origin of e-mail messages by verifying the IP address of the sender against the alleged owner of the sending domain.

• Sender Policy Framework (SPF) is designed to protect against forgery of e-mail sender identities, either in the envelope or in the header. Current implementations use the DNS TXT record, while IANA has assigned a DNS resource record (type 99) dedicated to SPF.

• DomainKey Identified Mail (DKIM) DKIM defines a domain-level authentication framework for email using public-key cryptography and key server technology. It provides a cryptographic signature of multiple SMTP header fields and the body of a message. A domain protected by DKIM publishes its public key and senders signing policy in DNS.

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): http://www.aotalliance.org

5.8 Alternative Access to Mailbox

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

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:

• Suppression of certain attachments. For example, attachments that are too large or are executable files may be removed based on configuration.

• Partial fetch of the email. For example, an IMAP client can retrieve individual MIME types or retrieve portions of the individual parts or the entire message.

• The mobile user should be informed if a modified version of the email was delivered to the mobile (e.g. attachment removed, image downsized or text truncated).

• Conversion of an email or an attachment (e.g. image downsizing). Such procedures may be requested by the client or determined by the server based on knowledge of client capabilities. For example, the LEMONADE profile recommends the support of [IMAP-BINARY] or [IMAP-CONVERT] extensions.

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:

• the type of attachment to be received

• the type of attachment to be blocked

• the maximum email size

5.10 Enhance 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

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 smith.mobi, and an email address of joe@smith.mobi].

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

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.