iPlanet Messaging Server SMS Channel

8 March 2002

0.0 Contents

1.0 Introduction

The Messaging Server SMS channel is a one-way email to SMS gateway. Mail can be sent to an SMS gateway, but handling of SMS notifications (that is, replies and delivery receipts) and origination of email from SMS users (mobile to email) is presently not supported. The channel converts enqueued email messages to SMS messages as described in Section 3.2. This conversion process includes handling of multipart MIME messages as well as character set translation issues.

The generated SMS messages are submitted to a Short Message Service Centre (SMSC) using the Short Message Peer to Peer (SMPP) protocol. Specifically, SMPP V3.4 is used over a TCP/IP connection to the SMSC's SMPP server. Operating in this capacity, the channel functions as a External Short Message Entity (ESME).

2.0 Requirements

This paper requires that you read the abstract SMS specification, the SMPP specification from Logica, and the SMPP documentation for your SMSC's SMPP server.

In order to use the Messaging Server SMS channel, you must have the following:

  1. iPlanet Messaging Server 5.2 or later, and
  2. Access to the SMSC's SMPP server. The server must support SMPP V3.4 over TCP/IP and there must be TCP/IP connectivity between the host running Messaging Server and the SMPP server.

3.0 Operation

The Messaging Server SMS channel is a multi-threaded channel which converts queued email messages to SMS messages and then submits them for delivery to an SMSC. Operation of the channel falls into three categories:

  1. Directing email messages to the channel,
  2. Conversion of those email messages to SMS messages, and
  3. Submission of the resulting SMS messages to an SMSC.

Each of these categories is discussed in the subsections which follow.

3.1 Directing email to the channel

When the SMS channel is configured as per Section 4.0, one or more host names will be associated with the channel. For purposes of discussion, let us assume that the host name sms.siroe.com is a host name associated with the channel. In that case, email is directed to the channel with an address of the form

in which local-part is either the SMS destination address (for example, a wireless phone number, pager id, etc.) or an attribute-value pair list (AVPL) in the format

The recognized attribute names and their usages are given in the table below. These attributes allow for per-recipient control over some channel options.

And now for some example addresses:

For information on performing translations, validity checks, and other operations on the SMS destination address portion of the email address, see Section 3.4.

3.2 The email to SMS conversion process

An email message queued to the SMS channel is converted to one or more SMS messages. As described below, options allow control over the maximum number of SMS messages generated, the maximum total length of those SMS messages, and the maximum size of any single SMS message. Only text parts (that is, MIME text content types) from the email message are used and the maximum number of parts converted may also be controlled.

Character sets used in the email message's header lines and text parts are all converted to Unicode and then converted to an appropriate SMS character set.

When there is no SMS_TEXT mapping table, an email message queued to the SMS channel receives the following processing.

  1. An empty output buffer is started. The character set used for the buffer is Unicode.
  2. The email message's originator address is taken from one of the following five sources, shown in decreasing order of preference: If the originator address is a non-empty string, then the result of processing the FROM_FORMAT channel option is then appended to the output buffer. If, however, the originator address is an empty string, then the value of the FROM_NONE channel option is instead appended to the buffer.

    Note that the Resent-from: and Resent-sender: header lines are only considered if the USE_HEADER_RESENT option has the value 1. Otherwise, Resent- header lines are ignored.

  3. If Step 2 resulted in appending data to the output buffer, then the value of the LINE_STOP channel option is appended to the output buffer.
  4. If a Subject: header line is not present or is empty, then the value of the SUBJECT_NONE option is appended to the output buffer. Otherwise, the result of processing the SUBJECT_FORMAT option is appended to the buffer.
  5. If Step 4 resulted in appending data to the output buffer, then the value of the LINE_STOP channel option is appended to the output buffer.
  6. If there are text message parts, then the value of the CONTENT_PREFIX channel option for is appended to the output buffer. For each text part,
    1. The text part is decoded to Unicode and appended to the buffer. Between each line and text part, the value of the LINE_STOP channel option is appended.
    2. If there are additional text parts and the MAX_MESSAGE_PARTS limit has not been reached, then repeat.
    Non-text message parts are discarded.
  7. If there are no text message parts, then the value of the NO_MESSAGE channel option is appended to the output buffer.
  8. The resulting output buffer is then converted from Unicode to either the SMSC's default character set or UCS2 (UTF-16). After being converted, it is then truncated to not exceed MAX_MESSAGE_SIZE bytes. The SMSC's default character set is specified with the SMSC_DEFAULT_CHARSET option.
  9. The converted string from Step 8 is then broken into one or more SMS messages, no single SMS message longer than MAX_PAGE_SIZE bytes. At most, MAX_PAGES_PER_MESSAGE SMS messages will be generated.

As an email message may have multiple recipients, Steps 8 and 9 may need to be done for each recipient address which makes use of the MAXLEN, MAXPAGES, or PAGELEN attributes described in Section 3.1 above.

For example, with the channel's default settings, the email message

From: John Doe <jdoe@siroe.com>
To: 1234567@sms.siroe.com
Subject: Today's meeting
Date: Fri, 26 March 2001 08:17

The staff meeting is at 14:30 today in the big conference room.

Would be converted to the SMS message

jdoe@siroe.com (Today's meeting) The staff meeting is at 14:30 today in the big conference room.

The option settings

CONTENT_PREFIX=Msg:
FROM_FORMAT=From:${pa}
SUBJECT_FORMAT=Subj:$s

would instead produce

From:John Doe Subj:Today's meeting Msg:The staff meeting is at 14:30 today in the big conference room.

3.3 The SMS message submission process

Once an email message has been converted to one or more SMS messages, with possibly different sets for each recipient, the SMS messages are then submitted to the destination SMSC. The submissions are effected using SMPP V3.4 over TCP/IP. The hostname of the SMPP server is taken to be the official host name associated with the SMS channel; the TCP port to use is specified with the port channel keyword.

The channel binds to the SMPP server as a transmitter, presenting the credentials specified with the ESME_ channel options described in Section 4.3.3. In a bind_transmitter PDU (Protocol Data Unit), the following fields are set:

Fields in Generated bind_transmitter PDU
Field Value
system_id ESME_SYSTEM_ID channel option; default value is an empty string
password ESME_PASSWORD channel option; default value is an empty string
system_type ESME_SYSTEM_TYPE channel option; default value is an empty string
interface_version 0x34 indicating SMPP V3.4
addr_ton ESME_ADDRESS_TON; default value is 0x00 indicating an unknown TON
addr_npi ESME_ADDRESS_NPI; default value is 0x00 indicating an unknown NPI
addr_range ESME_IP_ADDRESS channel option; default value is an empty string

The SMS messages are then submitted using SMPP submit_sm PDUs. If a permanent error is returned (for example, ESME_RINVDSTADR), then the email message is returned as undeliverable. If a temporary error is returned, then the email message is re-enqueued for a later delivery attempt.

If the SET_SMS_SOURCE_ADDRESS option has the value 1, then the source address for the submitted SMS message is set. The value used is derived from the originating email message and is chosen to be the most likely (email) address to which any replies should be directed. Accordingly, the source address taken from one of the following seven sources, shown in decreasing order of preference:

Note that the Resent-reply-to: and Reply-to: header lines are only considered if the USE_HEADER_REPLY_TO option has the value 1. Moreover, the Resent-reply-to:, Resent-from:, and Resent-sender: header lines are only considered if the USE_HEADER_RESENT option has the value 1. (Note that this means that both of those options must have the value 1 for the Resent-reply-to: header line to be considered.) The default value for both of these options is the value 0. As such, only items 4, 6, and 7 are considered by the default configuration. Finally, since the source address in an SMS message is limited to 20 bytes, the source address chosen will be truncated if it exceeds that limit.

In a submit_sm PDU, the following fields are set:

Mandatory Fields in Generated submit_sm PDUs
Field Value
service_type DEFAULT_SERVICE_TYPE channel option; default value is an empty string
source_addr_ton DEFAULT_SOURCE_TON channel option; if SET_SMS_SOURCE_ADDRESS=1, then this field is usually forced to the value 0x05 indicating an alphanumeric TON; otherwise, the default value is 0x01 indicating an international TON
source_addr_npi DEFAULT_SOURCE_NPI channel option; default value is 0x00
source_addr DEFAULT_SOURCE_ADDRESS channel option if SET_SMS_SOURCE_ADDRESS=0; otherwise, an alphanumeric string representing the originator of the email message
dest_addr_ton TON addressing attribute or DEFAULT_DESTINATION_TON channel option; default value is 0x01 indicating an international TON
dest_addr_npi NPI addressing attribute or DEFAULT_DESTINATION_NPI channel option; default value is 0x00 indicating an unknown NPI
dest_addr Destination SMS address derived from the local part of the email envelope To: address; see Section 3.1 for further details
esm_class Set to 0x03 indicating store and forward mode, default SMSC message type, and do not set reply path
protocol_id 0x00; unused for CDMA and TDMA; for GSM, 0x00 indicates no internetworking, but SME-to-SME protocol
priority_flag 0x00 for GSM & CDMA and 0x01 for TDMA, all indicating normal priority; See the description of the DEFAULT_PRIORITY channel keyword
schedule_delivery_time Empty string indicating immediate delivery
validity_period DEFAULT_VALIDITY_PERIOD channel option; default value is an empty string indicating that the SMSC's default should be used
registered_delivery 0x00 indicating no registered delivery
replace_if_present_flag 0x00 indicating that any previous SMS messages should not be replaced
data_coding 0x00 for the SMSC's default character set; 0x08 for the UCS2 character set
sm_default_msg_id 0x00 indicating not to use a pre-defined message
sm_length Length and content of the SMS message; see Section 3.2 for further details
short_message
Optional TLV Fields in Generated submit_sm PDUs
Field Value
privacy See the description of the DEFAULT_PRIVACY channel keyword; default is to not provide this field unless the email message has a Sensitivity: header line
sar_refnum See the description of the USE_SAR channel keyword; default is to not provide these fields
sar_total
sar_seqnum

The channel remains bound to the SMPP server until either it has no more SMS messages to submit, or MAX_PAGES_PER_BIND has been exceeded. In the latter case, a new connection is made and bind operation performed if there remain further SMS messages to send.

Note that the SMS channel is multithreaded. Each processing thread in the channel maintains its own TCP connection with the SMPP server. For example, if there are three processing threads each with SMS messages to submit, then the channel will have three open TCP connections to the SMPP server. Each connection will bind to the SMPP server as a transmitter. Moreover, any given processing thread will only have one outstanding SMS submission at a time. That is, a given thread will submit an SMS message, then wait for the submission response (that is, submit_sm_resp PDU) before submitting another SMS message.

3.4 Site-defined address validity checks and translations

Sites may wish to apply validity checks or translations to SMS destination addresses encoded in the recipient email addresses described in Section 3.1. For example,

The first two tasks can be done specifically with the DESTINATION_ADDRESS_NUMERIC and DESTINATION_ADDRESS_PREFIX channel options. In general, all three of these tasks, and others can be implemented using mapping tables: either mapping table callouts in the rewrite rules or by means of a FORWARD mapping table. Using a mapping table callout in the rewrite rules will afford the most flexibility, including the ability to reject the address with a site-defined error response. The remainder of this section will focus on just such an approach -- using a mapping table callout from the rewrite rules.

Let us suppose that destination addresses need to be numeric only, be 10 or 11 digits long, and be prefixed with the string "+1". This can be accomplished with the following rewrite rule 

sms.siroe.com   ${X-REWRITE-SMS-ADDRESS,$U}@sms.siroe.com
sms.siroe.com   $?Invalid SMS address

The first rewrite rule above calls out to the site-define mapping table named X-REWRITE-SMS-ADDRESS. That mapping table is passed the local part of the email address for inspection. If the mapping process decides that the local part is acceptable, then the address is accepted and rewritten to the SMS channel. If the mapping process does not accept the local part, then the next rewrite rule is applied. Since it is a $? rewrite rule, the address is rejected with the error text "Invalid SMS address".

The X-REWRITE-SMS-ADDRESS mapping table is shown below. It performs the necessary validation steps for local parts in either attribute-value pair list format or just a raw SMS destination address.

X-VALIDATE-SMS-ADDRESS

! Iteratively strip any non-numeric characters
    $_*$[$ -/:-~]%*  $0$2$R
! Accept the address if it is of the form 1nnnnnnnnnn or nnnnnnnnnn
! In accepting it, ensure that we output +1nnnnnnnnnn
    1%%%%%%%%%%      +1$0$1$2$3$4$5$6$7$8$9$Y
    %%%%%%%%%%       +1$0$1$2$3$4$5$6$7$8$9$Y
! We didn't accept it and consequently it's invalid
    *                $N

X-REWRITE-SMS-ADDRESS
    */id=$_*/*       $C$0/id=$|X-VALIDATE-SMS-ADDRESS;$1|/$2$Y$E
    */id=$_*/*       $N
    *                $C$|X-VALIDATE-SMS-ADDRESS;$0|$Y$E
    *                $N

With the above set up, be sure that DESTINATION_ADDRESS_NUMERIC option has the value 0 (the default). Otherwise, the "+" will be stripped from the SMS destination address.

3.5 Site-defined text conversions

Sites may customize Steps 1 - 6 of Section 3.2 with a table of conversion rules. These rules are specified via a mapping table in the MTA's mapping file.

The name of the mapping table should be x_TEXT where x is the name of the SMS channel; for example, SMS_TEXT if the channel is named sms or SMS_MWAY_TEXT if the channel is named sms_mway.

Two types of entries may be made in this mapping table. However, before explaining the format of those entries, let it be made clear that an understanding of how to use the mapping file is essential in order to understand how to construct and use these entries. An example mapping table is given after the description of these two types of entries.

Now, the two types of entries are:

The entries in the example SMS_TEXT mapping table are explained below:
  1. These two entries cause From: and Subject: header lines to be included in an SMS message. "From:" and "Subject:" are abbreviated as, respectively, "F:" and "S:". Some of the other entries may have further effects on From: and Subject: header lines.
  2. This entry will reduce a From: header line containing a <...> pattern to only the text within the angle brackets. For example, "F: "Daniel C. Newman" <dan@siroe.com> (Hello)" will be replaced with "F: dan@siroe.com".
  3. This entry will remove, inclusively, everything inside of a (...) pattern in a From: header line. For example, "F: "Daniel C. Newman" <dan@siroe.com> (Hello)" will be replaced with "F: "Daniel C. Newman" <dan@siroe.com> ".
  4. This entry will remove, inclusively, everything inside of a "..." pattern in a From: header line. For example, "F: "Daniel C. Newman" <dan@siroe.com> (Hello)" will be replaced with "F: <dan@siroe.com> (Hello)".
  5. This entry will remove, inclusively, everything to the right of an at-sign, @, in a From: header line. For example, "F: "Daniel C. Newman" <dan@siroe.com> (Hello)" will be replaced with "F: "Daniel C. Newman" <dan".
  6. These four entries remove leading and trailing spaces from lines in the message header and body.
  7. These two entries reduce two spaces to a single space in lines of the message header and body.
  8. These four entries reduce double dashes, periods, exclamation points, and question marks to single occurrences of the matching character. Again, this helps save bytes in an SMS message.

Example SMS_TEXT mapping table 
SMS_TEXT
   H|From:*        H|F:$0$R$Y  (1)
   H|Subject:*     H|S:$0$R$Y  (1)
   H|F:*<*>*       H|F:$1$R$Y  (2)
   H|F:*(*)*       H|F:$0$2$R$Y  (3)
   H|F:*"*"*       H|F:$0$2$R$Y  (4)
   H|F:*@*         H|F:$0$R$Y  (5)
   H|%:$ *         H|$0:$1$R$Y  (6)
   H|%:*$          H|$0:$1$R$Y  (6)
   H|%:*$ $ *      H|$0:$1$ $2$R$Y  (7)
   B|*--*          B|$0-$1$R  (8)
   B|*..*          B|$0.$1$R  (8)
   B|*!!*          B|$0!$1$R  (8)
   B|*??*          B|$0?$1$R  (8)
   B|*$ $ *        B|$0$ $1$R  (7)
   B|$ *           B|$0$R  (6)
   B|*$            B|$0$R  (6)

In the example above, the metacharacter $R is used to implement and control iterative application of the mappings. By iterating on these mappings, powerful filtering is achieved. For instance, the simple mappings to remove a single leading or trailing space (6) or reduce two spaces to a single space (7) become, when taken as a whole, a filter which strips all leading and trailing spaces and reduces all consecutive multiple spaces to a single space. Such filtering helps reduce the size of each SMS message.

The order of the entries is very important. For instance, with the given ordering, the body of the message From: header line 

From: "Daniel C. Newman" <dan@siroe.com> (Hello)
will be reduced to 
dan
The steps taken to arrive at this are as follows:

Note that the imsimta test -mapping utility may be used to test a mapping table. For instance, 

# imsimta test -mapping -noimage_file -mapping_file=test.txt
Enter table name: SMS_TEXT
Input string: H|From: "Daniel C. Newman" <dan@siroe.com> (Hello)
Output string: H|F:dan 
Output flags: [0,1,2,89] 
Input string: ^D
#

4.0 Configuration

Two steps are required to add an SMS channel to a Messaging Server configuration:
  1. Add the channel definition and associated rewrite rules to the imta.cnf file, and
  2. Create a channel option file containing site-specific parameters required for the operation of the channel.

While there are no channel options which must be set in all situations, it is likely that one or more of the following options may need to be set: ESME_PASSWORD, ESME_SYSTEM_ID, MAX_PAGE_SIZE, DEFAULT_SOURCE_TON, and DEFAULT_DESTINATION_TON. And, as described, the SMPP server's hostname or IP address and TCP port must be set either through the channel definition in the imta.cnf file or the channel option file.

You may configure more than one SMS channel, giving different characteristics to different SMS channels. See Section 4.4 for further information on the use of multiple SMS channels.

4.1 Adding the channel definition and rewrite rules

Before adding an SMS channel to the MTA's configuration, you need to pick a name for the channel. The name of the channel may be either sms or sms_x where x is any case-insenstive string whose length is between one and thirty-six bytes. For example, sms_mway.

To add the channel definition, edit the imta.cnf file located in the server-root/msg-instance/imta/config/ directory. At the bottom of the file add a blank line followed by the two lines

channel-name master port p threaddepth t \
  backoff pt2m pt5m pt10m pt30m notices 1
smpp-host-name

where channel-name is the name you chose for the channel, p is the TCP port the SMPP server listens on, t is the maximum simultaneous number of SMPP server connections per delivery process, and smpp-host-name is the host name of the system running the SMPP server. For example,

sms_mway master port 55555 threaddepth 20 \
  backoff pt2m pt5m pt10m pt30m notices 1
smpp.siroe.com

Presently the use of the master channel keyword is criticial: without it the channel will default to being bidirectional and will generate replyable SMS messages. See Section 4.5 for a discussion of the backoff and notices channel keywords.

If you wish to specify an IP address rather than a host name, then for smpp-host-name, specify a domain literal. For example, if the IP address is 127.0.0.1, then specify [127.0.0.1] for smpp-host-name. Alternatively, consider using the SMPP_SERVER channel option.

The threaddepth channel keyword controls the number of messages to assign to each delivery thread within a delivery process. The SMPP_MAX_CONNECTIONS option controls the maximum number of delivery threads in a delivery process. And, finally, the job_limit option for the Job Controller processing pool in which the channel is run controls the maximum number of simultaneous delivery processes.

Once the channel definition has been added, go to the top half of the file and add a rewrite rule,

smpp-host-name $u@smpp-host-name

For example,

smpp.siroe.com $u@smpp.siroe.com

Then save the imta.cnf file, recompile the configuration with the imsimta cnbuild command, and then restart the SMTP server with the imsimta restart dispatcher command.

With the above configuration, email message are directed to the channel by addressing them to id@smpp-host-name (for example, 123456@smpp.siroe.com). See Section 3.2 for further information on addressing.

If you wish to hide the SMPP server's host name from users or associate other host names with the same channel, then add additional rewrite rules. For instance, to associate host-name-1 and host-name-2 with the channel, add the following to rewrite rules

host-name-1 $U%host-name-1@smpp-host-name
host-name-2 $U%host-name-2@smpp-host-name

For example, if the SMPP server's host name is smpp.siroe.com but you want users to address email to id@sms.sun.com, then add the rewrite rule

sms.sun.com $U%sms.sun.com@smpp.siroe.com

Note that the SMPP_SERVER and SMPP_PORT channel options will override the channel's official host name and port channel keyword settings. When the SMPP_PORT option is used, it is not necessary to also use the port keyword. The advantage of using these two options is that they can be put into effect and subsequently changed without needing to recompile the configuration. An additional use of the SMPP_SERVER option is described in Section 4.4.

4.2 The channel option file

The channel options described in the subsequent section are stored in a text file in the

directory. As with other channel option files, the name of the file takes the form For instance, if the channel is named sms_mway then the channel option file is

Each option is placed on a single line in the file using the format

For example,

A sample option file named sms_option.sample is distributed with iMS. Copy this option file and use it as a starting point.

4.3 Available options

The SMS channel contains a number of options which divide into four broad categories:

  1. Email to SMS conversion: Options which control the email to SMS conversion process.
  2. SMS fields: Options which control SMS-specific fields in generated SMS messages.
  3. SMPP protocol: Options associated with the use of the SMPP protocol over TCP/IP.
  4. Localization: Options which allow for localization of text fields inserted into SMS messages.

These options are summarized in the table below, and described more fully in the sections which follow.

Email to SMS Conversion
Option Default Description
MAX_MESSAGE_PARTS 2 Maximum number of message parts to extract from an email message
MAX_MESSAGE_SIZE 960 Maximum number of bytes to extract from an email message
MAX_PAGE_SIZE 160 Maximum number of bytes to put into a single SMS message
MAX_PAGES_PER_MESSAGE 6 Maximum number of SMS messages to break an email message into
SMSC_DEFAULT_CHARSET US-ASCII The default character set used by the SMSC.
USE_HEADER_PRIORITY 1 Control the use of priority information from the email message's header
USE_HEADER_REPLY_TO 0 Control the use of Reply-to: header lines when generating SMS source addresses.
USE_HEADER_RESENT 0 Control the use of Resent-*: header lines when generating originator information.
USE_HEADER_SENSITIVITY 1 Control the use of privacy information from the email message's header
USE_UCS2 1 Use the UCS2 character set in SMS messages when applicable
 
SMS Fields
Option Default Description
DEFAULT_DESTINATION_NPI 0x00 Default NPI for SMS destination addresses
DEFAULT_DESTINATION_TON 0x01 Default TON for SMS destination addresses
DEFAULT_PRIORITY 0 (GSM, CDMA),
1 (TDMA)		 Default priority setting for SMS messages
DEFAULT_PRIVACY -1 Default privacy value flag for SMS messages
DEFAULT SERVICE_TYPE   SMS application service associated with submitted SMS messages
DEFAULT_SOURCE_ADDRESS   Default SMS source address
DEFAULT_SOURCE_NPI 0x00 Default NPI for SMS source addresses
DEFAULT_SOURCE_TON 0x01 Default TON for SMS source addresses
DEFAULT_VALIDITY_PERIOD   Default validity period for SMS messages
DESTINATION_ADDRESS_NUMERIC 0 Reduce the destination SMS address to only the characters 0 - 9
DESTINATION_ADDRESS_PREFIX   Text string to prefix destination SMS addresses with
PROFILE GSM SMS profile to use
SET_SMS_SOURCE_ADDRESS 1 Set the SMS source address to the originator address of the email message
USE_SAR 0 Sequence multiple SMS messages using the SMS sar_ fields
 
SMPP Protocol
Option Default Description
ESME_ADDRESS_NPI 0x00 ESME NPI to specify when binding to the SMPP server
ESME_ADDRESS_TON 0x00 ESME TON to specify when binding to the SMPP server
ESME_IP_ADDRESS   IP address of the host running iMS
ESME_PASSWORD   Password to present when binding to the SMPP server
ESME_SYSTEM_ID   System identification to present to the SMSC when binding
ESME_SYSTEM_TYPE   System type to present to the SMSC when binding
MAX_PAGES_PER_BIND 1024 Maximum number of SMS messages to submit during a single session with an SMPP server
REVERSE_ORDER 0 Transmission sequence of multi-part SMS messages
SMPP_MAX_CONNECTIONS 20 Maximum number of simultaneous SMPP server connections
SMPP_PORT   TCP port the SMPP server listens on
SMPP_SERVER   Host name of the SMPP server to connect to
TIMEOUT 30 Timeout for completion of reads and writes with the SMPP server
 
Localization
Option Default Description
CONTENT_PREFIX   Text to introduce the content of the email message
FROM_FORMAT $a Text to display indicating the originator of the email message
FROM_NONE   Text to display when there is no originator
LANGUAGE i-default Language group to select text fields from
LINE_STOP space character Text to place at the end of each line extracted from the email message
NO_MESSAGE [no message] Text to indicate that the email message had no content
REPLY_PREFIX Re: Reserved for future use
SUBJECT_FORMAT ($s) Text to display indicating the subject of the email message
SUBJECT_NONE   Text to display when there is no subject for the email message
Miscellaneous
Option Default Description
DEBUG 0 Enable verbose debug output

4.3.1 Email to SMS conversion options

The following options control the conversion of email messages to SMS messages. In general, a given email message may be converted into one or more SMS messages. See Section 3.2 for a description of this conversion process.

MAX_MESSAGE_PARTS (integer)
When converting a multi-part email message to an SMS message, only the first MAX_MESSAGE_PARTS text parts will be converted. The remaining parts are discarded. By default, MAX_MESSAGE_PARTS is 2. To allow an unlimited number of message parts, specify a value of -1. When a value of 0 is specified, then no message content will be placed into the SMS message. This has the effect of using only header lines from the email message (for example, Subject:) to generated the SMS message.

Note that an email message containing both text and an attachment will typically consist of two parts. Note further that only message parts of type text are converted. All other MIME content types are discarded.

MAX_MESSAGE_SIZE (integer, >= 10)
With this option, an upper limit may be placed on the total number of bytes placed into the SMS messages generated from an email message. Specifically, a maximum of MAX_MESSAGE_SIZE bytes will be used for the one or more generated SMS messages. Any additional bytes are discarded.

By default, an upper limit of 960 bytes is imposed. This corresponds to MAX_MESSAGE_SIZE=960. To allow any number of bytes, specify a value of zero.

The count of bytes used is made after converting the email message from Unicode to either the SMSC's default character set or UCS2. This means, in the case of UCS2, that a MAX_MESSAGE_SIZE of 960 bytes will yield, at most, 480 characters since each UCS2 character is at least two bytes long.

Note that the MAX_MESSAGE_SIZE and MAX_PAGES_PER_MESSAGE options both serve the same purpose: to limit the overall size of the resulting SMS messages. Indeed, MAX_MESSAGE_SIZE=960 and MAX_PAGE_SIZE=160 implies MAX_PAGES_PER_MESSAGE=6. So why are there two different options? So as to allow control of the overall size or number of pages without having to consider the maximal size of a single SMS message, MAX_PAGE_SIZE. While this may not be important in the channel option file, it is important when using the MAXPAGES or MAXLEN addressing attributes described in Section 3.2.

Finally, note that the smaller of the two limits

is used.

MAX_PAGE_SIZE (integer, >= 10)
The maximum number of bytes to allow in a single SMS message is controlled with the MAX_PAGE_SIZE option. By default, a value of 160 bytes is used. This corresponds to MAX_PAGE_SIZE=160.

MAX_PAGES_PER_MESSAGE (integer, 1 - 255)
The maximum number of SMS messages to generate for a given email message is controlled with this option. In effect, this option truncates the email message, only converting to SMS messages that part of the email message which fits into MAX_PAGES_PER_MESSAGE SMS messages. See the description of the MAX_MESSAGE_SIZE option for further discussion.

By default, MAX_PAGES_PER_MESSAGE is set to the larger of 1 or MAX_MESSAGE_SIZE divided by MAX_PAGE_SIZE.

SMSC_DEFAULT_CHARSET (string)
With this option, the SMSC's default character set may be specified. Use the character set names given in the file

When this option is not specified, then US-ASCII is assumed.

When processing an email message, the header lines and text message parts are first decoded and then converted to Unicode. Next, the data is then converted to either the SMSC's default character set or UCS2 as described in the table below. Note that the UCS2 character set is a 16-bit encoding of Unicode and is often referred to as UTF-16.

USE_HEADER_PRIORITY (0 or 1)
This option controls handling of RFC822 Priority: header lines. By default, information from the Priority: header line is used to set the resulting SMS message's priority flag, overriding the default SMS priority specified with the DEFAULT_PRIORITY option. This case corresponds to USE_HEADER_PRIORITY=1. To disable use of the RFC822 Priority: header line, specify USE_HEADER_PRIORITY=0.

See the description of the DEFAULT_PRIORITY option for further information on the handling the the SMS priority flag.

USE_HEADER_REPLY_TO (0 or 1)
When SET_SMS_SOURCE_ADDRESS=1, this option controls whether or not a Reply-to: or Resent-reply-to: header line is considered for use as the SMS source address. By default, Reply-to: and Resent-reply-to: header lines are ignored. This corresponds to an option value of 0. To enable consideration of these header lines, use an option value of 1.

Note that RFC 2822 has deprecated the use of Reply-to: and Resent-reply-to: header lines. This is the reason why, by default, USE_HEADER_REPLY_TO=0.

USE_HEADER_RESENT (0 or 1)
When SET_SMS_SOURCE_ADDRESS=1, this option controls whether or not Resent- header lines are considered for use as the SMS source address. By default, Resent- header lines are ignored. This corresponds to an option value of 0. To enable consideration of these header lines, use an option value of 1.

Note that RFC 2822 has deprecated the use of Resent- header lines; hence, why this option has the default value of 0.

USE_HEADER_SENSITIVITY (0 or 1)
The USE_HEADER_SENSITIVITY option controls handling of RFC822 Sensitivity: header lines. By default, information from the Sensitivity: header line is used to set the resulting SMS message's privacy flag, overriding the default SMS privacy specified with the DEFAULT_PRIVACY option. This case, which is the default, corresponds to USE_HEADER_SENSITIVITY=1. To disable use of RFC822 Sensitivity: header lines, specify USE_HEADER_SENSITIVITY=0.

See the description of the DEFAULT_PRIVACY option for further information on the handling the the SMS privacy flag.

USE_UCS2 (0 or 1)
When appropriate, the channel will use the UCS2 character set in the SMS messages it generates. This is the default behavior and corresponds to USE_UCS2=1. To disable the use of the UCS2 character set, specify USE_UCS2=0. See the description of the SMSC_DEFAULT_CHARSET option for further information on character set issues.

4.3.2 SMS options

The following options allow for specification of SMS fields in generated SMS messages.

DEFAULT_DESTINATION_NPI (integer, 0 - 255)
By default, destination addresses will be assigned an NPI (Numeric Plan Indicator) value of zero. With this option, an alternate integer value in the range 0 to 255 may be assigned. Typical NPI values include

Values for this option may be specified in one of three ways:

  1. A decimal value, (for example, 10),
  2. A hexadecimal value prefixed by "0x" (for example, 0x0a), and
  3. One of the following case-insensitive text strings (the associated decimal value is shown in parentheses): data (3), default (0), e.163 (1), e.164 (1), e.212 (6), ermes (10), f.69 (4), internet (14), ip (14), isdn (1), land-mobile (6), national (8), private (9), telex (4), unknown (0), wap (18), x.121 (3).

DEFAULT_DESTINATION_TON (integer, 0 - 255)
By default, destination addresses will be assigned a TON (Type of Number) designator value of zero. With this option, an alternate integer value in the range 0 to 255 may be assigned. Typical TON values include

Values for this option may be specified in one of three ways:

  1. A decimal value, (for example, 10),
  2. A hexadecimal value prefixed by "0x" (for example, 0x0a), and
  3. One of the following case-insensitive text strings (the associated decimal value is shown in parentheses): abbreviated (6), alphanumeric (5), default (0), international (1), national (2), network-specific (3), subscriber (4), unknown (0).

DEFAULT_PRIORITY (integer, 0 - 255)
SMS messages have a mandatory priority field. The interpretation of SMS priority values is

With this option, the default priority to assign to SMS messages may be specified. When not specified, a default priority of 0 is used for PROFILE=GSM and CDMA, and a priority of 1 for PROFILE=TDMA.

Note that if USE_HEADER_PRIORITY=1 and an email message has an RFC822 Priority: header line, then the priority specified in that header line will instead be used to set the priority of the resulting SMS message. Specifically,

In translating RFC822 Priority: header line values to SMS priority flags, the following mapping is used:

DEFAULT_PRIVACY (integer, -1, 0 - 255)
Whether or not to set the privacy flag in an SMS message, and what value to use is controlled with the DEFAULT_PRIVACY and USE_HEADER_SENSITIVITY options. By default, a value of -1 is used for DEFAULT_PRIVACY.

The SMS interpretation of privacy values is as follows:


To translate RFC822 Sensitivity: header line values to SMS privacy values, the following mapping is used:

DEFAULT_SERVICE_TYPE (string, 0 - 5 bytes)
Service type to associate with SMS messages generated by the channel. By default, no service type is specified (that is, a zero length string). Some common service types are: CMT (cellular messaging), CPT (cellular paging), VMN (voice mail notification), VMA (voice mail alerting), WAP (wireless application protocol), and USSD (unstructured supplementary data services).

DEFAULT_SOURCE_ADDRESS (string, 0 - 20 bytes)
Source address to use for SMS messages generated from email messages. Note that the value specified with this option is typically overridden by the email message's originator address when SET_SMS_SOURCE_ADDRESS=1.

DEFAULT_SOURCE_NPI (integer, 0 - 255)
By default, source addresses will be assigned an NPI value of zero. With this option, an alternate integer value in the range 0 to 255 may be assigned. See the description of the DEFAULT_DESTINATION_NPI option for a table of typical NPI values.

DEFAULT_SOURCE_TON (integer, 0 - 255)
By default, source addresses will be assigned a TON designator value of zero. With this option, an alternate integer value in the range 0 to 255 may be assigned. See the description of the DEFAULT_DESTINATION_TON option for a table of typical TON values.

DEFAULT_VALIDITY_PERIOD (string, 0 - 252 bytes)
By default, SMS messages will be given no relative validity period, using the SMSC's default value. Use this option to specify a different relative validity period. Values may be specified in units of seconds, minutes, hours, or days:

A specification of 0, 0s, 0m, 0h, or 0d may be used to select the SMSC's default validity period. That is, when a specification of 0, 0s, 0m, 0h, or 0d is used, an empty string is specified for the validity period in generated SMS messages.

Note that this option does not accept values in UTC format.

DESTINATION_ADDRESS_NUMERIC (0 or 1)
Use this option to strip all non-numeric characters from the SMS destination address extracted from the email envelope To: address. For instance, if the envelope To: address is 

    "(800) 555-1212"@sms.siroe.com
then it will be reduced to 
    8005551212@sms.siroe.com
To enable this stripping, specify a value of 1 for this option. By default, this stripping is disabled which corresponds to an option value of 0. Note that when enabled, the stripping is done before any destination address prefix is added via the DESTINATION_ADDRESS_PREFIX option.

DESTINATION_ADDRESS_PREFIX (string)
In some instances, it may be necessary to ensure that all SMS destination addresses are prefixed with a fixed text string; for example, "+". This option may be used to specify just such a prefix. The prefix will then be added to any SMS destination address which lacks the specified prefix. To prevent being stripped by the DESTINATION_ADDRESS_NUMERIC option, this option is applied after the DESTINATION_ADDRESS_NUMERIC option.

PROFILE (string)
Specify the SMS profiling to be used with the SMSC. Possible values are GSM, TDMA, and CDMA. When not specified, GSM is assumed. This option is only used to select defaults for other channel options such as DEFAULT_PRIORITY and DEFAULT_PRIVACY.

SET_SMS_SOURCE_ADDRESS (0 or 1)
Use of this option forces the SMS source address TON to be set to alphanumeric (0x05), and the SMS source address to be an originator address extracted from the email message. As email messages may have a number of originator addresses, the particular address chosen is the one most likely to be the address to which any replies should be directed. Consequently, the choice is made from one of the seven following header lines, listed in order of decreasing preference:
Email message field
Restrictions
TON
1. Resent-reply-to: Requires USE_HEADER_RESENT=1 and USE_HEADER_REPLY_TO=1
0x05
2. Resent-from: Requires USE_HEADER_RESENT=1
3. Reply-to: Requires USE_HEADER_REPLY_TO=1
4. From:  
5. Resent-sender: Requires USE_HEADER_RESENT=1
6. Sender:  
7. Envelope From:  
8. DEFAULT_SOURCE_ADDRESS Used as a last resort (that is, when the envelope From: address is empty) As per DEFAULT_SOURCE_TON

The selected address is reduced to just its local and domain parts; that is, any source route, phrase, or comments are stripped from the address. Furthermore, if the length of the reduced address exceeds 20 bytes, it will be truncated to 20 bytes.

When none of the seven listed header lines are suitable, the default source SMS address is instead used as specified with the DEFAULT_SOURCE_ADDRESS option. In that case, the TON is set as per the DEFAULT_SOURCE_TON.

To enable this option, specify SET_SMS_SOURCE_ADDRESS=1. By default, this option is enabled.

USE_SAR (0 or 1)
Sufficiently large email messages may need to be broken into multiple SMS messages. When this occurs, the individual SMS messages can optionally have sequencing information added using the SMS sar_ fields. This produces a "segmented" SMS message which can be re-assembled into a single SMS message by the receiving terminal. Specify USE_SAR=1 to indicate that this sequencing information is to be added when applicable. The default is to not add sequencing information and corresponds to USE_SAR=0.

When USE_SAR=1 is specified, the REVERSE_ORDER option is ignored.

4.3.3 SMPP options

The following options allow for specification of SMPP protocol parameters. The options with names beginning with the string "ESME_" serve to identify the MTA when it acts as an External Short Message Entity (ESME); that is, when the MTA binds to an SMPP server in order to submit SMS messages to the server's associated SMSC.

ESME_ADDRESS_NPI (integer, 0 - 255)
By default, bind operations will specify an ESME NPI value of zero indicating an unknown NPI. With this option, an alternate integer value in the range 0 to 255 may be assigned. See the description of the DEFAULT_DESTINATION_NPI option for a table of typical NPI values.

ESME_ADDRESS_TON (integer, 0 - 255)
By default, bind operations will specify an ESME TON value of 0. With this option, an alternate integer value in the range 0 to 255 may be assigned. See the description of the DEFAULT_DESTINATION_TON option for a table of typical TON values.

ESME_IP_ADDRESS (string, 0 - 15 bytes)
When binding to the SMPP server, the bind PDU indicates that the client's (that is, ESME's) address range is an IP address. This is done by specifying a TON of 0x00 and an NPI of 0x0d. The value of the address range field is then set to be the IP address of the host running the SMS channel. Specify the IP address in dotted decimal format; for example, 127.0.0.1.

ESME_PASSWORD (string, 0 - 8 bytes)
When binding to the SMPP server, a password may be required. If so, then specify that password with this option. By default, a zero-length password string is presented.

ESME_SYSTEM_ID (string, 0 - 15 bytes)
When binding to the SMPP server, a system id for the MTA may be supplied. By default, no system id is specified (that is, a zero-length string is used). To specify a system id, use this option.

ESME_SYSTEM_TYPE (string, 0 - 12 bytes)
When binding to the SMPP server, a system type for the MTA may be supplied. By default, no system type is specified (that is, a zero-length string is used).

MAX_PAGES_PER_BIND (integer, >= 0)
Some SMPP servers may limit the maximum number of SMS messages submitted during a single, bound session. In recognition of this, this option allows specification of the maximum number of SMS messages to submit during a single session. Once that limit is reached, the channel will unbind, close the TCP/IP connection, re-connect, and then rebind.

By default, a value of 1024 is used for MAX_PAGES_PER_BIND. Note that the channel will also detect ESME_RTHROTTLED errors and adjust MAX_PAGES_PER_BIND during a single run of the channel accordingly.

REVERSE_ORDER (0 or 1)
When an email message generates more than one SMS message, those SMS messages can be submitted to the SMSC in sequential order (REVERSE_ORDER=0), or reverse sequential order (REVERSE_ORDER=1). Reverse sequential order is useful for situations where the receiving terminal displays the last received message first. In such a case, the last received message will be the first part of the email message rather than the last. By default, REVERSE_ORDER=1 is used.

Note that this option is ignored when USE_SAR=1 is specified.

SMPP_MAX_CONNECTIONS (integer, 1 - 50)
This option controls the maximum number of simultaneous SMPP connections per process. As each connection has an associated thread, this option also places a limit on the maximum number of "worker" threads per process. By default, SMPP_MAX_CONNECTIONS=20.

SMPP_PORT (integer, 1 - 65535)
The TCP port which the SMPP server listens on may be specified with either this option or the port channel keyword. This port number must be specified through either of these two mechanisms. If it is specified with both mechanisms, then the setting made with the SMPP_PORT option takes precedence. Note that there is no default value for this option.

SMPP_SERVER (string, 1 - 252 bytes)
By default, the IP host name of the SMPP server to connect to is the official host name associated with the channel; that is, the host name shown on the second line of the channel's definition in MTA's configuration. This option may be used to specify a different host name or IP address which will override that specified in the channel definition. When specifying an IP address, use dotted decimal notation; for example, 127.0.0.1.

TIMEOUT (integer, >= 2)
By default, a timeout of 30 seconds is used when waiting for writes of data to the SMPP server to complete or for data to be recieved from the SMPP server. Use the TIMEOUT option to specify, in units of seconds, a different timeout value. The specified value should be at least 2 seconds.

4.3.4 Localization options

In constructing SMS messages, the SMS channel has a number of fixed text strings it puts into those messages. These strings, for example, introduct the email's From: address and Subject: header line. With the channel options described below, versions of these strings may be specified for different languages and a default language for the channel then specified. This section of the option file appears as follows,

Within each [language=x]block, the localization options relevant to that language may be specified. If a particular option is not specified within the block, then the global value for that option is used. A localization option specified outside of a [language=x] block sets the global value for that option.

For the options listed below, the string values must be specified using either the US-ASCII or UTF-8 character sets. Note that the US-ASCII character set is a special case of the UTF-8 character set.

CONTENT_PREFIX (string, 0 - 252 bytes)
Text string to place in the SMS message before the content of the email message itself. Default global value is the US-ASCII string "Msg:".

FROM_FORMAT (string, 0 - 252 bytes)
Formatting template to format the originator information to insert into the SMS message. The default global value is the US-ASCII string "$a" which substitutes in the originator's email address. See Section 4.3.5 for futher details.

FROM_NONE (string, 0 - 252 bytes)
Text string to place in the SMS message when there is no originator address to display. The default global value is an empty string.

Note that normally, this option will never be used as sites will typically reject email messages which lack any originator address.

LANGUAGE (string, 0 - 40 bytes)
The default language group to select text strings from. If not specified, then the language will be derived from the host's default locale specification. If the host's locale specification is not available or corresponds to "C", then i-default will be used. (i-default corresponds to "English text intended for an international audience.)

LINE_STOP (string, 0 - 252 bytes)
Text string to place in the SMS message between lines extracted from the email message. The default global value is the US-ASCII space character, " ".

NO_MESSAGE (string, 0 - 252 bytes)
Text string to place in the SMS message to indicate that the email message had no content. The default global value is the US-ASCII string "[no message]".

REPLY_PREFIX (string, 0 - 252 bytes)
Reserved for future use. The default global value is the US-ASCII string "Re: ".

SUBJECT_FORMAT (string, 0 - 252 bytes)
Formatting template to format the content of the Subject: header line for display in the SMS message. The global default value for this option is the US-ASCII string "($s)". See Section 4.3.5 for futher details.

See the SUBJECT_NONE option for a description of the handling when there is no Subject: header line or the content of that header line is an empty string.

SUBJECT_NONE (string, 0 - 252 bytes)
Text string to display when the originating email message either has no Subject: header line, or the Subject: header line's value is an empty string. The default global value for this option is the empty string.

4.3.5 Formatting templates

The formatting templates specified with the FROM_FORMAT and SUBJECT_FORMAT channel options are UTF-8 strings which may contain a combination of literal text and substitution sequences. Assuming the sample email address of

Jane Doe <user@siroe>

The recognized substitution sequences are

Sequence Description
$a
 Replace with the local and domain part of the originator's email address (for example, "user@siroe")
$d
 Replace with the domain part of the originator's email address (for example, "domain")
$p
 Replace with the phrase part, if any, of the originator's email address (for example, "Jane Doe")
$s
 Replace with the content of the Subject: header line
$u
 Replace with the local part of the originator's email address (for example, "user")
\x
 Replace with the literal character "x"

For example, the formatting template

From: $a

produces the text string

From: user@siroe

The construct,

${xy:alternate text}

may be used to substitute in the text associated with the sequence x. If that text is the empty string, the text associated with the sequence y is instead used. And, if that text is the empty string, to then substitute in the alternate text. For example, consider the formatting template

From: ${pa:unknown sender}

For the originator email address

John Doe <jdoe@siroe.com>

which has a phrase part, the template produces

From: John Doe

However, for the address

jdoe@siroe.com

which lacks a phrase, it produces

From: jdoe@siroe.com

And for an empty originator address, it produces

From: unknown sender

4.4 Adding additional SMS channels

You may configure the MTA to have more than one SMS channel. There are two typical reasons to do this

  1. To communicate with different SMPP servers.
  2. To communicate with the same SMPP server but using different channel options.

Handling Case 1 is quite straightforward: just add an additional SMS channel to the configuration, being sure to (a) give it a different channel name, and (b) associated different host names with it. For example,

sms_mway master port 55555 threaddepth 20
smpp.siroe.com

sms_ace master port 777 threaddepth 20
sms.ace.net

Case 2, in which the same SMPP server is to be used requires use of the SMPP_SERVER channel option. This need arises from the fact that two different channels cannot have the same official host name (that is, the host name listed in the second line of the channel definition). For example, if you need two different channels which communicate with the same SMPP server, then you could use the following channel definitions,

sms_mway_1 master port 55555 threaddepth 20
SMS-DAEMON-1

sms_mway_2 master port 55555 threaddepth 20
SMS-DAEMON-2

and rewrite rules,

sms-1.siroe.com $u%sms-1.siroe.com@SMS-DAEMON-1
sms-2.siroe.com $U%sms-2.siroe.com@SMS-DAEMON-2

Then, each of these two channel would specify SMPP_SERVER=smpp.siroe.com in their channel option files.

4.5 Adjusting the frequency of delivery retries

When an SMS message cannot be delivered owing to temporary errors (for example, the SMPP server is not reachable), the email message is left in the delivery queue and retried again later. Unless configured otherwise, the Job Controller will not re-attempt delivery for an hour. For SMS messaging, that is likely too long to wait. As such, it is recommended that the backoff channel keyword be used with the SMS channel to specify a more aggressive schedule for delivery attempts. For example,

sms_mway master port 55555 threaddepth 20 \
  backoff pt2m pt5m pt10m pt30m notices 1
smpp.siroe.com

With the above settings, a redelivery attempt will be made at two minutes after the first attempt. If that then fails, then five minutes after the second attempt. Then ten minutes later and finally every thirty minutes. The notices 1 channel keyword causes the message to be returned as undeliverable if it cannot be delivered after a day.

4.6 An example configuration (MobileWay)

The Messaging Server SMS channel may be used with any SMPP V3.4 compatible SMPP server. For purposes of illustrating an example configuration, this section explains how to configure the SMS channel for use with a MobileWay SMPP server. MobileWay (http://www.mobileway.com/) is a leading provider of global data and SMS connectivity. By routing your SMS traffic through Mobileway, you can reach SMS subscribers on most of the major SMS networks throughout the world.

When requesting an SMPP account with MobileWay, you may be asked to answer the following questions:

  1. IP address of your SMPP client: Supply the IP address of your Messaging Server system as seen by other domains on the Internet.
  2. Default validity period: This is the SMS validity period which MobileWay will use should a validity period not be specified in the SMS messages you submit. SMS messages which cannot be delivered before this validity period expires will be discarded. Supply a reasonable value (for example, 2 days, 7 days, etc.).
  3. Window size: This is the maximum number of SMS messages your SMPP client will submit before it will stop and wait for responses from the SMPP server before submitting any further SMS messages. You must supply a value of 1 message.
  4. Timezone: Specify the timezone in which your Messaging Server system operates. The timezone should be specified as an offset from GMT.
  5. Timeout: Not relevant to one-way SMS messaging.
  6. IP address and TCP port for outbind requests: Not relevant for one-way SMS messaging.

After supplying MobileWay with the answers to the above questions, they will provide you with an SMPP account and information necessary to communicate with their SMPP servers. This information includes

Account Address: a.b.c.d:p
Account Login: system-id
Account Passwd: secret

The Account Address field is the IP address, a.b.c.d, and TCP port number, p, of the MobileWay SMPP server you will be connecting to. Use these values for the SMPP_SERVER and SMPP_PORT channel options. The Account Login and Passwd are, respectively, the values to use for the ESME_SYSTEM_ID and ESME_PASSWORD channel options. Using this information, your channel's option file should include

SMPP_SERVER=a.b.c.d
SMPP_PORT=p
ESME_SYSTEM_ID=system-id
ESME_PASSWORD=secret

Now, to interoperate with MobileWay you need to make two additional option settings

ESME_ADDRESS_TON=0x01
DEFAULT_DESTINATION_TON=0x01

The rewrite rule in the imta.cnf file can appear as

sms.your-domain $u@sms.your-domain

And, the channel definition in the imta.cnf file can appear as

sms_mobileway master
sms.your-domain

Once the channel option file, rewrite rule, and channel definition are in place, a test message may be sent. MobileWay requires International addressing of the form

+<country-code><subscriber-number>

For instance, to send a test message to the North American subscriber with the subscriber number (800) 555-1212, you would address your email message to

+18005551212@sms.your-domain

5.0 Debugging

To debug the channel, specify the master_debug channel keyword in the channel's definition. For example,

sms_mway master port 55555 threaddepth 20 \
  backoff pt2m pt5m pt10m pt30m notices 1 master_debug

With the master_debug channel keyword, basic diagnostic information about the channel's operation will be output to the channel's log file. For verbose diagnostic information about the SMPP transactions undertaken by the channel, also specify

DEBUG=-1

in the channel's option file.