Outgoing Messages

The Outgoing Messages tab allows you to set rules for outgoing messages. This functionality lets you perform vast spectrum of filtering, routing, load-balancing, archiving, etc.

Figure. Outgoing Messages tab.

Field	Description
Rule Title	This field lists titles of the existing content filters for outgoing messages. Only filters with the left-hand checkboxes checked are applied.
Add	Click this button to set a new content filter. The Rule dialog appears. For more details refer to the Mail Service - Content Filters - Filter Conditions and Filter Actions chapters. Note: Some options designed for SMTP service content filters are not available for SMS service because they are not meaningful here.
Edit	Click this button to edit the selected rule. The Rule dialog appears. For more details refer to the Mail Service - Content Filters Filter Conditions and Filter Actions chapters. Note: Some options designed for SMTP service content filters are not available for SMS service because they are not meaningful here.
Copy	Click this button to copy the selected content filter.
Delete	Click this button to delete the selected content filter.
Up/Down arrows	Click one of these buttons to move the selected filter up/down in the list. Content filters will be applied in the order from the top down.
Export	Click the button to export one or more content filters. In the Export dialog, select Filters that you want to export and click the Export Selected Filters Now button. In the standard Save As dialog select the directory to save these filters to.
Import	Click the button to import one or more content filters. In the standard Open dialog, navigate to the directory with the xml file that contains desired content filters. In the Import dialog, select Filters that you want to import and click the Import Selected Filters Now button. Imported content filters will appear in the list.

Applications

Outgoing Messages use the standard content filters system which gives you an infinite number of options, including but not limited to the following scenarios.

Warning: A destination SMS number comes to a content filter in the following form: [number][@GateWayID]. It means, the number is always there and the part with @ (at) sign is there only, when a user has set a specific SMS gateway in user settings (Domains and Accounts - Management - <domain> - <user> - Policies - SMS Settings - Gateway). As a consequence, when an administrator wants to redirect some messages to a specific gateway using outgoing rule, he/she has to consider the To: header in the form number and number@userGateway.
When ANY outgoing rule condition is met, the server expects, that specific SMS gateway is defined by sender's_domain. Even if the To: header is not modified by the rule. When none of filters conditions is met, the server will ignore the @sender_domain part and will use some gateway which the server prefers. This could lead to unexpected behavior when a user creates a rule which for example checks SMS content but server expects it also specifies a gateway.

Load-balancing

A gateway can be load-balanced with another gateway or external modem, and routing preferences configured using SMS Service - Outgoing Messages content filters. Gateways have their IDs that you can use to send SMS through a specific ID (id= parameter) or load-balanced automatically to any available gateway if not specified.

The message To: header contains the destination number + "@" and the ID of the destination gateway ID. If a gateway is not specified, the 2nd part with "@" is missing - you can use the Edit Message Header function to rewrite and specify the gateway ID. RegEx replace is recommended for this purpose.

You can check if the outgoing SMS is already going through a specific gateway and if not, based on the number prefix route it to a specific gateway (using the Edit Message Headers and the new RegEx Rewrite).

Note: If you have created a rule that assigns some message(s) only to one specific gateway and its delivery fails, the message stays in the queue as the server always tries to send through this gateway.

Sent SMS Archiving

To store all SMS sent through the server, create a rule forwarding the content of SMS to an email address of a dedicated SMS archive mailbox. Use Edit Message Headers to record additional information about the sender and recipient.

Filtering the content of SMS

Also any content filter actions are supported, you can forward SMS to email addresses based on content filters criteria and any other scenario, you can even use the Forward To action to send an email back to the SMS gateway if required. To check whether @ is present, use the (.?[\d]*)(?!@) expression.

Least Cost Routing

You can check if the outgoing SMS is already going through a specific gateway and if not, based on the number prefix, route it to a specific gateway (using the Edit Message Headers and the new RegEx Rewrite).

Warning:RegEx rewrite is a very strong tool that lets you define a RegEx search pattern and, based on the pattern, it can create a rewritten result using parts of the original RegEx pattern. If the RegEx condition does not match, the Edit Message Header action is simply skipped. This provides great flexibility for custom content filters, especially with rewriting parts of a telephone numbers (prefixes or suffixes) in SMS and SIP gateways.

Text message To: header contains the destination number + "@" + domain name or ID of the destination gateway. If the message is routed to email or to specific gateway, further routing cannot take place and you need to use the Stop processing more rules action. To check whether the message is already routed to email or specific gateway, look for presence of "@" using the following RegEx:

^(?!.*@)(.*)$

If gateway is not specified and the 2nd part with "@" is missing, you can safely use the Edit Message Header action to rewrite and specify the gateway ID, using RegEx Rewrite:

Add/Edit

Header: To:

Regex: False

Value: %%To%%@gatewayid

Add/Edit

Header: To:

Regex: True "^(?!.*@)(.*)$"

Value: $1@gatewayid

This action checks the presence of number@domain and then creates number@gatewayid. Substitute gatewayid for ID of the gateway where you want the text message to be routed to.

Typically you may want to route the message to a specific gateway based on the number format:

Add/Edit

Header: To:

Regex: True "^(\+1)(.*)"

Value: $1$2@usgatewayid

This action checks the number prefix and, if it begins with +1, routes the message to usgatewayid. Substitute gatewayid for ID of gateway where you want the text message to be routed to.

Warning:The syntax of regular expressions requires you to escape the special character "+" with a backslash to acquire its literal meaning.

Validating the sender

You can check the number of incoming message against a RegEx condition or a list of valid senders.

Each gateway is using the From: option defined in SMS Service - General tab - gateway properties. What you define here will appear as the From: header of the incoming message. You only need to create a content filter in Incoming Messages tab, which will validate the sender against a RegEx pattern or whether it Contains a list from a file or pattern:

If From RegEx: "(\+15551234567)|(\+15551238866)" (if the sender number is from the list) than for example:
Forward To: john.doe@icewarp.com

This will route the message from one of those foreign numbers to the appropriate recipient.

Rewriting the Caller ID

You can rewrite the sender's Caller ID so that the message will appear to recipient as sent from a number you specify.

It must be supported by the wireless carrier (GSM or HTTP service provider). If not available, the number associated with the SIM card or SMS account will be used.

You can use the phone number global variable as found in Management - [user] - General - Phone # field and then create action which adds the &sender=%sender_phonealias% parameter.

Add/Edit

Header: To:

Regex: True "^(.*.@)(.*)$"

Value: $1@$2&sender=%sender_phonealias%

Again, first you need to verify whether the message is not already routed to email - see Least Cost Routing.

Non-Delivery Reports

Thanks to integration with Mail Server, IceWarp SMS Server is using a bounce-back system for text messages sent via email or WebClient which works exactly the same as SMTP NDR:

A warning is sent by e-mail if the text message is still not delivered after some time (SMTP - Delivery - Warning option).
If the message cannot be delivered and expires (SMS API setting), sender will receive the final NDR on message delivery failure.

To override the default global message expiration (7200 minutes, i.e. 5 days), use the command line in root of IceWarp Server installation:

tool modify system C_SMSService_ExpireMins

The original text is always included. This applies only if the real sender is known (sent from WebClient, email or specified in the SMS API).