Investigating and Implementing an Email Forensic Readiness Architecture

Total Page:16

File Type:pdf, Size:1020Kb

Investigating and Implementing an Email Forensic Readiness Architecture Investigating and Implementing an Email Forensic Readiness Architecture by F.R. Van Staden Submitted in fulfilment of the requirements for the degree Magister Scientiae (Computer Science) in Faculty of Engineering, Built-Environment and Information Technology at the University of Pretoria August 2017 Investigating and Implementing an Email Forensic Readiness Architecture by F.R. Van Staden supervised by Prof H.S. Venter Department of Computer Science Abstract Email forensic investigations rely on the collection and analysis of digital forensic evidence collected from email systems. Problems arise when the digital forensic evidence needed for the email forensic investigation is no longer available or there is a huge amount of email data that can be collected which take time to sift through to find the digital forensic evidence that is actually needed. The email digital forensic readiness (eDFR) architecture, as proposed in this dissertation, endeavours to address these problems. The eDFR architecture is based on the digital forensic readiness process described in ISO 27043. To ensure that the collected email data can be used as digital forensic evidence a process to validate the collected email data was created. The validation process uses data collected from the email IP headers to validate the data in the SMTP headers ensuring that the SMTP header data was not spoofed or in any way changed. The IP header data is stored in an audit database together with the email data so that the validation process can be executed at any time. An audit database is used to store the collected data to ensure that once the data is stored it cannot be tampered with. The digital forensic evidence collected using the eDFR architecture was found to be useable as part of an email forensic investigation. It was also found to be useful for other processes such as creating a graph representation of email sent and received by an email system or a group of email systems. It was shown that implementing the eDFR architecture could be achieved in an economical way that has almost no impact on current email systems. i Table of Contents Chapter 1 : Introduction ................................................................................................... 2 1.1 Introduction ............................................................................................................ 2 1.2 Terms...................................................................................................................... 3 1.3 Problem statement ................................................................................................... 5 1.4 Goals ...................................................................................................................... 7 1.5 Scope ...................................................................................................................... 7 1.6 Dissertation Structure .............................................................................................. 8 Chapter 2 : Email systems .............................................................................................. 12 2.1 Introduction .......................................................................................................... 12 2.2 Simple Message Transfer Protocol ........................................................................ 13 2.3 Internet Protocol ................................................................................................... 15 2.4 Security Architecture for Internet Protocol ............................................................ 16 2.5 An overview of email system components ............................................................ 17 2.5.1 Basic email systems ....................................................................................... 17 2.5.2 Anti-Spam servers .......................................................................................... 20 2.5.3 Archiving server ............................................................................................ 21 2.5.4 DNS Server .................................................................................................... 21 2.6 Information security and email systems ................................................................. 23 2.7 Legislation and governance with regard to electronic communication ................... 23 2.8 Conclusion ............................................................................................................ 24 Chapter 3 : State of the art of Spam and Anti-Spam ....................................................... 26 3.1 Introduction .......................................................................................................... 26 3.2 Intelligent Filters ................................................................................................... 28 3.3 Content Scanning .................................................................................................. 28 3.4 Block list, black list, white list and mailbox authentication .................................... 29 3.5 Anti-spoofing SMTP service extensions ................................................................ 30 3.6 Honey-pots ........................................................................................................... 31 3.7 Botnets .................................................................................................................. 31 3.8 Conclusion ............................................................................................................ 33 ii Chapter 4 : Digital Forensics, Email forensics and Digital Forensic Readiness ............... 34 4.1 Introduction .......................................................................................................... 34 4.2 Digital Forensics ................................................................................................... 34 4.3 Email forensics ..................................................................................................... 35 4.4 Digital Forensic Readiness .................................................................................... 36 4.4.1 Designing a DFR process ............................................................................... 36 4.4.2 Performance monitoring tools ........................................................................ 39 4.4.3 Network monitoring tools .............................................................................. 41 4.5 DFR processes, Big-Data and Hadoop .................................................................. 41 4.6 Conclusion ............................................................................................................ 44 Chapter 5 : Planning the eDRF architecture .................................................................... 46 5.1 Introduction .......................................................................................................... 46 5.2 Creating the Scenario definition ............................................................................ 48 5.3 Identification of potential digital evidence sources ................................................ 50 5.4 Planning the collection, storage and handling of data ............................................ 50 5.5 Planning the analysis of the data ........................................................................... 51 5.6 Planning incident detection ................................................................................... 51 5.7 Defining system architecture ................................................................................. 51 5.8 Summary .............................................................................................................. 53 Chapter 6 : Identifying sources of potential digital evidence for the eDRF architecture .. 56 6.1 Introduction .......................................................................................................... 56 6.2 Automating the collection and storage of SMTP header data ................................. 57 6.3 Adding validation to SMTP header ....................................................................... 60 6.3.1 Adding digital forensic data to SMTP ............................................................ 60 6.3.2 Adding digital forensic data to IP ................................................................... 62 6.3.3 Gap-detection Algorithm................................................................................ 65 6.4 Implementing log file sniffing using a performance monitoring tool...................... 69 6.4.1 Setup of the Performance monitoring tool to collect digital forensic data ....... 69 6.4.2 Collecting data from the log files using custom probes ................................... 71 6.4.3 Using the data for a digital forensic investigation ........................................... 73 6.4.4 Collecting digital evidence from email system log files .................................. 76 6.5 Collecting IP header data ...................................................................................... 76 iii 6.5.1 Creating the IP packet data collection process ................................................ 77 6.5.2 Scenario for collecting IP header data ............................................................ 80 6.5.3 Implementing the collection points ................................................................. 81 6.5.4 Reviewing the data collected
Recommended publications
  • Untersuchung Von Techniken Zur Persönlichen E-Mail-Postfachverschlüsselung
    Fachbereich VI - Informatik und Medien Master-Arbeit von Benjamin Fichtner zur Erlangung des akademischen Grades Master of Engineering im Studiengang Technische Informatik - Embedded Systems Untersuchung von Techniken zur persönlichen E-Mail-Postfachverschlüsselung Erstprüfer: Prof. Dr. rer. nat. Thomas Scheffler Gutachter: Prof. Dr. rer. nat. Rüdiger Weis Eingereicht am: 04.03.2019 Kurzfassung E-Mails enthalten häufig sensible und schützenswerte Inhalte, die nicht für Dritte be- stimmt sind. Obwohl die E-Mail ein weit verbreiteter Kommunikationsstandard ist, er- füllt sie viele aktuelle Sicherheitsanforderungen nicht [Foster et al., 2015]. Eines der Probleme ist, dass E-Mail-Inhalte im Klartext auf den Servern des E-Mail-Providers ge- speichert sind. Dort haben berechtigte und unberechtigte Dritte eine dauerhafte Möglich- keit, auf diese zuzugreifen. Um das zu verhindern, wurde die sogenannte persönliche E- Mail-Postfachverschlüsselung entwickelt. Diese neuartige, serverseitige Schutzmaßnah- me speichert eingehende E-Mails verschlüsselt ab. Sie sorgt dafür, dass die verschlüssel- ten E-Mails ausschließlich durch den Nutzer bzw. dessen Passwort entschlüsselt werden können. In dieser Masterarbeit soll untersucht werden, ob der Einsatz von Postfachverschlüs- selungstechniken Auswirkungen auf den E-Mail-Server-Betrieb hat und wie sich die- se darstellen. Hierbei werden die vier Postfachverschlüsselungstechniken GPG-Sieve- Filter, MailCrypt, Scrambler und TREES miteinander verglichen. Dazu werden die ver- schiedenen Techniken analysiert, eine Testumgebung entwickelt, sowie eine Messreihe konzipiert und durchgeführt. Abstract In digital communication, e-mail is an indispensable means of communication. They often contain sensitive and protective content that is not intended for third parties. Alt- hough e-mail is such an important and widespread communication standard, it it does not meet modern security requirements [Foster et al., 2015].
    [Show full text]
  • Computer System Administration. Topic 11. Secure E-Mail Service
    Computer System Design and Administration Topic 11. Secure e-Mail service: SMTP Postfix, IMAP Dovecot (over SSL) José Ángel Herrero Velasco Department of Computer and Electrical Engineering This work is published under a License: Creative Commons BY-NC-SA 4.0 Computer System Design and Administration Topic 11. Secure e-Mail service: SMTP Postfix, IMAP Dovecot (over SSL) Puzzle Secure Information Server Clients Active ISC Directory DHCP Open ISC client SSL SSL LDAP DNS OpenLDAP DB LDAP ISC SSL NTP SSH IMAP (mail client) NFSv4 CIFS Secure MAIL Server Network file server/ MS Windows-Linux/UNIX interoperability SMTP IMAP (Postfix) (Dovecot) RAID/LVM SAMBA NFSv4 SSL Secure Web Server Ganglia Apache2 Hosts Core (web data) User (web data) Virtual MailLISTs Webmail pool pool (MailMan) (squirrelmail) (public_html) SSL Webmin Nagios 2 (.html, php …) WordPress José Ángel Herrero Velasco Computer System Design and Administration Topic 11. Secure e-Mail service: SMTP Postfix, IMAP Dovecot (over SSL) Target: e-Mail services • Deployment and development of an INTERNET secure e-MAIL service based on SMTP/IMAP protocols: – Sending mail using SMTP protocol: Pos(ix. – Receiving mail using IMAP protocol: Dovecot. – Management of Maildrop: Maildirs. – MUA-MTA secure communicaon (encrypted): TLS/SSL. • Installaon, configuraon and start up of a Webmail client: – Roundcube. – Mailmain. José Ángel Herrero Velasco Computer System Design and Administration Topic 11. Secure e-Mail service: SMTP Postfix, IMAP Dovecot (over SSL) The e-Mail system HTTP SMTP IMAP • Definions and basics: TCP TCP UDP – E-Mail: the electronic mail system: • Network service that enables 2 users from different computers IP to send and receive (exchange) digital messages.
    [Show full text]
  • LNCS 2763, Pp
    A High Performance and Low Cost Cluster-Based E-mail System Woo-Chul Jeun1, Yang-Suk Kee1, Jin-Soo Kim2, and Soonhoi Ha1 1 School of Electrical Engineering and Computer Science, Seoul National University, San 56-1, Sinlim-dong, Gwanak-gu, Seoul 151-744, Korea {wcjeun, yskee, sha}@iris.snu.ac.kr 2 Division of Computer Science, KAIST, Daejeon 305-701, Korea [email protected] Abstract. A large-scale e-mail service provider requests a highly scal- able and available e-mail system to accommodate the increasing volume of e-mail traffic as well as the increasing number of e-mail users. To reduce the system development and maintenance cost, it is requested to make the system modular using off-the-shelf components. In this pa- per, we propose a cluster-based e-mail system architecture to achieve the goals of high scalability and availability, and low development and maintenance cost. We adopt the internal structure of a typical Internet e-mail system for a single server, called the MTA-MDA structure, to the proposed system architecture for the low cost requirements. We have implemented four different system configurations with the MTA-MDA structure and compare their performances. Experimental results show that the proposed system architecture achieves all the design objectives. 1 Introduction The growth of the Internet has led to an explosion in volumes of e-mail traffic and in number of the users of e-mail service. At the same time, large-scale e-mail service providers have appeared. They have hundreds of millions of subscribers and process billions of messages: for example, in May 2001, Hotmail had over 100 million users and Yahoo! Mail, in March 1999, served 45 million users with 3.6 billion mail messages [1][2].
    [Show full text]
  • Lecture Notes for Web Security 2019 Part 5 — E-Mail Security Martin Hell
    Lecture Notes for Web Security 2019 Part 5 | E-mail Security Martin Hell This chapter will discuss some different security aspects of emails. In order to understand these aspects, it is necessary to understand the SMTP protocol, i.e., how emails are sent from one user to another, and what the messages look like. 1 The SMTP Protocol SMTP (Simple Mail Transfer Protocol) is the most common protocol used to transfer emails. It was first defined in RFC 821 [6], which was obsoleted by RFC 2821 [4], which was again obsoleted by RFC 5321 [5]. The email architecture consists of several building blocks, see Figure 1. • MUA - Mail User Agent. This is the source and target of emails and is responsible for delivering the email to the MSA. Typical examples are Eudora, Outlook, Pine and Kmail. • MSA - Mail Submission Agent. This receives the message from the MUA and delivers it to the MTA. This is usually implemented together with the MTA instead of being a standalone program. The MSA can implement security checks on the email, e.g., checking that it is not spam, before sending it to the MTA. Message submission uses TCP port 587 and is discussed in RFC 4409 [3]. • MTA - Mail Transfer Agent. This is the building block that implements the SMTP protocol. It is responsible for both sending and receiving mes- sages. When the destination has been reached, the MTA at the end host sends the message to the MDA. Examples of MTAs are sendmail, postfix, qmail and Microsoft's Exchange Server. • MDA - Mail Delivery Agent.
    [Show full text]
  • (19) United States (12) Patent Application Publication (10) Pub
    US 20090164586A1 (19) United States (12) Patent Application Publication (10) Pub. No.: US 2009/0164586 A1 DOUGLAS et al. (43) Pub. Date: Jun. 25, 2009 (54) METHOD AND SYSTEM FOR MANAGING Publication Classi?cation THE RECEPTION OF MESSAGES IN A (51) Int Cl COMMUNICATION NETWORK G0 6F 15/16 (200601) (52) US. Cl. ...................................................... .. 709/206 (75) Inventors: PAUL B. DOUGLAS, SHARDLOW DERBY (GB); (57) ABSTRACT ANDREW I‘ THOMPSON’ A method and system for managing the reception of messages SOUTHAMPTON (GB) in a communication network (100) includes a ?rst client node (102) polling (404) a server node (110) to check for the arrival Correspondence Address: of a ?rst message that is related to a ?rst message account at MOTOROLA INC the server node (110). The ?rst client node has a pull-message 600 NORTH Us HIGHWAY 45, W4 _ 39Q con?guration for the ?rst message account. The method also LIBERTYVILLE, IL 600485343 (Us) includes receiving (410) a push-message at the ?rst client node. The push-message noti?es the ?rst client node of the . _ arrival of a second message at the server node that is related to (73) Asslgnee' ’ S the ?rst message account. Further, the method includes ’ (U ) changing (502) the ?rst client node from a pull-message con?guration to a push-message con?guration, based on the (21) Appl. NO-I 11/962,374 push-message. Furthermore, the method includes the ?rst client node terminating (506) the polling of the server node (22) Filed; Dec. 21, 2007 for the ?rst message account. r102 FIRST CLIENT NODE r202 MEMORY [204 206 110 PROCESSOR r SERVER r TRANSCEIVER 4 ' ' ' ' '> NODE r210 MESSAGE r203 RETR'EVER CONFIGURATION MANAGER Patent Application Publication Jun.
    [Show full text]
  • 리눅스 서버 Chapter 08 324 Page
    20 Linux fedora Server 리눅스 왕초보 실무를 익혀라! 김영훈ㆍ정거룡 지음 리눅스 서버 Chapter 08 324 page 메일 서버 8.1 Email 서비스의 구성 요소 8.2 메일 서버 구축 05 8.1 Email 서비스의 구성 요소 • mail 서비스 관련 프로토콜 – SMTP(Simple Mail Transfer Protocol) • 인터넷 상에서 전자 메일을 전송할 때 쓰이는 표준 프로토콜 – POP3(Post Office Protocol 3) • 메일서버로 수신된 메일을 사용자 자신의 PC 즉 메일 client 프로그램으로 다운 로드해주는 프로토콜 – IMAP(Internet Messaging Access Protocol) • POP3와 마찬가지로 메일을 사용자가 볼 수 있도록 해주는 프로토콜 • 서버에 메일 박스를 둘 수 있어서 메일을 사용자의 client로 다운로드 하지 않더라도 서버에서 메일 관리 가능 3 05 8.1 Email 서비스의 구성 요소 • mail 서비스 관련 프로그램 – MTA (Mail Transfer Agent) • SMTP 프로토콜을 이용하여 client에서 server로 메일 메시지 전송 • sendmail 등 – MUA (Mail User Agent) • 사용자PC(client)에서 메일을 보내고 받을 때 이용 • 윈도우의 아웃룩, Fedora Linux의 에볼루션 등 – MDA (Mail Delivery Agent) • 메일서버(MTA)에 도착한 메일을 사용자 메일박스(Mail Box)로 저장 • /bin/mail (mailx), procmail 등 – MRA (Mail Retrieval Agent) • 사용자 메일박스에서 Client프로그램(아웃룩 등)으로 메일을 받아오는 역할 • fetchmail, getmail, retchmail, dovecot 등 4 05 8.1 Email 서비스의 구성 요소 • 메일 송수신 과정 5 05 8.2 메일 서버 구축 • <실습 8-1> Fedora 20 서버 설치 – GUI 환경에서 메일서버를 설치 할 것이며 “Minimal Install” 모드 에서 실습을 원하는 경우 교재 324 ~367페이지 참조 6 05 8.2 메일 서버 구축 • 실습환경 예시 1 7 05 8.2 메일 서버 구축 • 실습환경 예시 2 8 05 8.2 메일 서버 구축 • 실습환경 예시 3 9 05 8.2 메일 서버 구축 • 실습환경 예시 4 1 0 05 8.2 메일 서버 구축 • <실습 8-2> yhkim.com DNS 서버 설치 – “실습환경 예시 4” 에서 구축(가상컴퓨터 램 용량을 적절히 조절) – DNS/MAIL Server 1 • yhkim.com 도메인 설정 – DNS/MAIL Server 2 • yh.com 도메인 설정 11 05 8.2 메일 서버 구축 • yhkim.com DNS 구축 – yum list bind – yum -y install bind.i686 – vi /etc/named.conf • listen-on port 53 { any; }; • allow-query { any; }; • recursion no; • zone “yhkim.com” IN { – type master; – file “yhkim.com.zone”; – allow-update {none;}; • }; 12 05 8.2 메일 서버 구축 • cd /var/named/ • ls • cp named.empty yhkim.com.zone • vi yhkim.com.zone – $TTL 3H – @ IN SOA @ root.
    [Show full text]
  • Tg-Olivera.Pdf
    Universidad de la República Oriental del Uruguay Facultad de Ingeniería Carrera Ingeniería en Computación Sistema MailDB Integración de ee----mailmail y bases de datos Integrantes Elohim Olivera Marcelo Rodríguez Responsables Ing. Felipe Zipitría Ing. Alejandro Blanco Proyecto de grado Abril 2005 Resumen Este trabajo se basa en el estudio de formatos de almacenamientos de correo electrónico (e-mail). La principal motivación de este estudio es la sobrecarga de procesamiento que sufren los servidores de e-mails al trabajar con casillas (mailboxes) de gran tamaño. Por otro lado, es indudable el avance y potencia que han desarrollado las bases de datos, en consecuencia surgen naturalmente preguntas como: • ¿Alguna de las soluciones de almacenamiento existentes está aprovechando ese conocimiento? • ¿Se obtienen ventajas sobre los otros formatos de almacenamiento al utilizar bases de datos? En la primera parte del trabajo, se estudian los formatos y tecnologías más comúnmente utilizadas hoy en día para el almacenamiento de e-mails. Mediante un estudio cuantitativo se analiza que impacto tiene en el desempeño de los servicios de e-mails, la utilización de cada formato. En busca de mejoras en la calidad de los servicios, se analiza y diseña una API (Application Programming Interface, traducido del inglés: Interfaz de Programación de Aplicaciones) que se encarga de brindar las herramientas necesarias para trabajar con e-mails almacenados en una base de datos. Se desarrolla un prototipo de esta API y se la integra a un servidor de e-mails. Por último, se compara el desempeño de los servicios de e-mail utilizando la API con los datos obtenidos de servicios que utilizan otro tipo de formatos para almacenar e-mails.
    [Show full text]
  • Bladecenter, Linux, and Open Source Blueprint for E-Business on Demand
    Front cover IBM Eserver BladeCenter, Linux, and Open Source Blueprint for e-business on demand Discover open source projects to reduce cost and improve reliability Install and configure Linux and critical open source network services Learn best practices to implement reliable services George Dolbier Peter Bogdanovic Dominique Cimafranca Yessong Johng Rufus Credle Jr. ibm.com/redbooks International Technical Support Organization IBM ^ BladeCenter, Linux, and Open Source: Blueprint for e-business on demand July 2003 SG24-7034-00 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (July 2003) This edition applies to Red Hat Advanced Server 2.1. © Copyright International Business Machines Corporation 2003. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix The team that wrote this redbook. ix Become a published author . xi Comments welcome. xi Chapter 1. About the book: Blueprint for building an e-business application for BladeCenter. 1 1.1 Building an e-business infrastructure . 2 1.1.1 Materials . 2 1.1.2 Objectives . 3 1.2 IBM eServer™ BladeCenter . 3 1.3 FAStT SAN storage. 3 1.4 BladeCenter business value . 4 1.5 Linux business value. 4 1.6 Open source business value. 4 1.7 Other references . 5 Chapter 2. Architecture: Solution overview . 7 2.1 Open source e-business infrastructure a modular approach . 8 2.2 All construction projects start with a pattern . 8 2.2.1 Industry standard e-business pattern: A three-tier infrastructure .
    [Show full text]
  • Software Architecture 10. Remote Terminal and Electric Mail
    1 SOFTWARE ARCHITECTURE 10. REMOTE TERMINAL AND ELECTRIC MAIL Tatsuya Hagino [email protected] lecture URL https://vu5.sfc.keio.ac.jp/slide/ 2 Terminal to Use Host Computer • Before personal computer age • Connect a terminal to a host computer with a serial line or a telephone line. • A terminal is a kind of type writer but key inputs go to the serial line and characters received from the serial line are printed. • Character terminal, graphical terminal, etc. input serial line output terminal host computer • Personal computer age • PC terminal emulator • Connected with a serial line or a telephone line through a modem. • Internet age • Virtual terminal emulator • Use Internet to connect to a remote computer. 3 Terminal Connection in UNIX Host • First, `getty' program waits for each line for a new connection init from a terminal. • getty = get tty getty getty getty • Hand to a `login' program does user authentication by asking a user name login user name and a password. password • Invoke a shell • The shell will handle all the execute csh interaction from then on. commands 4 Telnet Protocol remote terminal • Implement a virtual terminal for Internet computer port 23 • Use internet instead of a serial line. • TCP connection (with session and reliability) • port 23 • Simple protocol • All the characters input from a terminal are sent to the remote computer. • All the output form the remote computer are output to the terminal. • Replace the serial line, but no authentication of user is handled. • Options are negotiated between the terminal
    [Show full text]
  • Praca Dyplomowa In»Ynierska
    Politechnika Warszawska Rok akademicki Wydziaª Elektroniki i Technik Informacyjnych 2014/2015 Instytut Informatyki Praca Dyplomowa In»ynierska Wojciech Szymski System zarz¡dzania przestrzeni¡ adresów e-mail Opiekun pracy: prof. nzw. dr hab. in». Piotr Gawrysiak Ocena pracy: . ....................................... Data i podpis Przewodnicz¡cego Komisji Egzaminu Dyplomowego Kierunek: Informatyka Specjalno±¢: In»ynieria Systemów Informatycznych Data urodzenia: 13 wrze±nia 1991 Data rozpocz¦cia studiów: 1 pa¹dziernika 2010 yciorys Urodziªem si¦ 13 wrze±nia 1991 roku w Warszawie. W latach 2007-2010 ucz¦szczaªem do VIII Liceum Ogólnoksztaªc¡cego im. Wªadysªawa IV w Warszawie. W roku 2010 uko«czyªem szkoª¦ ±redni¡ oraz zdaªem matur¦. W pa¹dzierniku 2010 roku rozpocz¡ªem studia stacjonarne pierwszego stopnia na Wydziale Elektroniki i Technik Informacyjnych na kierunku Informatyka. ................................. podpis studenta Egzamin dyplomowy Zªo»yª egzamin dyplomowy w dn. Z wynikiem . Ogólny wynik studiów . Dodatkowe wnioski i uwagi Komisji . .................................................................................. 1 Streszczenie Przedmiotem pracy byªo zaprojektowanie oraz zaimplementowanie systemu e-mailowego. Przedstawiono dost¦pne na rynku rozwi¡zania oraz wskazano ich zalety i wady. Pozwoliªo to na zdeniowanie wymaga« sta- wianych przed systemem. Opisano wykorzystane protokoªy oraz architektur¦ i szczegóªy implementacyjne systemu. Jako efekt pracy powstaª system umo»liwiaj¡cy proste zarz¡dzanie przestrzeni¡ adresów e-mail w obr¦bie wªasnej domeny. Sªowa kluczowe: e-mail, zarz¡dzanie przestrzeni¡ adresow¡, ltrowanie wia- domo±ci, ochrona przed spamem E-mail address space management system The subject of the thesis was to design and create an e-mail system. Review of available solutions was introduced with their pros and cons pointed out. This allowed to dene the requirements for the system.
    [Show full text]
  • Servidor De Correo En GNU/Linux Con Postfix + Mysql + Courier IMAP +
    Servidor de correo en GNU/Linux con Postfix + MySQL + Courier IMAP + Courier POP + Squirrelmail + Amavis + Clamav + Spamassassin Alberto Molina Coballes <[email protected]> Jose´ Domingo Munoz˜ Rodr´ıguez <[email protected]> IES Gonzalo Nazareno. Dos Hermanas (Sevilla) 24 de septiembre de 2006 Resumen En este documento se describe la instalacion´ y configuracion´ de un servi- dor de correo postfix, con usuarios almacenados en una base de datos, posi- bilidad de acceder a los mensajes a traves´ de los protocolos POP e IMAP y con un sistema de filtrado de mensajes para prevenir la difusion´ de mensa- jes de SPAM y virus. Esta documentacion´ se elaboro´ para el curso M´aquinas virtuales para la puesta en marcha de un portal educativo organizado por el CEP de Sevilla en Septiembre de 2006. c Alberto Molina Coballes y Jose´ Domingo Munoz˜ Rodr´ıguez. Algunos De- rechos reservados. Esta obra esta´ bajo una licencia Attribution-ShareAlike 2.5 de Creative Com- mons. Para ver una copia de esta licencia, visite: http://creativecommons.org/licenses/by-sa/2.5/ 1 1. Introducci´on El correo electronico´ se trata sin duda de una de las aplicaciones mas´ utiliza- das en Internet. La mayor´ıa de los usuarios de Internet estan´ acostumbrados a terminos´ como servidor smtp, servidor pop, nombre de usuario, etc. Sin embargo, existe la idea de que la instalacion´ y configuracion´ de un servi- dor de correo electronico´ es una tarea propia solo´ de proveedores de servicios de Internet (ISP). Esto en parte se debe a la relativa complejidad de la configuracion´ de un servidor de correo —sobretodo si la comparamos con configuraciones tan sencillas como las de un servidor web como apache o un servidor ftp—.
    [Show full text]
  • A High Performance and Low Cost Cluster-Based E-Mail System
    A High Performance and Low Cost Cluster-based E-mail System Woo-Chul Jeun1, Yangsuk Kee1, Soonhoi Ha1, Jin-Soo Kim2 1 Electrical Engineering and Computer Science Dept. Seoul National University, San 56-1, Sinlim-dong, Gwanak-gu, Seoul 151-744, Korea {wcjeun, enigma, sha} @ iris.snu.ac.kr Tel: +82-2-880-7292, Fax: +82-2-886-7589 2 Division of Computer Science, KAIST, Daejeon 305-701, Korea jinsoo @ cs.kaist.ac.kr Tel: +82-42-869-3545, Fax: +82-42-869-3510 Abstract. A large-scale e-mail service provider requests a highly scalable and available e-mail system to accommodate the increasing volume of e-mail traffic as well as the increasing number of e-mail users. To reduce the system devel- opment and maintenance cost, it is requested to make the system modular using off-the-shelf components. In this paper, we propose a cluster-based e-mail sys- tem architecture that satisfies both the high performance requirement of scal- ability and availability, and the low cost requirement at the same time. We adopt the internal structure of a typical Internet mail system for a single server, which is called the MTA-MDA structure, to the proposed cluster system for the latter requirement. We have implemented four different system configurations with the MTA-MDA structure and compare their performances. Experimental results prove that the proposed e-mail system achieves all the design objectives. 1 Introduction The growth of the Internet has led to explosions in volumes of e-mail traffic and in number of the users of e-mail service.
    [Show full text]