Начиная с начала 2000 года осуществляется внедрение GHIS в здравоохранении, в рамках принятого проекта о реформирование информ Mathematical Problems of Computer Science 50, 56--60, 2018. Notification Mechanisms by Initiative of E-mail Receiver in Systems Based on E-mail/SMS Technologies Andranik E. Mkhitaryan, Arthur S. Petrosyan and Aram S. Nanassian Institute for Informatics and Automation Problems of NAS RA e-mail: and.mkhitaryan@gmail.com, arthur@sci.am, ananas@sci.am Abstract The feature of mechanisms for the exchange of messages in computer and cellular networks is considered, in order to send a notification to the receiver of e- mail on his/her own initiative using IP and GSM technologies. The peculiarities of technical models for designing a separated system are compared. Keywords: Notification, mail2sms, E-mail, SMS. 1. Introduction Nowadays, electronic mail is one of the widespread info-communicational systems, which provides the opportunity to exchange messages between computers by the Internet [1]. However, e-mail is a typical “on demand” system. Despite the instant delivery of messages, the addressees will see new letters only when they request them from the server. Another well-known info-communicational system is SMS. It operates on a completely different platform: Global System for Mobile (GSM). This system has some limitations, such as text size, content, etc. However, an undeniable advantage of this technology is the delivery of the message directly to “the pocket” of the mobile subscriber. Many modern mobile devices allow you to get e-mail messages via mobile networks directly to the device. But still, the cost of Internet traffic via cellular networks forces many users to keep the mobile Internet switched off, which prevents receiving urgent messages, because they are being delivered according to the client request. In case of SMS the message is delivered to the device by the Mobile operator’s (server) decision, thus it remains a more flexible solution than e-mail. The use of e-mail and SMS mechanisms in one unified system could enhance the features of both as they complement each other. It’s a common practice for e-mail users to register some list of e-mail addresses to get notified in case someone from that list sends him a message. Such systems help users to be informed about the received e-mails from important sources as soon as possible. Usually this kind of 56 mailto:and.mkhitaryan@gmail.com mailto:arthur@sci.am mailto:ananas@sci.am A. Mkhitaryan, A. Petrosyan and A. Nanassian 57 mechanisms are embedded in mail server, thus being implemented inside the server of mail providers because the server is the only resource, which has complete information about the sent/received e-mails. Such mechanisms are expensive and not targeted especially for small providers as they face all the complexity of software and hardware for sending SMS notifications. 2. Solution In this article a mechanism is considered, which provides the possibility to use a separated and shared platform for e-mail providers (such as UniMail), which solves the above-described problem. For such systems it is necessary to have information about the recent history of received mails of users (Fig. 1). The purpose is to design a shared system so that it can have the possibility to integrate mail providers [2], [3]. To be able to realize such a system, the e-mail provider should provide the necessary information. That could be done in different ways:  Design a filter software in mail server, which will have access to all components of all e-mails and by parsing the necessary content (i.e., the fields From and To) sent to the separated system. Sending process also could be done in different ways. For such systems, mechanisms based on database server/client or other protocols are mostly being used. The advantage of this solution is that it has the message itself and can process all the fields, even the body and the subject. On the other hand, e- mail messages are the property of the sender and receiver only, which could contain private information. A software, which has access to the private information of the e-mail and has an ability to send data to other machines is an additional risk for the admins of the servers of mail providers. This solution could be used for the systems where the contents of fields “From”, “To”, “Body”, “Subject”, etc., are necessary. However, any software, which is using this mechanism should be well tested and certified.  The other way, which is currently well known to admins is “Log forwarding”. It sends the log files generated by some software to another machine. The log file contains information about the current processes of particular software. Each line of the log has a standard format, which contains the date (in server’s time zone), the name of application, some details about the current action of the software, etc. [5]. Specifically, for the mail server, the generated log contains the fields “From”, “To” and the time when the message was sent. Those three components are necessary and sufficient information to send a notification to the receiver in case he/she asked about it before. The advantage of this method is that it is easy to configure, does not require access to private files. In many servers “log Fig. 1. Connection of mail server and UniMail server. 58 Notification Mechanisms by Initiative of E-mail Receiver in Systems Based on E-mail/SMS Technologies forwarding” is already in use, thus in this case a new effort will not be required. However, it has limited information about the e-mail message and could not be used in systems, which require more information rather than “From” and “To” fields. Log file of software, which is configured server side with active users (i.e., mail server) will contain lots of information written by different threads, which make the file size very big. Forwarding such huge information periodically could lead to heavy traffic and slow down the workflow of software. The notifier applications require limited information from the log file. The only required lines are the log about e-mail, which indicates the mail sending/receiving and the log that confirms the mail has passed all the checking filters (i.e., spam filter). One of the most popular tools for log forwarding is called Rsyslog. It has an easy to use interface and is embedded in many Unix-like computer systems by default. Rsyslog provides the ability to filter logs by specifying the format. For example: if ($programname ==′ ProgramName′) and ($msg contains ′from =<′) and($msg contains ′to =< ′) … According to the example, only the logs containing the fragments ‘from=<’ and ‘to=<’ will be processed. In real example, in the log file with 20000 lines there are 1705 logs containing the fragments. The size of the log file has been reduced by 91.475 percent. A similar filtering mechanism could be realized in the UniMail server in case the log forwarders have not done it on their side. This will improve the performance. Another problem is the memory usage of forwarded logs in UniMail server. The memory should be cleaned periodically. For such situations there is a mechanism called “Log Rotation”. That allows you to specify rotation rules, such as the size of log file, the period of rotation, the number of rotated files to keep, etc. In Unix-like computer systems there is an already integrated mechanism for “log rotation”. For notification systems where receiver gets notified on his/her own initiative, the required information is the “From” and “To” fields of the e-mail, thus the limitations of the second considered solution cannot obstruct its usage. Such a mechanism has been implemented in info-communicational system UniMail [4]. As a complete resource, UniMail provides services to email users to notify the receivers of messages on the initiative of either the sender or the receiver. The mandatory condition is that the mail provider of the user should be configured and integrated within the UniMail server to share the important information for notifications. In UniMail the second considered solution was implemented. To use it, the user just needs to combine “white list”. The user will be notified of each received email message from any member of the white list. To use the provided services, where the initiator is the receiver of email, the user should be authenticated in UniMail server. UniMail system provides complete command list, which allows users to register, combine black and white lists, send an SMS notification parallel to the e-mail, get notified about the received e- mails from important sources, send SMS messages by email, etc. Some commands with descriptions:  *notice to…(phone numbers)* - Parallel to the letter send SMS notification to the addressee/addressees  *SMS to… (phone numbers)* - Send an SMS to the addressee/addressees A. Mkhitaryan, A. Petrosyan and A. Nanassian 59  *add white list* - Include the addressees in the "white list"  *del white list* - Exclude the addressees from the "white list" Conclusion Except for many indisputable advantages of e-mail and SMS technologies, both have unique disadvantages. E-mail is a typical “on demand” info-communicational resource, while SMS is not. That feature of e-mail could be overcome by using E-mail and SMS technologies in a united system. To be able to create a separate system, some data is required from the mail server. For notification systems, a model of log forwarding is suggested based on the comparison of the other mechanisms. References [1] Д. Геворкян, А. Нанасян и К. Хачатрян «Новые WEB ресурсы ASNET.AM», Материалы конф. CSIT-2011, Ереван, сс. 311-313, 2011. [2] D. Gevorkyan, K.Khachatryan, A.Nanassian, A.Petrosyan, G.Petrosyan, V.Sahakyan and E.Vardanyan, “Mail informer- selective incoming instand phone notification system”, Proceedings of International Conference Computer Science and Information Technologies, Yerevan, Armenia, pp. 466-- 467, 2009. [3] А. Нанасян и К. Хачатрян, «Mail2sms.asnet.am – система оповещения о входящих письмах», Материалы конф. CSIT-2013, Ереван, 2013. [4] E. Mateev, A. Mkhitaryan, A. Nanasyan, V. Sahakyan and A. Petrosyan, “Hybrid infocommunication Email SMS UNImail system”, Proceedings of International Conference Computer Science and Information Technologies, Yerevan, Armenia, pp. 389-- 391, 2009. [5] R. Gerhards “The Syslog Protocol RFC 5424”, IETF-related tools, standalone or hosted on tools.ietf.org, 2009. Submitted 20.07.2018, accepted 28.11.2018. 60 Notification Mechanisms by Initiative of E-mail Receiver in Systems Based on E-mail/SMS Technologies Էլ․ նամակ ստացողի նախաձեռնությամբ ծանուցման համակարգեր հիմնված էլ․փոստի և SMS-ի տեխնոլոգիաների վրա Ա. Մխիթարյան, Ա․ Պետրոսյան և Ա․Նանասյան Ամփոփում Աշխատանքում դիտարկվել է բջջային և համակարգչային ցանցերում տեքստային հաղորդագրությունների փոխանակման մեխանիզմների կիրառմամբ ծանուցման համակարգերի ստեղծման նախադրյալները։ էլեկտրոնային հաղորդագրության ստացողին իր իսկ նախաձեռնությամբ ծանուցման համակարգերի առանձնահատկությունները՝ IP և GSM տեխնոլոգիաների օգտագործմամբ: Համեմատվել են առանձնացված համակարգի նախագծման տեխնիկական մոդելների առանձնահատկությունները: Механизмы уведомления по инициативе почтового получателя на базе технологий e-mail и sms А․ Мхитарян, А. Петросян и А․ Нанасян Аннотация Рассмотрены механизмы обмена сообщениями в компьютерных и сотовых сетях с целью отправки уведомления получателю электронной почты по его собственной инициативе с использованием технологий IP и GSM. Сравниваются особенности технических моделей для проектирования разделенной системы.