Receiving messages - Nordic Messaging

The messaging protocols, including the proprietary MGP, all include functionality to send and receive messages.

Using an SMPP connector

An SMPP connector normally supports bi-directional message flow. This means that a SMPP connector can both send and receive messages regardless if it is an incoming or outgoing connector. The SMPP bind mode determines whether connector can send only, receive only or send and receive.

Using an HTTP connector

Sending a message from a HTTP client to the incoming HTTP connector involves issuing a GET or POST request with the proper message options as arguments. The document part of the request must be /bin/send. Sample URL for sending an SMS with the text “Hello world”:

http://localhost/bin/send?SOURCEADDR=123456&DESTADDR=876543&MESSAGE=Hello+world

If successful, the message id is returned in the body of the HTTP response. If multiple DESTADDR are supplied in the same request multiple message ids will be returned in the same order as the DESTADDR options were supplied.

EMG supports persistent HTTP/1.1 connections.

When sending binary messages or UDH the message data must be hex encoded.

The DESTADDR parameter can occur multiple times in one request and therefore it is possible to perform batch sending with very high throughput (more than 5.000 messages per second).

The ROUTE and ROUTEDLR options all need the ALLOWROUTE keyword to be set on the connector in order to prevent users from setting these options by default.

There is no limitation in EMG on the size of an incoming HTTP POST request.

Using UTF-8

Starting with EMG 7.1 you can set connector keyword DEFAULT_CHARCODE_TEXT to specify that UTF-8 is the default character set for an incoming connector.

CONNECTOR http-in1 <
...
DEFAULT_CHARCODE_TEXT=UTF8
>

JSON and XML responses

Starting with EMG 7.1 you can get responses in JSON and XML format by using the uri:s “/bin/send.json” and “/bin/send.xml” respectively.

Sample JSON response:

{
 "results": [
  {
   "status": "0",
   "msgid": "25629515",
   "statustext": "OK"
  }
 ],
 "balance": "956489.1699"
}

Sample XML response:

<response>
 <results>
  <result>
   <status>0</status>
   <msgid>25629516</msgid>
   <statustext>OK</statustext>
  </result>
 </results>
 <balance>956489.1399</balance>
</response>

Using an SMTP connector

When receiving a message via an incoming SMTP connector EMG will (by default) parse incoming message data (RFC 822 or MIME messages), discard all present non-text attachments and convert message data to the GSM character set.

This is the default behavior if connector is missing DEFAULT_MSGTYPE or it is set to NORMAL. If DEFAULT_MSGTYPE=EMAIL is used the e-mail message will be parsed but message content will remain intact. This should be used when e-mail messages should pass transparently through EMG.

A few message options will be set from SMTP provided information:

SOURCEADDR	Retrieved from MAIL FROM address.
DESTADDR	Retrieved from RCPT TO address.
MESSAGE	Retrieved from the DATA message body.

EMG will also look for user-defined headers on the format “X-EMG-Option-<option>:”. If present, they will be used and override any equivalent information provided in the SMTP session.

There are also a few specific connector keywords used by the incoming SMTP connector:

USESUBJECT	This indicates that the Subject of the message should be included short message.
USESENDER	This indicates that the sender of the message should be included short message.
SEPARATOR	Specifies which separator should be used between sender, subject and message body. Default: ” ” (a single space)
USEPRIORITY	This indicates that the X-Priority message header, if present, will be used to set the priority of the short message

All message options can be used using the “X-EMG-Option-<option>:” user-defined headers. The UDH, if present in the message, will also be sent using a user-defined header with the UDH data hex encoded.

As many messages as possible will be sent in each SMTP session using the RSET command between the messages.

When sending binary messages or UDH the message data must be hex encoded.

Sample incoming SMTP session

Remote SMTP client lines begin with `>’.

220 <hostname> ESMTP
>HELO <client host>
250 Pleased to meet you
>MAIL FROM:<user@domain.com>
250 ok
>RCPT TO:<123456@domain.com250
ok
>DATA
354 Enter mail "." ends
>From: "User Smith" <user@domain.com>
>To: <123456@domain.com>
>Subject: Test SMS
>Date: Thu, 14 Feb 2002 17:36:00 +0100
>MIME-Version: 1.0
>Content-Type: text/plain
>  charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>X-Priority: 3
>
>Test
>.
250 Messaging accepted (id=7398)
>QUIT
221 Closing connection

Preventing SMTP relaying

By specifiying which IP addresses are local (and trusted) and what domains are handled locally EMG can be set up to reject unauthorized relaying.

Sample configuration:

CONNECTOR smtp-in1 <
TYPE=INCOMING
...
LOCALIPS=127.0.0.1/32
LOCALIPS=10.0.0.0/8
LOCALIPS=192.168.0.0/16
LOCALDOMAINS=example.com
>

The above would indicate that only clients connector from private networks would be able to send e-mail to other domains than example.com through EMG.

If a client connecting from another IP tries to send e-mail to a domain other than example.com, it would receive a “Relaying denied” error message in the SMTP session.

Receiving WAP push via PAP

EMG can act as a PPG (Push Proxy Gateway) and handle incoming WAP push messages issued via PAP (Push Application Protocol), a protocol based on XML over HTTP.

Sample configuration:

CONNECTOR pap <
TYPE=INCOMING
ADDRESS=127.0.0.1:8088
PROTOCOL=PAP
INSTANCES=5
ROUTE=smsc
REDIRECT=pap-dlr
>

CONNECTOR pap-dlr <
TYPE=OUTGOING
# Dummy address, real address will be in DLR
ADDRESS=http://localhost
PROTOCOL=PAP
INSTANCES=1
>

When a WAP push is received via PAP it will be compiled into binary form and for the outgoing SMS message the UDH parameters source port and destination port will be set. This allows for the WAP push to be delivered via SMS to the recipient transparently.

It is possible to request that a delivery confirmation should be delivered back to a specific URL. This is handled by the REDIRECT keyword and the pap-dlr connector so that any DLRs routed back to the pap connector will be redirected to the outgoing pap-dlr connector and since a URL will be specified in the PAP request that URL will be used instead of the address specified on the pap-dlr connector.