SMTP Interface Developer Guide - Telstra · CONFIDENTIAL INFORMATION: Do not disclose SMTP Interface Developer Guide SMTP Interface Developer Guide v7.8.1 © 2015 Soprano Design Pty

CONFIDENTIAL INFORMATION: Do not disclose

SMTP Interface Developer Guide

© 2015 Soprano Design Pty Ltd

SMTP Interface Developer Guide v7.8.1

Telstra Integrated Messaging powered by Soprano



All rights reserved Soprano Design Pty Ltd. No parts of this work may be reproduced in any form or by any means -graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrievalsystems - without the written permission of SOPRANO Design Pty Ltd.

Products that are referred to in this document may be either trademarks and/or registered trademarks of therespective owners.

While every precaution has been taken in the preparation of this document, the publisher and the author assume noresponsibility for errors or omissions, or for damages resulting from the use of information contained in this documentor from the use of programs and source code that may accompany it. In no event shall the publisher and the authorbe liable for any loss of profit or any other commercial damage caused or alleged to have been caused directly orindirectly by this document.

Printed: November 2015

SMTP Interface Developer Guide v7.8.1

© 2015 Soprano Design Pty Ltd and Confidentiality Statement



© 2015 Soprano Design Pty Ltd 3SMTP Interface Dev eloper Guide v 7.8.1

Table of Contents

5Setup

5Access

5Standard Email Configuration

7Simple Email Configuration

11Email Structure

11Standard Email API

12Simple Email API

15Message Parameters

15Standard Email API Parameters

20Simple Email API Parameters

22Advanced Messaging Techniques

22Advanced Standard Email API

27Advanced Simple Email-to-SMS

27Supported Email Types

28Troubleshooting

29Appendices

29Appendix A - API Capabilities

33Appendix B – Abbreviations

34Appendix C – Response Details

36Appendix D – 'dcs' Parameter – Detail

38Appendix E - Example Code

39Appendix F - ServiceNow Integration

42Appendix G - Handset Profile Setup for MMS



SMTP Interface Dev eloper Guide v 7.8.14© 2015 Soprano Design Pty Ltd

Overview and Document PurposeTelstra Integrated Messaging powered by Soprano is an industry-leading mobile messaging application which enablesusers to send SMS, Premium SMS, MMS and WAP Push mobile messages.

This document provides a technical overview of the SMTP Interface for the Telstra Integrated Messaging powered bySoprano platform.

Intended AudienceThis document is intended for TIM customers interested in using TIM’s SMTP (Email) interface for sending SMS andMMS messages.

References[1] Soprano Design (2004), SOPRANO Corporate Gateway Platform – User Manual[2] Dawson, F. and Howes, T. (1998), RFC 2426 - vCard MIME Directory Profile <HTTP://www.ietf.org/rfc/rfc2426.txt>[3] Dawson, F. and Stenerson, D. (1998), RFC 2445 - Internet Calendaring and Scheduling Core ObjectSpecification (iCalendar), <HTTP://www.ietf.org/rfc/rfc2445.txt>[4] Dawson, F. et al. (1998), RFC 2447 - iCalendar Message-Based Interoperability Protocol (iMIP), <HTTP://www.ietf.org/rfc/rfc2447.txt>[7] Freed, N. and Borenstein, N. (1996), RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One:Format of Internet Message Bodies, <HTTP://www.faqs.org/rfcs/rfc2045.html>[8] ETSI (1996), Digital cellular telecommunications system (Phase 2+); Alphabets and language-specificinformation (GSM 03.38) <HTTP://pda.etsi.org/pda/AQuery.asp>[9] Howes, T. et al. (1998), RFC 2425 - A MIME Content-Type for Directory Information, <HTTP://www.ietf.org/rfc/rfc2425.txt>[10] Silverberg, S. et al. (1998), RFC 2446 - iCalendar Transport-Independent Interoperability Protocol (iTIP)Scheduling Events, BusyTime, To-dos and Journal Entries, <HTTP://www.ietf.org/rfc/rfc2446.txt>[11] SMPP Developers Forum (1999), Short Message Peer to Peer Protocol Specification v3.4, Issue 1.2[12] SMS Forum (2002), Short Message Application Protocol Specification Version 1.0-Draft09, HTTP://www.smsforum.net




SetupSetup of up the 'Email-to-SMS' SMTP interface involves three parts:AccessSimple Email API ConfigurationStandard Email API Configuration

Access Telstra SMTP API Access

The SMTP API is available via the internet.

TIM SMTP server address is as follows:

IP Network Address tim.telstra.com

Port 25

Standard Email ConfigurationThe following configuration parameters are only visible to Customer Administrators.

Certain configuration settings must be established via the web interface.

ConfigurationTo enable Email-to-SMS, the customer needs to provision their Email API Preferences.

Setup > Company Setup > Email API Preference




Remote Hosts - Remote hosts are a set of your email server's IP addresses (if you wish to add access policycontrol over which mail servers can access the Email API services).

e.g. 209.85.198.250

Note: If your organisation uses Outbound Email spam/virus checking services, you may wish to add their mail serveraddresses in this remote hosts list, as these addresses will be where the message appears to originate from.

Rather than specifying all fully qualified domain names, users can also enter a wild card (e.g. '*.url.com'), so that anysource mail transfer agent within that domain can be used.

Wildcards not supported: .com, *.com.au, *.co, *.gov, *.net, *.edu, *.edu.au etc, or any IP address wildcard such as*.168.1.1 or 192.168.1.

If your business is using cloud email providers, such as Messaging.Microsoft.comor Google, or is using outbound email virus and spam control service providers, youmay not be able to confirm all IP addresses from these service providers; therefore,the field should be left blank.

Domains - Domains are the originating email domains of your messages (e.g. tim.telstra.com). This field can be usedto allow any 'From' address to be used.

Always Check Username - When ticked, username must match the provisioned username.

Always Check Password - When ticked, password must be present in the email for authentication; if not ticket,implicit session applies.

Send Message Limit - This only applies to Simple Email-to-SMS. This option allows you to limit the number ofSMSes which will be created from the email message. The message will be truncated at that point. The number ofmessages that can be selected is 1, 2 or No Limit.

The number of characters in the message depends on the encoding:7 bit encoding = 160 characters8 bit encoding = 140 characters16 bit encoding = 70 characters

Note: For 'Simple' SMS, 'Always Check Password' must not be clicked. For 'Standard' SMS, the 'Simple Email API'section does not apply.

Additional MMS ConfigurationBefore you can send MMS using the SMTP API, you may need to check that a default handset profile is assigned tothe customer account.

Click here for more information.




Addressing - SMSTo send SMS messages using the SMTP interface Standard Email-to-SMS method, you must assign the ‘To’ emailaddress as follows:

Destination email address [email protected]

The body of the email must contain parameters that define the username, password, destination mobile number(s),delivery and other options.

Notes: SMTP interface is supports both plain-text and HTML-based emails. Subject line text is not needed with this method, and is ignored if entered. All parameter names are not case sensitive

Addressing - MMSTo send MMS messages using the SMTP interface Standard Email-to-MMS method, you must assign the ‘To’ emailaddress as follows:

Destination email address [email protected]

Simple Email ConfigurationConfigurationFollow the same configuration instructions as 'Standard' Email-to-SMS.

The 'Simple' Email-to-SMS method requires the 'Always Check Password' option in 'Email Preference' to beunchecked. This requires a Customer Administrator licence.

Certain configuration settings must be established via the web interface.

To enable Email-to-SMS, the customer needs to provision their Email API Preferences.

Setup > Company Setup > Email API Preference




Remote Hosts - Remote hosts are a set of your email server's IP addresses (if you wish to add access policycontrol over which mail servers can access the Email API services).

e.g. 209.85.198.250

Note: If your organisation uses Outbound Email spam/virus checking services, you may wish to add their mail serveraddresses in this remote hosts list, as these addresses will be where the message appears to originate from.

Rather than specifying all fully qualified domain names, users can also enter a wild card (e.g. '*.url.com'), so that anysource mail transfer agent within that domain can be used.

Wildcards not supported: .com, *.com.au, *.co, *.gov, *.net, *.edu, *.edu.au etc, or any IP address wildcard such as*.168.1.1 or 192.168.1.

If your business is using cloud email providers, such as Messaging.Microsoft.comor Google, or is using outbound email virus and spam control service providers, youmay not be able to confirm all IP addresses from these service providers; therefore,the field should be left blank.

Domains - Domains are the originating email domains of your messages (e.g. tim.telstra.com). This field can be usedto allow any 'From' address to be used.

Always Check Username - When ticked, username must match the provisioned username.

Always Check Password - When ticked, password must be present in the email for authentication; if not ticket,implicit session applies.



Note: The 'Simple' Email-to-SMS method requires the 'Always Check Password'option in 'Email API Preference' to be unchecked. This requires a CustomerAdministrator licence.




Email White List - A selection of Lists which can be used to determine the User email addresses permitted to sendSMS using the 'Email-to-SMS' interface.

e.g. In an organisation where there are 100 Users, and you would like to enable 'Email-to-SMS' without provisioningeach employee with a TIM account.

Cost Centre from Whitelist - You may use the whitelist to define the cost centre of each user permitted to sendemails using Email-to-SMS. Include the cost centre information as part of the file you upload, and identify whichcolumn this information is located in using this form field. The cost centre associated to the user will then be used onmessage reports for SMSes sent using Email-to-SMS.

Email Signature Filter - This field is used to create a filter to remove a standardised email footer or confidentiality

disclaimer from Email2SMS requests being sent in to the platform.

The filter will match a text string which starts at the beginning of a line within the message and is case-sensitive. Thestring specified in the filter should be the first line of text which constitutes the portion of the email that needs to beremoved.

It is important to note that if the match is found at the beginning of a line anywhere in the email message, it will applyfrom that point. It is recommended that the criteria for the filter be as specific as possible to avoid unwanted truncationof Email2SMS messages. If a match is not found, all of the email text will be used in the generation of SMSes.

Example: Confidentiality disclaimer starting with a line of asterisks:**********************************************************************

Privacy disclaimer starts here... etc

It is recommended that the entire line of asterisks is copied and pasted into the Email Signature Filter field, as thiswould provide the most accurate method of avoiding accidental truncation.

Example: Email Signature with Name:Demo User

Demo Company LTD

PH: 1111111111... etc

As the user's name will vary with each message, a generic filter can be set up using the string "Demo Company LTD"as the criteria for the filter. There is a risk of accidental truncation of the message if the full company name with thesame case as the signature is used within the message and is at the beginning of a line.

Pass Code - Used in the Subject as a method for authenticating an 'Email-to-SMS' from a User that does not need tobe registered as a User with a TIM account. This Pass Code is only used if the Allow Pass Code Check checkboxis clicked.

Client Message ID Pattern - This field allows 'Simple' Email2SMS users to extract a Client Message ID from theiremail subject. The regular expression specified in the pattern field will then be used to extract the Client Message IDin the email subject, and associate it with the all inbound/outbound messages in the conversation.

e.g. A customer sends an SMS to a call centre regarding a wireless connectivity issue. Call centre staff uses 'Simple'Email2SMS to respond to the SMS with a ticket/ reference ID (i.e. set in the email subject). The ticket/ reference ID




will then be extracted from the email subject and set as the Client Message ID.

This means you can quickly identify all messages that belong to a single conversation by checking the ClientMessage ID.

When setting a Client Message ID in this way, there is a limitation of 100 characters (measured in bytes). If yourClient Message ID exceeds 100 characters it will be trimmed to fit the 100 character limit and the message will passthrough to the platform successfully.

Example 1: Email Subject: 'ABC 123456 - Connectivity Issue Identified'Client Message ID Pattern: ABC\s*[\d]{6}(ABC = The leading 3 letters; \s* = any number of spaces; \d{6} = a series of 6 digits.)This means that API will extract any series of characters which matches the above pattern from the 'Subject'

field of emails and set this as the 'Client Message ID', thus linking any messages sharing the same ID together.

Example valid IDs using the above example might be: ABC 123456; ABC 584327; ABC 987654

Example 2: 'SUPPORT-[\d]{4}' will only match the characters 'SUPPORT-5832' in the message subject: 'Re: Re:

SUPPORT-5832 case established' and disregard any other characters.

Strip Client Message ID When Matched - This tickbox works in conjunction with the Client Message ID Patternsetting. If you have the system set to detect a client message ID in your Simple email2SMS requests, ticking thisbox will then remove that client message ID from your email request before it is converted to an SMS. This meansthat the client message ID will not be passed through as part of your message.

Once saved, the following details will be displayed:

Created By/At - Who the email preferences were created by, and when.

Last Modified By/At - Who the email preferences were last modified by, and when.

AddressingFollow the same configuration instructions for standard Email-to-SMS.

Simple Email to SMS method requires the 'Always Check Password' option in 'Email Preference' to be unchecked.This is a Platform Administrator-access only feature.

To send SMS messages using the SMTP interface Simple Email to SMS method then you must set the ‘to’ emailaddress to the following value:

Destination email address <mobile_number>@sms.tim.telstra.com

NOTE: Where <mobile_number> is the handset mobile number (in international format). Up to 300 recipientaddresses can be included on your email.

This method takes the email body text and converts it to SMS. There is only basic security applied to this method,based on identifying the TIM username within the originating email (From) address. No password is required.

Notes: SMTP interface supports both Plain Text and HTML-based emails. The email should be addressed to the destination mobile number. The mobile number must be in international format. e.g. 61491234567. The subject field of the email must be set. The value is ignored. Parameter names are not case-sensitive




Email StructureThe email structure varies depending on whether you are sending a message using the 'Standard Email' API or'Simple Email' API.

Please note that all mobile numbers must be entered in international format whenusing the APIs & interfaces.

Standard Email APIThe TIM SMTP interface parses the text sent in the body of the email, and uses it to create and send one or moreSMS messages.

The 'subject' line of the email is ignored.

The 'body' of the email takes the form:<parameter name>=<value><parameter name>=<value><parameter name>=<value>

SMSAn example of an email which results in sending a single SMS message is as follows: TO: [email protected]: [email protected]: Hello World

Email Body:

username=Acme

password=Acmepwd

destination=61491234567

text=Hello World!

The above example will result in an SMS with 'Hello World!' being sent to 61491234567 .

To send the above message to multiple destinations, append the required destination addresses to destination,separated by commas (,).

TO: [email protected]: [email protected]: Hello World

Email Body:

username=Acme

password=Acmepwd

destination=61491234567,61491234568

source=61498765432

text=Hello World!

The above email will send the text “Hello World!” as an SMS message to destinations: 61491234567, 61491234568

The parameters which can be used in the email body (such as 'username', 'text') are described in detail in theMessage Parameters section.




Notes for SMS: Each email could start with 2 lines containing the 'username' and 'password' parameters, so that authentication cantake place.If 'username' is not provided then the gateway will use the 'from address' of the email to find the user; if not found,the domain of the 'from address' will be used to match the domain field configured in the customer profile to find thecustomer and then use its primary user.If 'password' is not provided and the 'alwaysCheckPassword' setting in the customer profile is selected then theemail will be rejected.If 'password' is not provided and the 'alwaysCheckPassword' setting is not selected then implicit authentication isapplied using the username.Parameters may be submitted in any order.If multiple destinations are used, a mandatory 'source' address has to be provided.When setting multiple destination there should be no space separating the destination numbers but a < , >(comma), e.g. (destination = 61491234567,61491234568).

MMSAn example of an email which results in sending a single MMS message with an image attachment is as follows:TO: [email protected]: [email protected]: Hello World

Email Body:

[email protected]

password=egpassword1

destination=61491234567

source=61491234568

text=Hello World

content_type=4

Then attach the image file you wish to send via your Email-to-MMS interface.

Supported image types are:GIFJPGPNG

Simple Email APIThis method is the simplest form of sending an SMS. The functional control parameters are loaded with defaultvalues, and the body text is all that is required to send a 'Simple' SMS.

Since no parameters are required by this method, the destination address is used as the name (prefix before the '@'sign) of the recipient’s email address.

An example of a 'Simple' email, which results in sending a single SMS message, is as follows:

TO: <mobile_number>@sms.tim.telstra.comFROM: [email protected]: Hello World

Email Body:

Hello World!

The above example results in the SMS message: 'Hello World!' being delivered to the specified mobile number .




For more information on limiting a 'Simple' Email to SMS message to a single SMS click here.

Notes for SMS:The email from address is matched to a username. If no match is found, the domain of the 'from' address of theemail will be used to match the domain field configured in the customer profile to find the customer and then use itsprimary user.If the 'alwaysCheckPassword' setting in the customer profile is selected then all 'Simple' Email-to-SMS emails willbe rejected.Both HTML and plain-text emails are supported. Emails with no 'body text' are not processed.Attachments are not supported.

Limiting SimpleEmail2SMS to a Single SMSThe following instructions will assist you in limiting your Email-to-SMS to a single SMS. These settings are company-wide and can only be edited by a Customer Administrator.

Company Setup > Customer Information > Email Preferences









Message ParametersMessage parameters may vary depending on the interface being used:Standard Email to SMS InterfaceSimple Email to SMS Interface

Standard Email API ParametersThe following table describes all the parameters supported by the TIM SMTP interface which can be included withinan email body.

Parameter Description Example Optional /mandatory

Notes

registered Request deliveryacknowledgementfor the message(i.e. from the SMSCto handset)

registered=1 Optional 0 Off

1 Send Network DR

2 Reserved

3 Send IntermediaryDR

4 Send both Networkand IntermediaryDR

5 Reserved

ack Indicating if aresponse email isrequired for therequest, the contentof the responseemail will havemessage ID, andstatus etc.

ack=1 Optional 0 No

1 Yes

content Used in batchmessaging.Contains the data tobe inserted into thetemplate with eachparameter,separated by thedelimiter value.

content=61492345678,George,3.00pmcontent=61493456789,Fred,3.30pm

Optional.Mandatory iftemplateparameter isspecified

The destination addressmust be the first dataelement of the contentvalue and conform to theformat specified by thedestinationTON anddestinationNPIparameters.

contentType Specifies the typeof content in thetext or dataparameter.

This parameter ismainly used as aneasy way to set theudh to indicate useof binary messageslike logos andringtones.

contentType=1 Optional:if udh field is notpresent, defaultcontentType=1

If neithercontentType norudh is specified,then any datafield is treated astextual (i.e.contentType=1)

If templateparameter isused, then it ismandatory thatcontentType=1

1 Plain text.

2 Nokia Ringtone.

3 Nokia OperatorLogo.

4 Nokia PictureMessage.

5 Nokia Group Logo.

6 Business Card(vCard).

7 Calendar Event(vCalendar).

8 Raw Binary Data(data includesUDH).

data Message content(hexadecimal

data=This is a continuousdata=(no line break) SMS

One of thefollowing type of

160 characters or 130bytes maximum





Notes

encoding). The dataparameter is usedto send NokiaRingtones, NokiaOperator Logos,Nokia PictureMessages, NokiaGroup Logos or rawbinary data (asindicated by thecontentTypeparameter, or thepresence of the udhparameter).

parameters mustbe present ineach EMAIL:

textdata content

The example to the leftcreates an SMS with 1line (c.f. the textexample below).

dcs Indicates the DataCoding Scheme forthe SMS.

For more details,see Table 2 andTable 3

Note, DCS =16,20,24 representflash typemessages.

dcs=0 Optional:dcs=0 (ifcontentType = 1,6 or 7)dcs=4 (ifcontentType = 2,3, 4, 5 or 8)

0 SMSC defaultalphabet, (160characters permessage)

1 IA5 (CCITTT.50)/ASCII(ANSI X3.4)

2 Octetunspecified (8-bit binary)

3 Latin 1 (ISO-8859-1)

4 Octetunspecified (8-bit binary), (140characters permessage)

5 JIS (X 0208-1990)

6 Cyrllic (ISO-8859-5)

7 Latin/Hebrew(ISO-8859-8)

8 UCS2 (ISO/IEC-10646), (70characters permessage)

9 PictogramEncoding

10 ISO-2022-JP(Music Codes)

13 Extended KanjiJIS(X 0212-1990)

14 KS C 5601

16 Flash Message,Standard GSM7 bit Alphabet.(160 characters





Notes

per message)

20 Flash Message,Octetunspecified (8-bit binary), (140 charactersper message)

24 Flash Message,UCS2 (ISO/IEC-10646), (70characters permessage)

delay Delay delivery ofSMS to recipient.

delay=120 Optional:delay=0

Integer relative delay(from messagesubmission time) inminutes.

delimiter Used in batchmessaging.

Allowscustomisation of thedelimiter used in thecontent field.

delimiter=, Optional:delimiter=,

Typically a singlecharacter such as ‘,’, ‘.’,‘|’ or ‘;’.

destinationNPI Numbering PlanIndicator fordestinationaddress(es).

destinationNPI=1 Optional:destinationNPI=1

0 Unknown

1 ISDN (E.163/E.164)

3 Data (X.121)

4 Telex (F.69)

6 Land Mobile(E.212)

8 National

9 Private

10 ERMES

14 Internet (IP)

18 WAP Client ID

destinationTON Type of Number tobe used fordestinationaddress(es).

destinationTON=1 Optional:destinationTON=1

0 Unknown

1 International

2 National

3 NetworkSpecific

4 SubscriberNumber

5 Alphanumeric

6 Abbreviated

messageClass Message class forMT messages.

messageClass=0 Optional:messageClass=0

0 Class 0

1 Class 1 -defaultmeaning: ME-specific.

2 Class 2 - SIM-specificmessage





Notes

3 Class 3 -defaultmeaning: TEspecific

password Password for thisuser. Provided inSMTP Authorizationfield.

password=Acmepwd Mandatory Passwords are case-sensitive.

priority Message priority,used for messagerouting andprioritisation.

priority=2 Optional:priority=1

Lower numbersrepresent higherpriorities.

replyTo When it is presenttogether withreplyToTON, allreply messages willbe delivered to thisaddress based onthe replyToTONtype: MOBILE,EMAIL, or URL.

[email protected]; replyTo=61490112233; orreplyTo=http://myhost.com/reply

Optional. Maximum 50characters.

If replyToTON=0, thisfield will be ignored

replyToTON Type of Number tobe used for replyaddress to indicateif replyTo field is:INBOX, MOBILE,EMAIL, URL.

Optional:replyToTON=1

replyToTon=8

replyToTon=1

0 INBOX1 MOBILE8 EMAIL10 URL

replyToNPI Not used, reservedfor future.

source The client sourceaddress.

source=61492333444

Additional example for sending asan Alphanumeric address:

source=alphatag

Notes:

You may have to request anAlpha address (alphatag) fromyour service provider.

You can not reply to Messagessent with an alpha address.

Optional, defaultis null

This is the address thatthe message will appearto come from.

Note: Your serviceprovider may only allowyou to send from alimited number ofaddresses.

Note: If you define thesource address in therequest, some of themessage reply featuresare disabled, includinglinking Client MessageID of submittedmessage to theresponse. i.e. If you usethe 'source' parameter inthe request the replyToand replyToTONaddress specified will beignored.

sourceNPI The client sourceaddress NPI

sourceNPI=1 Optional,default=1

Deprecated field





Notes

sourceTON The client sourceaddress TON

sourceTON=1 Optional,default=1

Deprecated field

template Used in batchmessaging.

The equivalent ofthe text field for'batch messages'. Message template,including optionalpersonalised fields({1} to {N}).

template=Hi {1}, your appointment isat {2} tomorrow

Optional.Mandatory ifcontentparameter isspecified

Note that field1 is usedfor the recipient’s mobilephone number and istypically not included inthe message template.

Any message built froma template is treated astext – i.e.contentType=1.

text The text content ofthe message.

In MMS contexttext as anattachment, theexample shownwould be'Hello Worldtext=We are here!'

text=Hello Worldtext=We are here!

Exactly one ofthe followingtypes ofparameters mustbe present ineach EMAIL:

text data content.

May be included 1 ormore times in themessage.

The example to the leftcreates an SMS with 2lines.

If text is over 160characters long (forGSM), a concatenatedmulti-part message willbe sent.

destination Destination orrecipient number.Typically a validISDN number, butother numbers canbe specified alongwith the use of thedestinationTON anddestinationNPIparameters.Messages can besent to multiplerecipients byseparating thenumbers withcommas.

destination=61492345678,61493456789

or

destination = 61492345678destination = 61493456789

Mandatoryexcept formessagescontaining atemplateparameter, inwhich case thedestination fieldmust not bepresent.

1 – 15 digits

May be included 1 ormore times in themessage.

Max destinations=300

udh Contains the UserData Header(hexadecimalencoding)corresponding todata contained inthe data parameter

Optional.

If udh is present,then it overridesthe value ofcontentType

Not applicable tomessages containing atemplate parameter.

username Username for thecustomer.

username=acme Optional. Username values arecase-sensitive. Thiscould be the first line ofthe email.

If it is present, it is used





Notes

to authenticate the user;if it is not present, findout a user with thematching email addressthe same as the 'from'address of the incomingemail; if no user is found with a matching'from' address, then thedomain of the fromaddress is used todetermine the customerand its primary user.

userDef1,userDef2,userDef3,userDef4,userDef_5,

These are five “userdefined fields” whichcan be used by theclient to recordinformationregarding themessage (e.g. costcentres), which canbe used for laterreporting.

userDef1=IKL-1 Optional.

valid The validity period ofthe message, afterwhich time themessage willexpire.

valid=120 Optional:valid=10080 (7days)

Relative validity (frommessage submissiontime) in minutes(positive integer greaterthan 0).

costCentre User cost centrelabel.

costCentre=CALLCENTER Optional:costCentre=REPAIR_DEPT

Maximum 100characters.

clientMessageId

User messagereference which willbe sent back withreply messages.

clientMessageId=A1B2C3 Optional:clientMessageId=ABC0123

Maximum 100characters.

responseTo The email addressto which responseemail (when ack=1)is sent back.

[email protected] Optional This value is only usedwhen ack=1.

Simple Email API Parameters'Simple' SMS does not require any mandatory parameters in order to function.

The email body text will be treated as the SMS message, carriage return characters will be translated as new line inthe SMS message. Destination address is used as the name of part of the recipient’s email address. Up to 300recipient addresses can be included on your email.

If no 'Registered' parameter is included, the API will use the setting defined in Company SMS Preferences (orCompany MMS Preferences, if used).







Advanced Messaging TechniquesAdvanced messaging techniques vary depending on whether you are using:Standard Email-to-SMSSimple Email-to-SMS

Advanced Standard Email APIAdvanced messaging techniques for 'Standard' Email-to-SMS:

Text messaging – use of 'text' and 'data' fieldsConcatenationBatch messagingBinary ContentReceiving an MO Message by EMAIL

Text Messaging – Use of 'text' and 'data' FieldsSMS text messages can be sent using the 'text' or 'data' fields. Use of multiple 'text' fields will result in line breaksbetween these in the resulting SMS; use of multiple 'data' fields will not.

ConcatenationNormally, long messages (over 160 characters or 140 bytes) will be automatically split across multiple (concatenated)SMS messages. The exception is where a message includes a 'udh' parameter.

For text messages, concatenation reduces the number of characters in each message by 5.

Batch Messaging'Batch messaging' allows a series of personalised SMS messages to be sent out using one email.

The following provides an example:[email protected] FROM: [email protected]: Batch message example

Email Body:

username=acme

password=Acmepwd

template= Hi {1}, your appointment is at {2} tomorrow

delimiter=,

content=61491234567,George,3.00pm

content=61491234568,Fred,3.30pm

This will send out 2 personalised SMS messages to George and Fred, nominating their appointment times.

Binary ContentThere are two options when sending binary data:

Use the 'contentType' parameter (with a value of 2, 3, 4, 5 or 8) and the “data” parameter. CGP will generate anappropriate UDH based on the specified contentType and length of the data submitted; or Use the 'udh' parameter and the 'data' parameter.

Note: If binary content is being managed using the 'udh' parameter the 'data' parameter value should be < 140 bytes so themessage can be delivered as a single SMS. Concatenation is expected to be handled by the Customer through thesubmission of multiple messages each with an appropriate UDH.




Receiving an MO Message by EMAILSMS messages originating on a mobile device can be delivered to a customer via the Telstra Integrated Messagingpowered by Soprano platform using the SMTP interface, provided they have selected this option in the configuration oftheir Telstra Integrated Messaging powered by Soprano platform subscription.

In this instance, the email is sent by the Telstra Integrated Messaging powered by Soprano platform. Any responseshould be returned by the customer.

Email HeadersTo enable a customer to apply rules-based routing to their incoming email, X-Headers are added to the messagecontaining data that can be parsed easily by machines.

X-Headers provided include:

X-MEMS-SOURCE - the mobile number from which the message originated;X-MEMS-DESTINATION - the destination mobile number, the number targeted by the originating mobile subscriber;X-MEMS-CLIENTMESSAGEID - the order ID which can be associated with either the broadcast;X-MEMS-TEXT - the message content itself.

If a carriage return is provided in the messsage body the X-MEMS-TEXT header willhave carriage returns replaced by HTML tags.

Message Body:

Test line 1Test line 2Test line 3Test line 4

Is presented in header as:

X-MEMS-TEXT: Test line 1 Test line 2 Test line 3 Test line 4

Note: if the inbound message is longer than 160 characters, the customer will receive 2 emails.

Email FormatFormat of the email received by the customer can be provided in Plain-Text or as a branded HTML email. The choiceon how to deliver the messages is provisioned at the customer/company level from the web interface.

Email Format Configuration Navigation:




To enable 'Email-to-SMS' the customer needs to provision their organisation's email preferences.

Setup > Company Setup > Email API Preferences > MO Template

Options:If 'Use Plain Text Email' is selected, then the email will be delivered as plain-text.If HTML is selected, then the email will be delivered as HTML based on a Telstra Integrated Messaging powered bySoprano platform email template. The use can choose "custom" to amend the template to their own requirement.

Example: Plain Text Email:




If a carriage return is provided in the messsage body the X-MEMS-TEXT header willhave carriage returns replaced by HTML tags.

Message Body:

Test line 1Test line 2Test line 3Test line 4

Is presented in header as:

X-MEMS-TEXT: Test line 1 Test line 2 Test line 3 Test line 4Example: HTML Email:




HTML Mail Example:

Header:

Delivered-To: [email protected]

………

Date: Tue, 18 Aug 2009 17:16:14 -0700 (PDT)

Message-ID: …

From: 61491234567 <[email protected]>

To: [email protected]

Subject: Response from 61491234567

Mime-Version: 1.0

Content-Type: text/html; charset=UTF-8

Content-Transfer-Encoding: 7bit

X-MEMS-SOURCE: 61491234567

X-MEMS-DESTINATION: 61491234567

X-MEMS-CLIENTMESSAGEID: 16105

X-MEMS-TEXT: Response message

....




Example of a component of the HTML Body is:

....Dear %FIRST_NAME% of %CUSTOMER_BNAME% 

 



The following message was received from Mobile Number = 61491234567.



 

Response message

 

Customer Reference = 16105 

 

Kind Regards, 

 

The Soprano Team 

Advanced Simple Email-to-SMS'Simple' Email-to-SMS method can process both plain and HTML emails.

Note: Attachments are not supported.

Advanced Messaging Techniques for Simple 'Email to SMS':Concatenation

ConcatenationNormally, long messages (over 160 characters or 140 bytes) will automatically be split across multiple (concatenated)SMS messages.

For text messages, concatenation reduces the number of characters in each message by 5.

Supported Email TypesRegarding the text inside email body, TIM SMTP API supports:

text/plaintext/html

Regarding how the email message is formatted, TIM SMTP API supports:TEXT emailHTML emailTEXT and HTML email

TIM SMTP API even supports multi-part within multi-part, where the deepest level contains the actual text or text/HTML.




TroubleshootingQ: Is your message longer than 1400 Characters (2000 Characters Base 64 Encoded)?

A: Some enterprise outbound mail servers add disclaimers onto a message. This takes the message over the sizethreshold limit.

Messages containing more than 1400 characters will be truncated, and a warning message displayed, stating:

'The rest of this message was truncated as it exceeded max size of 1400 characters'.




AppendicesAppendix A - TIM API Capabilities & FunctionsAppendix B - AbbreviationsAppendix C - Response DetailsAppendix D - 'dcs' Parameter - DetailAppendix E - Example CodeAppendix F - ServiceNow IntegrationAppendix G - Handset Profile Setup for MMS

Appendix A - API CapabilitiesThe following table provides an overview of common API capabilities supported on Telstra Integrated Messagingpowered by Soprano.

HTTP WSDL SMPP SMTP

(Simple)

SMTP

(Standard)

OMS MM7 SMAP WCTP Java API .NET

Send SMS

Send MMS

Receive Inbound SMS

Receive Inbound MMS

Scheduled Delivery

Registered Delivery

Define Validity Period

Reply Control & Management

Source Address Control

Send to Multiple Recipients

Query Message Status

Cancel Message

Replace Message

Limit Content to Single SMS

Mobile Barcode

Binary Message (Ringtone)

vCard / vCalendar Messages

WAP Push (SI/SL) Messages




One Time Passw ord*

Secure Connection HTTPS

Secure Tunnel (OpenSSL)

Username and Passw ord Auth.

Basic

Username and Passw ord Auth.

Parameters

User List Based Authentication

Passcode Authentication

Source Domain IP Auth.

* One time password for the HTTP interface requires Authenticator HTTP API.

Please note that all mobile numbers must be entered in international format whenusing the APIs & interfaces.




API FunctionsFunction DescriptionSend SMS The protocol/API call provides the ability to send an SMS (Mobile Terminated Short

Message) to one or more destinations.

Send MMS The protocol/API call provides the ability to send an MMS (Mobile TerminatedMultimedia Message) to one or more destinations.

Receive Inbound SMS The protocol/API provides the ability to receive SMS (Mobile Originated ShortMessages) originating from a mobile device and deliver to a customer system inreal-time, or batched, using different time intervals (monthly, weekly, daily, hourly, 5minutes).

Scheduled Delivery The protocol/API provides the ability to schedule a Mobile Terminated shortmessage for delivery at a time specified in the future.

Messages can be triggered to be sent at a later scheduled time using a relativevalue from when the request was submitted (e.g. 2 hours from now).

Registered Delivery The protocol/API provides the ability to request a notification when the networkdelivers a message to the mobile device.

A registered flag can be set on a message, prompting the mobile network to returnback a delivery receipt once the message is delivered to the device. Deliveryreceipts are delivered the same way as an Inbound messages.

Delivery Receipts (or 'Delivery Reports') may not be fully supported acrossinterconnect (such as delivering a message from GSM to CDMA networks or whendelivering internationally).

Define Validity Period The protocol/API provides the ability to set the length of time the message mayreside in the mobile network SMSC without delivery (when a mobile handset isswitched off or unavailable).

Setting an expiry time for each message (e.g. 1 day or 8 hours) enables messagesto expire when not delivered within a desired period. This is useful for situationswhere the message is no longer relevant if not delivered within the defined validityperiod.

Reply Control & Management The protocol/API provides the ability to control where replies (Mobile Originated/Delivery Receipts or Reports) are to sent to in our system. This may be defined asa web URL, email address, another mobile, or the platform database for reportingpurposes only.

While a default reply path exists within TIM, this can be overwritten using the API.

Source Address Control The protocol/API provides the ability to define the 'From' address that will appear onthe receiving mobile phone. This may be a Short Code / Vanity Short Code, LongCode (standard international mobile number) or an Alpha Address (up to 11characters).

TIM will automatically allocate a short code to the message if no source address isassigned to the message. If you have multiple short codes you have the ability tonominate which short code to use for each message.

Note: The available source addresses may be limited to one or more which havebeen provisioned for the root customer specifically.




Some countries do not support the sending of messages with alphanumericaddresses.

There are also some constraints when setting the source address which will disableautomatic reply management in the platform.

Transaction ID The protocol/API provides the ability to automatically manage sessions forcustomers.

To track responses to internal transactions, customers can assign an ID to eachmessage sent, so TIM can provide the ID in the response received and forwarded tothe nominated or default reply address.

Send to Multiple Recipients The protocol/API provides the ability to send to multiple recipients in a singlerequest/API call.

Query Message Status The protocol/API provides the ability to query the status of a message for finalstatus updates (SMSC response or receipt update), using the message ID that youreceive from the platform after sending.

Cancel Message The protocol/API provides the ability to cancel a message that has been scheduledor queued for future delivery, and has not been delivered to a mobile device that isswitched off or unavailable.

Replace Message The protocol/API provides the ability to override and replace the content of a message that you have previously sent.

Note: Not all carriers support this function.

Limit Content to Single SMS Protocol/API preferences in the platform allow SMS messages to be truncated to amaximum of 160 characters (1 SMS), which prevents long messages from beinggenerated.

This is applicable to SMTP (Email2SMS API, where an enterprise mail server mayappend a footer to the email that is received by the platform).

Long Concatenated Messages The protocol/API supports long messages (up to 1400 characters).

Mobile Barcode Not currently supported.

Binary Message (Ringtone) Not currently supported.

vCard / vCalendar Messages Not currently supported.

WAP Push (Si/SL) Messages The protocol/API provides the ability to send a WAP push (SI - Service Indicator orSL - Service Loading) over SMS. These messages are limited to 140 octets andmay not be supported by all networks, or the current smart phone range.

One-Time Password The API (code) provides the ability to call a function that will generate a one-timepassword, which can be used in the transmission of the SMS (one-time passwordis then stored in a variable for your code to utilise upon challenging).

Secure Connection HTTPS The transport layer of communication with the platform is secured over an SSLsocket, utilising HTTPS.

Secure Tunnel (OpenSSL) The platform provides the ability to utilise Open SSL to set up a 'soft' VPN-typeconnection, to secure communications protocols not already using SSL orequivalent.




Username & Password Auth.Basic

The platform supports validation of API access using a username and passwordencoded with Basic Authentication method and transmitted in the HTTP header.

Username & Password Auth.Parameters

The platform supports validation of API access using username and passwordparameters transmitted in the GET / POST parameters.

User List Based Auth. The platform supports validation of API access by looking up a whitelist of allowedsenders (the sender does not have to be a platform user).

Passcode Auth. The platform supports validation of API access by checking a passcode in an emailsubject line. This means that the sender of the message does not have to be aplatform user, and is typically used in conjunction with 'User List Based Auth.'.

Secure Domain IP Auth. The platform has the ability to lock down API access to a limited set of IPaddresses. IP address checking can be controlled in the Email API Preferences forSMTP. All supported protocols require configuration by the provisioning team.

Appendix B – AbbreviationsAPI Application Programming Interface – a programmatic interface which enables an application to use the

facilities of TIM.

CGP Corporate Gateway Platform – underlying technology of TIM – mobile messaging infrastructure whichenables the sending and receipt of mobile messages.

HTTP Hypertext transfer protocol – an internet standard for transporting information to/from a web server.

Inbound Inbound messages – messages sent from a handset (i.e. 'MO' messages) arriving at TIM from thetelecommunications network, to be forwarded to a TIM customer.

MMS Multimedia messaging service – a mobile messaging service which enables the sending and receipt ofmulti-part multi-media messages (text, picture, video, audio etc).

MO 'Mobile Originating' – inbound messages sent from a handset – to be routed to a TIM customer by TIM.

MT 'Mobile terminated' – outbound messages sent by an application through TIM to reach a particularhandset.

Outbound Outbound messages are messages sent by the TIM (on instruction from a customer) out through thetelecommunications network to mobile handsets.

SMS Short Message Service – a mobile messaging service enabling the sending of short text and datamessages.

SMTP Simple Mail Transfer Protocol – a standard API used for email.

UDH UDH stands for User Data Header and is specialised information that is normally posted with 8-bitmessages. The UDH contains information on the message type, the length of a message,concatenation and more. The UDH is specific to each manufacturer.

XML Extensible Markup Language – a flexible standard for formatting information exchanged betweenapplications.




Appendix C – Response DetailsIf a customer specifies the 'ack' parameter in their email, they will be sent an email response by TIM once themessage has been accepted.

An example of such as a response message is as follows :FROM: [email protected]: Response

Email Body:

0 001 OK

Message-ID: 1714001

The body of all responses to message submission requests that were received successfully by TIM will contain a onedigit success code (0 = success or 1 = error), a three digit response code and a response string which are defined inTable 1 as well as an identifier for the message.

For batch messages, a message status will be returned for each destination in the request. It could be possible forone destination to fail and others to succeed, as shown below: FROM: [email protected]: Response

Email Body:

2 017 ERROR – content

4473123456A8 101

0 001 OK

Message-ID: 1714002

61491234567 001

If the request could not be interpreted by the CGP (due to for example an unrecognised format or the request lackingmandatory parameters), the response will contain a success code of 2 (indicating an error with the command), aresponse code and a response string (refer to Table 1) identifying the error:

Example of an invalid email to cause such error and response from CGP are as follows:TO: [email protected] FROM: [email protected]: Invalid parameter value example

Email Body:

username=acme

password=Acmepwd

text=hello

ack=1

contentType=111

Response from TIMFROM: [email protected]: Response

Email Body:




2 001 ERROR - command not recognised

Note that the response contains text intended for use in automated applications.

Table 1 shows the responses that could be returned from the CGP as part of the response to an SMTP request.

Table 1 - Response details

SuccessCode

ResponseCode

Response String Explanation

0 001 OK command completed successfully

2 001 ERROR – command notrecognised

command not recognised, command containsunknown or missing mandatory parameter(s),contains repeated parameters, etc.Note that no identifier will be returned if this erroroccurs.

2 005 ERROR – sourceNPI value Invalid parameter value - sourceNPI

2 021 ERROR – destinationNPI value Invalid parameter value - destinationNPI

2 006 ERROR – onNet value Invalid parameter value – onNet

2 007 ERROR – ack value Invalid parameter value - ack

2 008 ERROR – dcs value Invalid parameter value - dcs

2 009 ERROR – contentType value Invalid parameter value – contentType

2 022 ERROR – 8-bit binary dcs valueexpected

dcs value does not match contentType value. Refer toTable 2 and

Table 3.

2 023 ERROR – 8-bit binary dcs valuenot expected

dcs value does not match contentType value. Refer toTable 2 and

Table 3.

2 028 ERROR – dcs value (notsupported)

dcs value is not supported

2 029 ERROR – udh parameter notexpected

Combination of separate and integrated udh notsupported

2 030 ERROR – text parameter notexpected

dcs value does not match with text parameter (dataparameter expected)

2 013 ERROR – destination value Invalid parameter value - destination

2 014 ERROR – source value Invalid parameter value - source

2 015 ERROR – delay value Invalid parameter value - delay

2 016 ERROR – valid value Invalid parameter value - valid

2 017 ERROR - content Invalid parameter value - content

2 018 ERROR - priority Invalid parameter value - priority




SuccessCode

ResponseCode

Response String Explanation

2 019 ERROR – sourceTON value Invalid parameter value - sourceTON

2 020 ERROR – destinationTON value Invalid parameter value - destinationTON

2 025 ERROR – udh value (invalidhexadecimal string)

Invalid parameter value – udh. Invalid hexadecimalformat.

2 027 ERROR – data value (invalidhexadecimal string)

Invalid parameter value – data. Invalid hexadecimalformat.

2 031 ERROR – messageClass value Invalid parameter value – messageClass

2 032 ERROR – delimiter value Invalid parameter value – delimiter

2 033 ERROR – replyTo value Invalid parameter value - replyTo

2 034 ERROR – replyToTON value Invalid parameter value - replyToTON

2 035 ERROR – responseTo value Invalid parameter value - responseTo

1 020 ERROR – storing batchparameters

1 030 ERROR – communication withSOPRANO CGP failed

SOPRANO CGP offline.†

1 031 ERROR – internal CGP failure Error within the CGP occurred†

1 040 ERROR 1:n {destination +status}

Error occurred with a destination. Response stringincludes a list of all destinations with their status.

† Some messages could have been successfully sent before the SOPRANO CGP went offline or encountered anerror. Therefore, it is recommended to query the identifier to determine which (if any) messages were received. Thecommand parameters can then be adjusted accordingly before resubmitting the command.

Appendix D – 'dcs' Parameter – DetailThe 'dcs' parameter is an optional parameter within the interface however it is required when sending a message to anSMSC. Therefore, it is the TIM responsibility to determine a value for the 'dcs' parameter when it has not beenincluded in a request. The 'dcs' value is dependent on the value of the contentType parameter, and this is used (asdescribed below) to set an appropriate value for the 'dcs' parameter (rather than applying a default value for allmessages).

If the 'dcs' parameter is not included AND the 'contentType' parameter is set to 2, 3, 4, 5 or 8, the TIM will set the'dcs' value to 8-bit binary when submitting the message to the SMSC.If the 'dcs' parameter is not included AND the 'contentType' parameter is set to 1, 6 or 7, the TIM should set the'dcs' value to SMSC default alphabet when submitting the message to the SMSC.If the 'dcs' parameter is included but is not set to 8-bit binary AND the 'contentType' parameter is set to 2, 3, 4, 5 or8, an error will be returned.If the 'dcs' parameter is included and set to 8-bit binary AND the 'contentType' parameter is set to 6 or 7, an errorwill be returned.

Table 1 and Table 2 below explicitly define the behaviour of TIM when both the 'dcs' and 'contentType' parameters areincluded in a message for both the 'text' and 'data' parameters respectively.

Table 1 Telstra Integrated Messaging powered by Soprano Behaviour when 'dcs', 'contentType' and 'text' parameters areincluded in an EMAIL message.




contentType

1 2 3 4 5 6 7 8

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

dcs

0 B C B C B C B C C C E F

1 I I I I I I I I I I I I I I I I

2 H H H H H H H H H H H H H H H H


4 A A B C B C B C B C D C D C E F




8 B C B C B C B C C C E F

Legend:

message accepted

A Invalid: 8-bit data is not text(reject message and return error 2 030)

B Invalid: pictures and tones are not text(reject message and return error 2 030)

C Combination of user-supplied and TIM-generated udh not supported in TIM 4.0(reject message and return error 2 029)

D Invalid: vCards/ vCalendars are text(reject message and return error 2 023)

E Invalid: data including udh is not text(reject message and return error 2 030)

F Combination of separate and integrated udh not supported in TIM 4.0(reject message and return error 2 029)

H Set dcs value to 4 (refer to the behaviour for 4)

I dcs value not supported by TIM 4.0(reject message and return error 2 028)

Table 2TIM Behaviour when 'dcs', 'contentType' and 'data' parameters are included in an EMAIL message




contentType

1 2 3 4 5 6 7 8

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

udhabsent

udhpresent

dcs

0 G C G C G C G C C C F


2 H H H H H H H H H H H H H H H H


4 C C C C D C D C F




8 G C G C G C G C C C F

Legend:

message accepted

C Combination of user-supplied and TIM-generated udh not supported in TIM 4.0(reject message and return error 2 029)

D Invalid: vCards/ vCalendars are text (reject message and return error 2 023)

F Combination of separate and integrated udh not supported in TIM 4.0(reject message and return error 2 029)

G Invalid: pictures & tones are 8-bit data(reject message and return error 2 022)

H Set dcs value to 4 (refer to the behaviour for 4)

I dcs value not supported by the TIM 4.0(reject message and return error 2 028)

Appendix E - Example Codeperl - SMTP API Test ScriptReplace

%hostname% with the service address i.e. tim.telstra.com.%your email address% with the email address that you are authenticating against,%your mobile number% with your mobile number in international format

#!/usr/local/bin/perl -w

use Net::SMTP;




Define the variables of your test case

Script tests Email to SMS API where with Email API Preference set up to convert the message body to the textwithin the SMS.

If you are testing multiple Email2SMS API configurations you may want to build a has of the configuration

Service 1 is used for Simple Email API Testing$mymailhost{1}="%hostname%";$myto{1} = "%your mobile number%@sms.%hostname%";$myfrom{1} = "%your email address%"; #make sure you use the escape on the @ sign ie @ in your email address$bodymsg{1} = "Hello World";

Service 2 is used for Standard Email API Testing$mymailhost{2}="%hostname%";$myto{2} = "sms@%hostname%";$myfrom{2} = "%your email address%"; #make sure you use the escape on the @ sign ie @ in your email address$bodymsg{2} = "destination=%your mobile number%\ntext=Hello World\nreplyTo=%your email addres%\nreplyToTON=8"; #make sure you use the escape on the @ sign ie @ in your email address

$service=1; # Set as 1 for Simple 2 for Standard

Execute the sending of the Email to be converted into SMS

$smtp = Net::SMTP->new($mymailhost{$service});

$smtp->mail($myfrom{$service});$smtp->to($myto{$service});

$smtp->data();$smtp->datasend("To: <" . $myto{$service} . ">\n");$smtp->datasend("Subject: Test Subject\n\n");$smtp->datasend($bodymsg{$service});

$smtp->dataend();$smtp->quit;

Appendix F - ServiceNow IntegrationThe following instructions will enable you to integrate TIM with ServiceNow to send SMS via Email2SMS.

Please visit http://wiki.servicenow.com/index.php?title=Notifications#Email_Notifications for more information aboutServiceNow setup.

TIM Setup:

Step 1Create a new user in the customer account:

http://wiki.servicenow.com/index.php?title=Notifications#Email_Notifications




Click the 'Users' link in 'Company Setup > Manage Users' to open the 'UserSummary' screen.

Click button in title bar to open the 'New User' screen.

Complete the 'Email' field to match the following form:{Customer name}@service-now.com.

e.g. [email protected]

This is the originating email address that will be used for sending emails from within the ServiceNow environment.

Step 2Request configuration of Email2SMS connection for the username you have created ({Customer name}@service-now.com) from Provisioning team.




Step 3Log into TIM with '{Customer name}@service-now.com' account.

Go to: Company Setup > Customer Information > Email API Preference

a) Tick the 'Always Check UserName' box.

b) Click .

ServiceNow Setup:

Step 4You will be required to set up email notifications that are triggered when certain events occur. Configure your SMTPand POP server settings in the 'Email Properties' and ensure that the 'From' email address is set to:

'{Customer name}@service-now.com' (i.e. the username you set up in 'Step 1').

Step 5Create Events and Business Rules




Step 6Create email notifications for your users.

Create new records or edit an existing notification if the default functionality does not suit your business needs.

Edit the notification message either in the notification record or in the Email Template used by the notification.

If you are using 'Standard' Email2SMS, ensure that the 'Message' field of your Email Template corresponds with thefollowing 'Standard' Email2SMS template:

[email protected]

password=********

text=${short_description}

destination=${mobile_number}

replyToTON=8

[email protected]

Where the variables ${short_description} and ${mobile_number} would refer to a short description of the ticketand the mobile number of the intended recipient. Setting the 'replyTo' fields enables SMS replies to be forwarded to'{Customer name}@service-now.com' address.

Appendix G - Handset Profile Setup for MMSOverviewCreate a handset profile to determine how messages will be rendered on a particular phone model.

Click the 'Handset Profile' link in 'Company Setup > Handset Profile' to open the 'HandsetProfile Summary' screen.

Click button in the title bar to create a new Handset Profile (this page will beautomatically displayed if there are no existing Handset Profiles).

Description




Handset Profile Details

Model The name that you wish to associate with the handset profile (note: this should be the same whichyou reference in the Subscriber Profile Lists set up in the 'Subscriber' settings).

Width The number of pixels in the horizontal direction that a handset MMS client can support.

Duration The running time of an MMS slideshow.

Height The number of pixels in the vertical direction that a handset MMS client can support.

URL Navigation Provides flexibility to customise the call-to-action text within the MMS message appropriate to thehandset.

This text will replace the '$URLnavigation' variable if used in MMS messages tailored for this type ofhandset. e.g. 'Find out more, simply scroll down and press Go To URL'

Store changes and exit

Undo any changes and exit.

Example of what you may enter with respect to screen resolution:Model - DefaultWidth - 128Height - 160Duration - 15

Documents

SMTP Interface Developer Guide - Telstra · CONFIDENTIAL INFORMATION: Do not disclose SMTP Interface Developer Guide SMTP Interface Developer Guide v7.8.1 © 2015 Soprano Design Pty