How to configure Mail Postfix with Dovecot on Linux

1. Requirement

Postfix, Qpopper, Mailx, Mailman, Apache2, PHP5, Dovecot

2. Configure Postfix

vim /etc/postfix/main.cf

mail_spool_directory = /var/mail

canonical_maps = hash:/etc/postfix/canonical

virtual_alias_maps = hash:/etc/postfix/virtual

virtual_alias_domains = hash:/etc/postfix/virtual

relocated_maps = hash:/etc/postfix/relocated

transport_maps = hash:/etc/postfix/transport

sender_canonical_maps = hash:/etc/postfix/sender_canonical

masquerade_exceptions = root

masquerade_classes = envelope_sender, header_sender, header_recipient

myhostname = linux.meanchey.com

program_directory = /usr/lib/postfix

inet_interfaces = 192.168.64.210

masquerade_domains = meanchey.com

mydestination = $myhostname, localhost.$mydomain, $mydomain

defer_transports =

mynetworks_style = subnet

disable_dns_lookups = no

relayhost = 192.168.64.210

mailbox_command =

mailbox_transport =

strict_8bitmime = no

disable_mime_output_conversion = no

smtpd_sender_restrictions = hash:/etc/postfix/access

smtpd_client_restrictions =

smtpd_helo_required = no

smtpd_helo_restrictions =

strict_rfc821_envelopes = no

smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination,permit_sasl_authenticated

smtp_sasl_auth_enable = no

smtpd_sasl_auth_enable = yes

smtpd_sasl_type = dovecot

smtpd_sasl_path = private/auth

smtpd_use_tls = no

smtp_use_tls = no

alias_maps = hash:/etc/aliases

mailbox_size_limit = 0

message_size_limit = 10240000

3. Configure Qpopper

vim /etc/xinitd.d/qpopper

#

# qpopper - pop3 mail daemon

#

service pop3

{

# disable = yes

socket_type = stream

protocol = tcp

wait = no

user = root

server = /usr/sbin/popper

server_args = -s

flags = IPv4

}

:x!

4. Configure Dovecot

# vim /etc/dovecot/dovecot.conf

auth default {

# Space separated list of wanted authentication mechanisms:

# plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi

# NOTE: See also disable_plaintext_auth setting.

mechanisms = plain login

----------------------------------

socket listen {

#master {

# Master socket provides access to userdb information. It's typically

# used to give Dovecot's local delivery agent access to userdb so it

# can find mailbox locations.

#path = /var/run/dovecot/auth-master

#mode = 0600

# Default user/group is the one who started dovecot-auth (root)

#user =

#group =

#}

client {

# The client socket is generally safe to export to everyone. Typical use

# is to export it to your SMTP server so it can do SMTP AUTH lookups

# using it.

path = /var/spool/postfix/private/auth

mode = 0660

user = postfix

group = postfix

}

}

=====================

After you should restart all services.

Read More

Unstructured Supplementary Services Data (USSD)

Unstructured Supplementary Services Data (USSD) allows for the transmission of information via a GSM network. Contrasting with SMS, it offers real time connection during a session. A USSD message can be upto 182 alphanumeric characters in length. Unstructured Supplementary Service Data allows interactive services between a MS and applications hosted by the Mobile Operator. These messages are composed of digits and the #, * keys, and allow users to easily and quickly get information/access services from the Operator.

USSD messages are simple to form and easy to send. User can directly enter the ussd string and press call to send the message. A typical USSD message starts with a * followed by digits which indicate an action to be performed or are parameters. Each group of numbers is separated by a *, and the message is terminated with a #. The USSD gateway in turn can interact with external applications based on the USSD command. This allows access to number of value added services via USSD.

USSD is a session oriented service, and can support a sequence of exchange of information. Phase 2 USSD also allows messages to be pushed onto a MS. It is several times faster than MO SMS messages since there is no store and forward of messages. The USSD gateway supports an open HTTP interface.

The USSD gateway will have an interface with the MSC over SS7. It uses MAP to receive and send USSD data from the HLR.

Generally the USSD functionality is implemented in the following modes:

• Pull Mode, will handle Mobile Initiated USSD Requests.

• Push Mode will handle network Initiated USSD Requests.

Characteristics of USSD:

• A USSD message can be upto 182 alphanumeric characters in length

• Unlike SMS, USSD is a session oriented service

• Simple and easy to send. No need to go into any menus and options. Just directly entered on the default mobile screen.

• USSD works on all GSM handsets of Phase II or later.

• There will not be any latency in request and responce as we experience in SMS based services

• The functionality will be the same even while roaming as the USSD messages always routed back to Home HLR.

• USSD is supported by WAP, SIM Application Toolkit and CAMEL enabling scope for many applciations.

• Works in two modes: pull mode and push mode.

Applications:

• USSD can be used as a WAP bearer.

• Used for menu based content services like news, weather, sports etc

• Used for prepaid callback service enabling prepaid roaming a better service

• Used in location based content services

• Used in SIM Application tool kit based applications.

Resources:

Messaging- SMS, SMPP, USSD, MMS Discussion Forum

Download specification : GSM ETSI 3.90 - Unstructured Supplementary Service Data (USSD) - Stage 2

Read More

ISUP (ISDN User Part)

ISUP (ISDN User Part) defines the messages and protocol used in the establishment and tear down of voice and data calls over the public switched telephone network (PSTN), and to manage the trunk network on which they rely. Despite its name, ISUP is used for both ISDN and non–ISDN calls. In the North American version of SS7, ISUP messages rely exclusively on MTP to transport messages between concerned nodes.

ISUP controls the circuits used to carry either voice or data traffic. In addition, the state of circuits can be verified and managed using ISUP. The management of the circuit infrastructure can occur both at the individual circuit level and for groups of circuits.

Services that can be defined using ISUP include: Switching, Voice mail, Internet offload. ISUP is ideal for applications such as switching and voice mail in which calls are routed between endpoints.

When used in conjunction with TCAP and SIGTRAN, ISUP becomes an enabler for Internet offload solutions in which Internet sessions of relatively long duration can be isolated from relatively brief phone conversations.

A simple call flow using ISUP signaling is as follows:

Call set up: When a call is placed to an out-of-switch number, the originating SSP transmits an ISUP initial address message (IAM) to reserve an idle trunk circuit from the originating switch to the destination switch. The destination switch rings the called party line if the line is available and transmits an ISUP address complete message (ACM) to the originating switch to indicate that the remote end of the trunk circuit has been reserved. The STP routes the ACM to the originating switch which rings the calling party's line and connects it to the trunk to complete the voice circuit from the calling party to the called party.

Call connection: When the called party picks up the phone, the destination switch terminates the ringing tone and transmits an ISUP answer message (ANM) to the originating switch via its home STP. The STP routes the ANM to the originating switch which verifies that the calling party's line is connected to the reserved trunk and, if so, initiates billing.

Call tear down: If the calling party hangs-up first, the originating switch sends an ISUP release message (REL) to release the trunk circuit between the switches. The STP routes the REL to the destination switch. If the called party hangs up first, or if the line is busy, the destination switch sends an REL to the originating switch indicating the release cause (e.g., normal release or busy). Upon receiving the REL, the destination switch disconnects the trunk from the called party's line, sets the trunk state to idle, and transmits an ISUP release complete message (RLC) to the originating switch to acknowledge the release of the remote end of the trunk circuit. When the originating switch receives (or generates) the RLC, it terminates the billing cycle and sets the trunk state to idle in preparation for the next call.

Links

http://www.telecomspace.com

http://www.pt.com/tutorials/ss7/isup.html

http://www.protocols.com/pbook/ss7.htm#ISUP

Read More

Intelligent Network Application Part (INAP)

Intelligent Network Application Part (INAP) is the signaling protocol used in Intelligent Networking. Developed by the International Telecommunications Union (ITU), IN is recognized as a global standard. Within the International Telecommunications Union, a total functionality of the IN has been defined and implemented in digestible segments called capability sets. The first version to be released was Capability Set 1 (CS-1). Currently CS-2 is defined and available. The CAMEL Application Part (CAP) is a derivative of INAP and enables the use of INAP in mobile GSM networks.

INAP is a signaling protocol between a service switching point (SSP), network media resources (intelligent peripherals), and a centralized network database called a service control point (SCP). The SCP consists of operator or 3rd party derived service logic programs and data.

• Service Switching Point (SSP) is a physical entity in the Intelligent Network that provides the switching functionality. SSP the point of subscription for the service user, and is responsible for detecting special conditions during call processing that cause a query for instructions to be issued to the SCP.

  The SSP contains Detection Capability to detect requests for IN services. It also contains capabilities to communicate with other physical entities containing SCF, such as SCP, and to respond to instructions from the other physical entities. Functionally, an SSP contains a Call Control Function, a Service Switching Function, and, if the SSP is a local exchange, a Call Control Agent Function. It also may optionally contain Service Control Function, and/or a Specialized Resource Function, and/or a Service Data Function. The SSP may provide IN services to users connected to subtending Network Access Points.

  The SSP is usually provided by the traditional switch manufacturers. These switches are programmable and they can be implemented using multipurpose processors. The main difference of SSP from an ordinary switch is in the software where the service control of IN is separated from the basic call control.

• Service Control Point (SCP) validates and authenticates information from the service user, processing requests from the SSP and issuing responses.The SCP stores the service provider instructions and data that direct switch processing and provide call control. At predefined points during processing an incoming or outgoing call, the switch suspends what it is doing, packages up information it has regarding the processing of the call, and queries the SCP for further instruction. The SCP executes user-defined programs that analyze the current state of the call and the information received from the switch. The programs can then modify or create the call data that is sent back to the switch. The switch then analyzes the information received from the SCP and follows the provided instruction to further process the call.

  Functionally, an SCP contains Service Control Function (SCF) and optionally also Service Data Function (SDF). The SCF is implemented in Service Logic Programs (SLP). The SCP is connected to SSPs by a signalling network. Multiple SCPs may contain the same SLPs and data to improve service reliability and to facilitate load sharing between SCPs. In case of external Service Data Point (SDP) the SCF can access data through a signalling network. The SDP may be in the same network as the SCP, or in another network. The SCP can be connected to SSPs, and optionally to IPs, through the signalling network. The SCP can also be connected to an IP via an SSP relay function. The SCP comprises the SCP node, the SCP platform, and applications. The node performs functions common to applications, or independent of any application; it provides all functions for handling service-related, administrative, and network messages. These functions include message discrimination, distribution, routing, and network management and testing. For example, when the SCP node receives a service-related message, it distributes the incoming message to the proper application. In turn, the application issues a response message to the node, which routes it to the appropriate network elements. The SCP node gathers data on all incoming and outgoing messages to assist in network administration and cost allocation. This data is collected at the node, and transmitted to an administrative system for processing.

• Intelligent Peripheral (IP) provides resources such as customized and concatenated voice announcements, voice recognition, and Dual Tone Multi-Frequencies (DTMF) digit collection, and contains switching matrix to connect users to these resources. The IP supports flexible information interactions between a user and the network. Functionally, the IP contains the Special Resource Function. The IP may directly connect to one or more SSPs, and/or may connect to the signalling network.

• Service Management Point (SMP) performs service management control, service provision control, and service deployment control. Examples of functions it can perform are database administration, network surveillance and testing, network traffic management, and network data collection. Functionally, the SMP contains the Service Management Function and, optionally, the Service Management Access Function and the Service Creation Environment
  Function. The SMP can access all other Physical Entities.

Conceptual model of the Intelligent Network :

The IN standards present a conceptual model of the Intelligent Network that model and abstract the IN functionality in four planes:

• The Service Plane (SP): This plane is of primary interest to service users and providers. It describes services and service features from a user perspective, and is not concerned with how the services are implemented within the network.
• The Global Functional Plane (GFP): The GFP is of primary interest to the service designer. It describes units of functionality, known as service independent building blocks (SIBs) and it is not concerned with how the functionality is distributed in the network. Services and service features can be realised in the service plane by combining SIBs in the GFP.
• The Distributed Functional Plane (DFP): This plane is of primary interest to network providers and designers. It defines the functional architecture of an IN-structured network in terms of network functionality, known as functional entities (FEs). SIBs in the GFP are realised in the DFP by a sequence of functional entity actions (FEAs) and their resulting information flows.
• The Physical Plane (PP): Real view of the physical network.The PP is of primary interest to equipment providers. It describes the physical architecture for an IN-structured network in terms of physical entities (PEs) and the interfaces between them. The functional entities from the DFP are realised by physical entities in the physical plane.

Services that can be defined with INAP include:

• Single number service: one number reaches a local number associated with the service
• Personal access service: provide end user management of incoming calls
• Disaster recovery service: define backup call destinations in case of disaster
• Do not disturb service: call forward
• Virtual private network short digit extension dialing service

Advantages created by the IN architecture:

• extensive use of information processing techniques;
• efficient use of network resources;
• modularization of network functions;
• integrated service creation and implementation by means of reusable standard network functions;
• flexible allocation of network functions to physical entities;
• portability of network functions among physical entities;
• standardised communication between network functions via service independent interfaces;
• customer control over their specific service attributes;
• standardised management of service logic.

References:

http://www.telecomspace.com

SS7 Discussion Forum

http://www.item.ntnu.no/fag/ttm4130/stottelitteratur/IN.pdf

http://www.doc.ic.ac.uk/~nd/surprise_97/journal/vol4/vra/

Read More

Transaction Capabilities Application Part (TCAP)

Transaction Capabilities Application Part (TCAP) defines the messages and protocol used to communicate between applications (deployed as subsystems) in nodes. It is used for database services such as calling card, 800, and AIN as well as switch-to-switch services including repeat dialing and call return. Because TCAP messages must be delivered to individual applications within the nodes they address, they use the SCCP for transport.

TCAP enables the deployment of advanced intelligent network services by supporting non-circuit related information exchange between signalling points using the SCCP connectionless service. TCAP messages are contained within the SCCP portion of an MSU. A TCAP message is comprised of a transaction portion and a component portion.

TCAP supports the exchange of non-circuit related data between applications across the SS7 network using the SCCP connectionless service. Queries and responses sent between SSPs and SCPs are carried in TCAP messages. For example, an SSP sends a TCAP query to determine the routing number associated with a dialed 800/888 number and to to check the personal identification number (PIN) of a calling card user. In mobile networks (IS-41 and GSM), TCAP carries Mobile Application Part (MAP) messages sent between mobile switches and databases to support user authentication, equipment identification, and roaming.

Resources:

http://www.telespace.com

SS7 Discussion Forum

http://www.protocols.com/pbook/ss7.htm#SCCP

openSS7 TCAP

Read More

Signaling Connection Control Part (SCCP)

The Signaling Connection Control Part (SCCP) layer of the SS7 stack provides provides connectionless and connection-oriented network services and global title translation (GTT) capabilities above MTP Level 3. SCCP is used as the transport layer for TCAP-based services. It offers both Class 0 (Basic) and Class 1 (Sequenced) connectionless services. SCCP also provides Class 2 (connection oriented) services, which are typically used by Base Station System Application Part, Location Services Extension (BSSAP-LE). In addition, SCCP provides Global Title Translation (GTT) functionality.

The signaling connection control part (SCCP) provides two major functions that are lacking in the MTP. The first of these is the capability to address applications within a signaling point. The MTP can only receive and deliver messages from a node as a whole; it does not deal with software applications within a node.

While MTP network-management messages and basic call-setup messages are addressed to a node as a whole, other messages are used by separate applications (referred to as subsystems) within a node. Examples of subsystems are 800 call processing, calling-card processing, advanced intelligent network (AIN), and custom local-area signaling services (CLASS) services (e.g., repeat dialing and call return). The SCCP allows these subsystems to be addressed explicitly.

The signaling connection control part (SCCP) provides two major functions that are lacking in the MTP. The first of these is the capability to address applications within a signaling point. The MTP can only receive and deliver messages from a node as a whole; it does not deal with software applications within a node.

While MTP network-management messages and basic call-setup messages are addressed to a node as a whole, other messages are used by separate applications (referred to as subsystems) within a node. Examples of subsystems are 800 call processing, calling-card processing, advanced intelligent network (AIN), and custom local-area signaling services (CLASS) services (e.g., repeat dialing and call return). The SCCP allows these subsystems to be addressed explicitly.

The second function provided by the SCCP is Global Title translation, the ability to perform incremental routing using a capability called global title translation (GTT). GTT frees originating signaling points from the burden of having to know every potential destination to which they might have to route a message. A switch can originate a query, for example, and address it to an STP along with a request for GTT. The receiving STP can then examine a portion of the message, make a determination as to where the message should be routed, and then route it.

For example, calling-card queries (used to verify that a call can be properly billed to a calling card) must be routed to an SCP designated by the company that issued the calling card. Rather than maintaining a nationwide database of where such queries should be routed (based on the calling-card number), switches generate queries addressed to their local STPs, which, using GTT, select the correct destination to which the message should be routed. Note that there is no magic here; STPs must maintain a database that enables them to determine where a query should be routed. GTT effectively centralizes the problem and places it in a node (the STP) that has been designed to perform this function.

In performing GTT, an STP does not need to know the exact final destination of a message. It can, instead, perform intermediate GTT, in which it uses its tables to find another STP further along the route to the destination. That STP, in turn, can perform final GTT, routing the message to its actual destination.

Intermediate GTT minimizes the need for STPs to maintain extensive information about nodes that are far removed from them. GTT also is used at the STP to share load among mated SCPs in both normal and failure scenarios. In these instances, when messages arrive at an STP for final GTT and routing to a database, the STP can select from among available redundant SCPs. It can select an SCP on either a priority basis (referred to as primary backup) or so as to equalize the load across all available SCPs (referred to as load sharing).

Links

www.telecomspace.com

SS7 Forum

protocols.com SCCP tutorial

http://www.iec.org/online/tutorials/ss7/topic09.html

http://www.pt.com/tutorials/ss7/sccp.html

Read More

Message Transfer Part (MTP)

The Message Transfer Part (MTP) layer of the SS7 protocol provides the routing and network interface capabilities that support SCCP, TCAP, and ISUP. Message Transfer part (MTP) is divided into three levels.

MTP Level 1 (Physical layer) defines the physical, electrical, and functional characteristics of the digital signaling link. Physical interfaces defined include E-1 (2048 kb/s; 32 64 kb/s channels), DS-1 (1544 kb/s; 24 64 kp/s channels), V.35 (64 kb/s), DS-0 (64 kb/s), and DS-0A (56 kb/s).

MTP Level 2 provides the reliability aspects of MTP including error monitoring and recovery. (MTP-2) is a signalling link which together with MTP-3 provides reliable transfer of signalling messages between two directly connected signalling points.

MTP Level 3 provides the link, route, and traffic management aspects of MTP. MTP 3, thus ensures reliable transfer of the signalling messages, even in the case of the failure of the signalling links and signalling transfer points. The protocol therefore includes the appropriate functions and procedures necessary both to inform the remote parts of the signalling network of the consequences of a fault, and appropriately reconfigure the routing of messages through the signalling network.

Links:

http://www.telecomspace.com/ss7.html

Performance Technlogies MTP Tutorial

http://www.protocols.com/pbook/ss7.htm#MTP-2

http://www.iec.org/online/tutorials/ss7/topic09.html

Read More

SS7 Signaling System #7

Resource from http://www.telecomspace.com/

There are two essential components to all telephone calls. The first, and most obvious, is the actual content—our voices, faxes, modem data, etc. The second is the information that instructs telephone exchanges to establish connections and route the “content” to an appropriate destination. Telephony signaling is concerned with the creation of standards for the latter to achieve the former. These standards are known as protocols. SS7 or Signaling System Number 7 is simply another set of protocols that describe a means of communication between telephone switches in public telephone networks. They have been created and controlled by various bodies around the world, which leads to some specific local variations, but the principal organization with responsibility for their administration is the International Telecommunications Union or ITU-T.
Signalling System Number 7 (SS#7 or C7) is the protocol used by the telephone companies for interoffice signalling. In the past, in-band signalling techniques were used on interoffice trunks. This method of signalling used the same physical path for both the call-control signalling and the actual connected call. This method of signalling is inefficient and is rapidly being replaced by out-of-band or common-channel signalling techniques.

To understand SS7 we must first understand something of the basic inefficiency of previous signaling methods utilized in the Public Switched Telephone Network (PSTN). Until relatively recently, all telephone connections were managed by a variety of techniques centered on “in band” signaling.
A network utilizing common-channel signalling is actually two networks in one:
1. First there is the circuit-switched "user" network which actually carries the user voice and data traffic. It provides a physical path between the source and destination.
2. The second is the signalling network which carries the call control traffic. It is a packet-switched network using a common channel switching protocol.

The original common channel interoffice signalling protocols were based on Signalling System Number 6 (SS#6). Today SS#7 is being used in new installations worldwide. SS#7 is the defined interoffice signalling protocol for ISDN. It is also in common use today outside of the ISDN environment. The primary function of SS#7 is to provide call control, remote network management, and maintenance capabilities for the inter- office telephone network. SS#7 performs these functions by exchanging control messages between SS#7 telephone exchanges (signalling points or SPs) and SS#7 signalling transfer points (STPs).

The switching offices (SPs) handle the SS#7 control network as well as the user circuit-switched network. Basically, the SS#7 control network tells the switching office which paths to establish over the circuit-switched network. The STPs route SS#7 control packets across the signalling network. A switching office may or may not be an STP.

SS7 Protocol layers:

The SS7 network is an interconnected set of network elements that is used to exchange messages in support of telecommunications functions. The SS7 protocol is designed to both facilitate these

functions and to maintain the network over which they are provided. Like most modern protocols, the SS7 protocol is layered.

Physical Layer (MTP-1) This defines the physical and electrical characteristics of the signaling links of the SS7 network. Signaling links utilize DS–0 channels and carry raw signaling data at a rate of 56 kbps or 64 kbps (56 kbps is the more common implemen tation). Message Transfer Part—Level 2 (MTP-2) The level 2 portion of the message transfer part (MTP Level 2) provides link-layer functionality. It ensures that the two end points of a signaling link can reliably exchange signaling messages. It incorporates such capabilities as error checking, flow control, and sequence checking. Message Transfer Part—Level 3 (MTP-3) The level 3 portion of the message transfer part (MTP Level 3) extends the functionality provided by MTP level 2 to provide network layer functionality. It ensures that messages can be delivered between signaling points across the SS7 network regardless of whether they are directly connected. It includes such capabilities as node addressing, routing, alternate routing, and congestion control.

Signaling Connection Control Part (SCCP)

The signaling connection control part (SCCP) provides two major functions that are lacking in the MTP. The first of these is the capability to address applications within a signaling point. The MTP can only receive and deliver messages from a node as a whole; it does not deal with software applications within a node.

While MTP network-management messages and basic call-setup messages are addressed to a node as a whole, other messages are used by separate applications (referred to as subsystems) within a node. Examples of subsystems are 800 call processing, calling-card processing, advanced intelligent network (AIN), and custom local-area signaling services (CLASS) services (e.g., repeat dialing and call return). The SCCP allows these subsystems to be addressed explicitly.

ISDN User Part (ISUP)

ISUP user part defines the messages and protocol used in the establishment and tear down of voice and data calls over the public switched network (PSN), and to manage the trunk network on which they rely. Despite its name, ISUP is used for both ISDN and non–ISDN calls. In the North American version of SS7, ISUP messages rely exclusively on MTP to transport messages between concerned nodes.

Transaction Capabilities Application Part (TCAP)

TCAP defines the messages and protocol used to communicate between applications (deployed as subsystems) in nodes. It is used for database services such as calling card, 800, and AIN as well as switch-to-switch services including repeat dialing and call return. Because TCAP messages must be delivered to individual applications within the nodes they address, they use the SCCP for transport.

Operations, Maintenance, and Administration Part (OMAP)

OMAP defines messages and protocol designed to assist administrators of the SS7 network. To date, the most fully developed and deployed of these capabilities are procedures for validating network routing tables and for diagnosing link troubles. OMAP includes messages that use both the MTP and SCCP for routing.

Read More