EMG 5.5.1 - User's Guide

Table of ContentsPreviousNextIndex

9. Receiving messages

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

9.1 Using 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":


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.

9.2 Using 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:

Retrieved from MAIL FROM address.
Retrieved from RCPT TO address.
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:

This indicates that the Subject of the message should be included short message.
This indicates that the sender of the message should be included short message.
Specifies which separator should be used between sender, subject and message body. Default: " " (a single space)
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-xxx:" 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.

9.2.1 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.com
250 ok
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
250 Messaging accepted (id=7398)
221 Closing connection

9.2.2 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 <

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.

9.3 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-dlr <
# Dummy address, real address will be in DLR

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.

Table of ContentsPreviousNextIndex