BACHELOR THESIS Jan Kundrát IMAP E-Mail Client

Total Page:16

File Type:pdf, Size:1020Kb

BACHELOR THESIS Jan Kundrát IMAP E-Mail Client Charles University in Prague Faculty of Mathematics and Physics BACHELOR THESIS Jan Kundr´at IMAP E-mail Client Department of Software Engineering Supervisor: Mgr. Vlastimil Babka Study Program: Computer Science, Programming 2009 I’d like to thank my supervisor, Mgr. Vlastimil Babka, for his numerous advices during the writing of this thesis, Ms. Anna Adamcov´a for her great patience and support, and my parents for supporting my studies. I hereby declare that I wrote this thesis myself using the referenced sources only. I also agree with lending and publishing of this thesis. Prague, May 29, 2009 Jan Kundr´at 2 Contents 1 Introduction 7 1.1 Motivation............................ 7 1.2 Structureofthethesis ..................... 8 2 IMAP and Related Technologies 9 2.1 BasicConcepts ......................... 9 2.2 IMAP-specificAttributes. 10 2.3 MIME .............................. 12 2.3.1 MessageasaContainer. 12 2.3.2 International Characters in Messages . 13 2.3.3 MIMESupportinIMAP. 13 2.4 IMAPProtocolFlow ...................... 14 2.4.1 Commandsandresponses . 14 2.4.2 Mailbox Synchronization . 15 2.4.3 ChangestoMailbox . 16 2.4.4 Fetching and Manipulating Messages . 17 2.4.5 Queries Against Other Mailboxes . 18 2.4.6 Searching, Sorting and Threading . 18 2.4.7 Manipulating Mailboxes . 18 2.4.8 Sessiontermination. 19 2.4.9 IMAPExtensions. 19 2.5 OtherMethodsofMailStoreAccess . 20 2.5.1 POP3 .......................... 20 2.5.2 MAPI .......................... 20 2.5.3 Webmail......................... 20 2.5.4 IMAPCriticism..................... 21 3 3 Trojita Design 23 3.1 Overview............................. 23 3.2 Model-ViewArchitecture. 25 3.3 Parser .............................. 26 3.3.1 Low-levelParser . .. .. 26 3.3.2 Parser .......................... 27 3.4 Cache .............................. 28 3.5 Streams ............................. 28 3.6 ModelinDetail ......................... 29 3.6.1 TheTree......................... 29 3.6.2 ProxyModels ...................... 32 3.6.3 Offline and Expensive Network Mode . 33 3.7 MessageView .......................... 33 3.7.1 NetworkManager. 34 3.7.2 WidgetFactory ..................... 35 3.7.3 HTMLMail....................... 36 3.8 GUI ............................... 36 4 Other IMAP Implementations 38 4.1 Alpine2.0 ............................ 38 4.2 Mutt1.5.19 ........................... 39 4.3 KMail3.5 ............................ 39 4.4 MozillaThunderbird2.0 . 40 4.5 Mailody ............................. 41 4.6 OutlookExpress ........................ 42 4.7 WindowsLiveMail ....................... 43 4.8 Trojita.............................. 43 5 User’s Guide 45 5.1 AboutTrojita.......................... 45 5.2 Installation ........................... 45 5.2.1 Prerequisites. .. .. 45 5.2.2 Obtainingsourcecode . 46 5.2.3 Installing ........................ 46 5.3 UsingTrojita .......................... 47 5.3.1 Configuration ...................... 47 5.3.2 Basicusage ....................... 48 5.3.3 Managing Messages and Mailboxes . 49 4 5.3.4 MessageComposition. 50 5.3.5 CheckingMail...................... 50 5.4 Advancedusage......................... 50 5.4.1 PartialMessageFetching . 50 5.4.2 OfflineMode ...................... 50 5.4.3 ExpensiveNetwork . 50 5.4.4 OnlineMode ...................... 51 5.4.5 LocalCache....................... 51 5.4.6 FullTreeView ..................... 52 6 Conclusion 53 Bibliography 55 A Contents of the CD 59 5 N´azev pr´ace: IMAP E-mail Client Autor: Jan Kundr´at Katedra (´ustav): Katedra softwarov´eho inˇzen´yrstv´ı Vedouc´ıbakal´aˇrsk´epr´ace: Mgr. Vlastimil Babka E-mail vedouc´ıho: Vlastimil.Babka@mff.cuni.cz Abstrakt: Pˇredloˇzen´apr´ace popisuje implementaci pokroˇcil´eho klienta pro pr´aci s poˇstou pomoc´ı protokolu IMAP. Hlavn´ım zamˇeˇren´ım je podpora relevantn´ıch standard˚us d˚urazem na efektivn´ı implementaci; vyuˇz´ıv´ase pokroˇcil´ych vlastnost´ı IMAPu, jako napˇr´ıklad IDLE notifikac´ı, parsov´an´ı zpr´av na stranˇeserveru ˇci lok´aln´ıho ukl´ad´an´ıe-mail˚us moˇznost´ıpr´ace of- fline. Spojen´ıs IMAP serverem je realizov´ano protokolem TCP s volitelnou moˇznost´ıTLS ˇsifrov´an´ıˇci pˇres lok´alnˇebeˇz´ıc´ı proces. Projekt umoˇzˇnuje psan´ı a odes´ıl´an´ıjednoduch´ych mail˚u, podporov´ano je odes´ıl´an´ıpomoc´ıprotokolu SMTP a sendmailem. C´ılov´aplatforma je framework Qt na Linuxu, avˇsak aplikace je portovateln´ai na jin´eplatformy. Kl´ıˇcov´aslova: IMAP, e-mail, MIME, Qt, SMTP Title: IMAP E-mail Client Author: Jan Kundr´at Department: Department of Software Engineering Supervisor: Mgr. Vlastimil Babka Supervisor’s e-mail address: Vlastimil.Babka@mff.cuni.cz Abstract: This thesis describes the implementation of an advanced IMAP e-mail client, Trojita. Focusing on standards compliance, the client sup- ports a wide range of IMAP features crucial for an efficient implementation such as IDLE notifications, server-side message parsing and caching of re- trieved body data for offline operation. Connecting to the IMAP server is supported over TCP sockets, optionally secured via the TLS encryption, as well as through a local process. Basic message composition and sending via both SMTP and a local sendmail instance is supported. The target platform is the Qt framework on Linux, but the application is reasonably portable. Keywords: IMAP, e-mail, MIME, Qt, SMTP 6 Chapter 1 Introduction Although being surpassed in popularity by other technologies like the World Wide Web and peer-to-peer applications, the electronic mail is still one of the few services that an average user can name when talking about the Internet. There are many ways how to send and receive e-mail, some of them being more popular than the others. In this thesis, we try to resurrect the older approach to reading e-mail, that is, using an standalone application. In the recent years, the improvements in the field of web browsers and related technologies allowed rapid development of new features that were not conceivable just five years ago. Using these new functions, the popular- ity of web-based e-mail readers grew accordingly. However, using a proper standalone application has numerous benefits from being able to work when not connected to the Internet to providing a truly instant feedback, a feature that is still somewhat missing from most of the web applications. Managing e-mail over a standardized protocol also avoids vendor lock-in, a highly dan- gerous phenomenon associated with using proprietary messaging solutions. To date, the Internet Message Access Protocol [1] (or IMAP) is the only such protocol. 1.1 Motivation Implementing an IMAP client is far from trivial. While there are certainly numerous stable and widely-used Mail User Agents on the market, none of them fulfills all the expectations of reasonable performance and efficiency. Indeed, most of these applications started as MUAs speaking the POP3 protocol only, adding support for IMAP later on. Typically, this support 7 was implemented long since the initial design phase of the product was completed, resulting in suboptimal design choices [2]. Therefore, we believe there is still a place on the market for a stable, highly performing IMAP e-mail application. 1.2 Structure of the thesis In the following chapter, we provide a gentle introduction to the world of IMAP and related standards such as MIME. Chapter 3 explains some of the design choices made during the development process of Trojita, as well as elaborates on the internal application architecture and structure. An overview of other IMAP implementations on the market is provided in chap- ter 4, including a comparison about how well they operate when compared to Trojita. The User’s Guide is available in chapter 5. Finally, the whole thesis is concluded by a wrap-up providing an overview of what we implemented and how the result is usable. 8 Chapter 2 IMAP and Related Technologies Electronic mail, or a SMTP-mail, is a public service suitable for automated message exchange among connected entities. Interoperability is guaranteed by several Internet standards, usually codified in the form of RFC docu- ments. Subject to these standards are various protocols specifying the rules of what entities can communicate to each other as well as definition of the format of all transmitted messages. In this section, we provide a gentle in- troduction to the numerous standards which deal with this highly complex topic. 2.1 Basic Concepts An email message, or a RFC-8221 message, consists of three parts: Envelope, Header and Body. The envelope is the only relevant part for mail exchange among Internet hosts; it includes basic information like addresses of the sender and recipient. A header provides more detailed metadata about the message, from human-readable sender addresses and message route traces to user-defined fields. Some pieces of this information are used when the original delivery fails for some reason, like the Return-Path header. The header also serves as a basis for an IMAP envelope data which is explained later in chapter 2.2. Finally, a message body is what an average user typically 1As defined by the RFC 822 standard and subsequently modified by RFC 2822 [3] and others 9 refers to as “the e-mail”. It might contain just a plain US-ASCII text, an HTML message with embedded images or it could be a recursively defined entity with rich tree structure. An IMAP server is a host in the Internet which provides access to local mail store via the standard protocol, IMAP4rev1 in this case. The IMAP server might be located in an employer’s data center or on the user’s laptop, for example. An MTA2 or an SMTP Server is an Internet host whose purpose is de- livery of the RFC 2822 mail. MTAs in the Internet communicate with each other, determining routing information from MX-records3 in the DNS. As a common practice nowadays, these servers also accept outgoing e-mail from their own users, provided the connection is properly authenticated, either by simple fact that it originates from a trusted network or that the user has provided her credentials, typically as a user name and password combination or in the form of an X.509 certificate. A Mailbox or a Mail Folder is a place on the IMAP server where the messages are logically stored.
Recommended publications
  • Oldschool E-Mail Setup Eine Freakshow
    Oldschool E-mail Setup Eine Freakshow [email protected] Chemnitzer Linuxtage, 2016 (Screenshot GMX vor >15 Jahren: Waybackmachine zu www.gmx.net) (Screenshot GMX heute) (Screenshot Gmail heute) Lösungen? ● Claws ● Mutt ● Eudora ● Netscape Navigator ● Evolution ● Opera M2 ● GMX ● Outlook ● Gnus ● SquirrelMail ● Hotmail ● The Bat! ● Hushmail ● Thunderbird ● KMail ● … Flußgrafik Email Netz MTA MRA MDA MUA MSA MTA Netz Hipster! ● KISS ● YAGNI ● DRY ● NIH ● Divide And Conquer ● Everything is a file ● No vendor lock-in ● Mißtraue Autoritäten – fördere Dezentralisierung Netz Netz Emails Client, den ich Remote verwenden kann Leicht erweiterbar Emails lokal Filter Offenes Format Adressen Netz Netz Abholen Transportformat? Pull Subject 1 Email = 1 File Keine Spuren X-List-ID Mit Hierarchien am Server Beliebige Einfaches Suchen Header Verlässliches Suchen Verarbeitung mit Unix Tools Client, den ich Remote verwenden kann Leicht erweiterbar Emails lokal Filter Offenes Format Adressen Netz Netz Abholen Transportformat? Pull Subject 1 Email = 1 File Keine Spuren X-List-ID Mit Hierarchien am Server Beliebige Einfaches Suchen Header Verlässliches Suchen Verarbeitung mit Unix Tools mbox Maildir mh Client, den ich Remote verwenden kann Leicht erweiterbar Emails lokal Filter Offenes Format Adressen Netz Netz Abholen Transportformat? Pull Subject 1 Email = 1 File Keine Spuren X-List-ID Mit Hierarchien am Server Beliebige Einfaches Suchen Header Verlässliches Suchen Verarbeitung mit Unix Tools mbox Maildir mh tmp 1439306571.1269_0.elvis ~/Post/Technik/Wikitech new 1448267819.5940_0.spencer ... 1457079728.2000_0.spencer:2, cur 1456839383.9873_0.nepomuk:2,SR 1457166567.23654_0.spencer:2,S ... Client, den ich Remote verwenden kann Leicht erweiterbar Filter Adressen Netz Netz Abholen Pull Subject Maildir Keine Spuren X-List-ID am Server Beliebige Header Client, den ich Remote verwenden kann Leicht erweiterbar Filter Adressen Netz Netz Abholen Pull Subject Maildir Keine Spuren X-List-ID am Server Beliebige Header fetchmail getmail mpop ..
    [Show full text]
  • Implementation of Proactive Spam Fighting Te Niques
    Implementation of Proactive Spam Fighting Teniques Masterarbeit von Martin Gräßlin Rupret-Karls-Universität Heidelberg Betreuer: Prof. Dr. Gerhard Reinelt Prof. Dr. Felix Freiling 03. März 2010 Ehrenwörtlie Erklärung I versiere, dass i diese Masterarbeit selbstständig verfasst, nur die angegebenen ellen und Hilfsmiel verwendet und die Grundsätze und Empfehlungen „Verantwortung in der Wissensa“ der Universität Heidelberg beatet habe. Ort, Datum Martin Gräßlin Abstract One of the biggest allenges in global communication is to overcome the problem of unwanted emails, commonly referred to as spam. In the last years many approaes to reduce the number of spam emails have been proposed. Most of them have in common that the end-user is still required to verify the filtering results. ese approaes are reactive: before mails can be classified as spam in a reliable way, a set of similar mails have to be received. Spam fighting has to become proactive. Unwanted mails have to be bloed before they are delivered to the end-user’s mailbox. In this thesis the implementation of two proactive spam fighting teniques is discussed. e first concept, called Mail-Shake, introduces an authentication step before a sender is allowed to send emails to a new contact. Computers are unable to authenticate themselves and so all spam messages are automatically bloed. e development of this concept is discussed in this thesis. e second concept, called Spam Templates, is motivated by the fact that spam messages are generated from a common template. If we gain access to the template we are able to identify spam messages by mating the message against the template.
    [Show full text]
  • Getting Started with Eudora 5.1 for Windows 95/98/ME/NT/2000 Author Teresa Sakata
    WIN9X003 July 2003 Getting Started with Eudora 5.1 For Windows 95/98/ME/NT/2000 Author Teresa Sakata Introduction ..............................................................................................................................................................1 POP and IMAP Servers ............................................................................................................................................2 Requirements ............................................................................................................................................................2 Changes From Version 4.3.x ....................................................................................................................................3 Issues ........................................................................................................................................................................3 Where do I get Eudora? ............................................................................................................................................4 Getting Started..........................................................................................................................................................4 Installation ................................................................................................................................................................4 Configuring Eudora ..................................................................................................................................................5
    [Show full text]
  • GNU Guix Cookbook Tutorials and Examples for Using the GNU Guix Functional Package Manager
    GNU Guix Cookbook Tutorials and examples for using the GNU Guix Functional Package Manager The GNU Guix Developers Copyright c 2019 Ricardo Wurmus Copyright c 2019 Efraim Flashner Copyright c 2019 Pierre Neidhardt Copyright c 2020 Oleg Pykhalov Copyright c 2020 Matthew Brooks Copyright c 2020 Marcin Karpezo Copyright c 2020 Brice Waegeneire Copyright c 2020 Andr´eBatista Copyright c 2020 Christine Lemmer-Webber Copyright c 2021 Joshua Branson Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". i Table of Contents GNU Guix Cookbook ::::::::::::::::::::::::::::::: 1 1 Scheme tutorials ::::::::::::::::::::::::::::::::: 2 1.1 A Scheme Crash Course :::::::::::::::::::::::::::::::::::::::: 2 2 Packaging :::::::::::::::::::::::::::::::::::::::: 5 2.1 Packaging Tutorial:::::::::::::::::::::::::::::::::::::::::::::: 5 2.1.1 A \Hello World" package :::::::::::::::::::::::::::::::::: 5 2.1.2 Setup:::::::::::::::::::::::::::::::::::::::::::::::::::::: 8 2.1.2.1 Local file ::::::::::::::::::::::::::::::::::::::::::::: 8 2.1.2.2 `GUIX_PACKAGE_PATH' ::::::::::::::::::::::::::::::::: 9 2.1.2.3 Guix channels ::::::::::::::::::::::::::::::::::::::: 10 2.1.2.4 Direct checkout hacking:::::::::::::::::::::::::::::: 10 2.1.3 Extended example ::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • Proceedings Template
    0 - IMAP in 90 Days or How to Migrate 25,000 Users to IMAP in Three Months Jay Graham Computing Services and Systems Development University of Pittsburgh 419 South Bellefield Avenue Pittsburgh, PA 15217 (412) 624-5244 [email protected] ABSTRACT Pittsburgh campus. Extensive use of user logs, forwarding data and distribution was critical to the process. The final phase The University of Pittsburgh began the Internet Message Access involved the migration of 25,000 users from VMS Mail, Unix Protocol (IMAP) Project in the spring of 1997 as an evaluation Pine and POP mail to the new environment by April 1, 2000. project investigating the replacement options for the legacy e-mail systems and a POP3 service. The project was initially divided into two phases---Phase 1 to deploy an IMAP server for campus- Keywords wide use and Phase 2 to identify and provide a reliable, high quality, enterprise-wide IMAP client. A sub-group of the IMAP IMAP, e-mail, POP, legacy, client-server project team was formed to identify requirements and evaluate clients. Cyrusoft International's Mulberry was found to meet the ever changing requirements of the campus computing labs and 1. INTRODUCTION have sufficient features and functionality that users would be compelled to switch from their legacy clients to the new Electronic mail has become a primary tool used by many large environment. organizations to enhance daily communication. E-mail between managers, workers, customers, students, teachers or parents often A critical third phase was added to the IMAP project which serves as a more efficient, cost effective and convenient form of required a phase-out of the legacy e-mail systems by April 1, 2000 interaction.
    [Show full text]
  • Sysinfotools Maildir Converter
    SysInfoTools MailDir Converter SysInfoTools MailDir Converter Table of Contents 1. SysInfotools MailDir Converter .................................................................................. 2 2. Overview ................................................................................................................... 2 3. Getting Started .......................................................................................................... 3 Installation procedure ............................................................................................... 4 4. Order and Activation .................................................................................................. 4 How to Order ............................................................................................................ 4 How to Activate ......................................................................................................... 4 5. Using SysInfoTools MailDir Converter ....................................................................... 5 Understanding the User Interface .............................................................................. 6 Button Used .............................................................................................................. 6 How to use MailDir Converter Tool ............................................................................ 7 6. Uninstall the Software .............................................................................................. 13 7. Legal Notice ...........................................................................................................
    [Show full text]
  • Metadata Track Akonadi the Independent Solution for PIM Data
    Akonadi – The independent solution for PIM GCDS 2009 data Metadata track Akonadi the independent solution for PIM data Will Stephenson Will Stephenson Akonadi – The independent solution for PIM GCDS 2009 data Akonadi Topics Akona-what? Design Overview What we give you What you give us Will Stephenson Akonadi – The independent solution for PIM GCDS 2009 data Akonadi The story so far Monolithic apps Own data storage Limited if any external interfaces E-D-S Data storage service Limited range of types supported Will Stephenson Akonadi – The independent solution for PIM GCDS 2009 data Why? Limitations of KDE3 KResource framework limitations: Data is not shared Designed for synchronous access Hard to extend to other data types Basically no shared common code KMail limitations: Only limited backend abstraction Designed for small amounts of local data Will Stephenson Akonadi – The independent solution for PIM GCDS 2009 data Scalability with KDE 3 |Data| = small Contact applet KAddressBook l l KMail Kopete Will Stephenson Akonadi – The independent solution for PIM GCDS 2009 data Scalability in KDE 3 |Data| = large Contact applet KAddressBook l l KMail Kopete Will Stephenson Akonadi – The independent solution for PIM GCDS 2009 data Why? Goals As much as possible shared, type independent functionality Easy to extend to new data types Unified API to access PIM data, independent of the actual data source Scalability Will Stephenson Akonadi – The independent solution for PIM GCDS 2009 data Why? Goals One synchronization point for mobile devices Reliable,
    [Show full text]
  • Designing a User Interface for the Innovative E-Mail Client Semester Thesis
    Designing a User Interface for the Innovative E-mail Client Semester Thesis Student: Alexandra Burns Supervising Professor: Prof. Bertrand Meyer Supervising Assistants: Stephanie Balzer, Joseph N. Ruskiewicz December 2005 - April 2006 1 Abstract Email Clients have become a crucial application, both in business and for per- sonal use. The term information overload refers to the time consuming issue of keeping up with large amounts of incoming and stored email. Users face this problem on a daily basis and therefore benefit from an email client that allows them to efficiently search, display and store their email. The goal of this thesis is to build a graphical user interface for the innovative email client developed in a previous master thesis. It also explores the possibilities of designing a user interface outside of the business rules that apply for commercial solutions. 1 Contents 1 Introduction 4 2 Existing Work 6 2.1 ReMail ................................. 6 2.1.1 Methods ............................ 6 2.1.2 Problems Identified ...................... 7 2.1.3 Proposed Solutions ...................... 7 2.1.4 Assessment .......................... 8 2.2 Inner Circle .............................. 8 2.2.1 Methods ............................ 8 2.2.2 Problems Identified ...................... 9 2.2.3 Proposed Solutions ...................... 9 2.2.4 Assessment .......................... 10 2.3 TaskMaster .............................. 10 2.3.1 Methods ............................ 10 2.3.2 Problems Identified ...................... 11 2.3.3 Proposed Solution ...................... 11 2.3.4 Assessment .......................... 12 2.4 Email Overload ............................ 12 2.4.1 Methods ............................ 12 2.4.2 Problems Identified ...................... 13 2.4.3 Proposed Solutions ...................... 13 2.4.4 Assessment .......................... 14 3 Existing Solutions 16 3.1 Existing Email Clients .......................
    [Show full text]
  • Mathematics Department's New Email Service
    Mathematics Department’s New Email Service The department’s new email service employs the widely-used IMAP email protocol to allow you to read and organize your email. You may use the Math web-based email service, http://webmail.math.vt.edu, and/or email software on Unix systems, such as elm, mutt or pine. The IMAP protocol stores your email on a department server computer that daily saves your email and files to backup tapes. The server does not have an infinite supply of disk storage, so you will need to periodically delete email you no longer need or transfer it to your PC or Mac for archival.1 You may use the webmail service in conjunction with other email applications. Elm Elm is no longer supported. You may use mutt which is very similar. Pine Before running pine, you must update your existing pine settings with this command, /local/calvin/bin/updatepinerc PID where PID is your Virginia Tech PID. This will create a new .pinerc file in your home directory containing settings for using the new Math Email system. A copy of your original .pinerc file is named .pinerc-pre4.64 in your home directory. If you have previously used an older version of pine, any of your old settings that were not migrated to the new .pinerc will be listed. These are saved in a file named pinerc- settings. If you want to continue using any old settings, you must edit .pinerc to include them. Pine groups mailboxes into collections. One collection will be any mailboxes on the mail server.
    [Show full text]
  • Postfix Catch All and Mutt
    Postfix Catch All and Mutt End goal: having postfix saving all of the emails for a domain to a single “mailbox” in maildir format, and being able to send email using mutt (or similar). Specifics to my setup I'm not going to open port 25 on my server, I'm going through Net7's spam filter, which will then forward to my server on port 8025. So I need to open port 8025. The rule was already there for port 25, I just need to edit the thing. Make Postfix listen to another port There is always the plan of using iptables to redirect the traffic. You can do it in Postfix as well. Open master.cf and find this line: smtp inet n - - - - smtpd The smtp word up front is actually a port. You can replace it with this line: 8025 inet n - - - - smtpd If you restart Postfix and check with netstat it should be listening to another port. Setting up Maildir delivery By default Postfix will output emails to a single file in /var/mail/. I'd rather have the Maildir format which separates emails into different files that I can individually move and/or delete. I'm going off the rails here trying out things. Looks like we're going to need these configuration options in main.cf: home_mailbox = Maildir/ mailbox_command = Make sure mailbox_command isn't set somewhere else in the file. Reload Postfix. We should be able to test that this is working using a known user on the system. You can telnet-test like so: EHLO test MAIL FROM:<[email protected]> RCPT TO:<william> DATA Test.
    [Show full text]
  • Snuffleupagus Documentation
    Snuffleupagus Documentation Release stable Sebastien Blot & Julien Voisin Aug 29, 2021 Contents 1 Documentation 3 1.1 Features..................................................3 1.2 Installation................................................ 11 1.3 Configuration............................................... 14 1.4 Download................................................. 22 1.5 Changelog................................................ 23 1.6 FAQ.................................................... 29 1.7 Propaganda................................................ 33 1.8 Cookies.................................................. 35 2 Greetings 39 i ii Snuffleupagus Documentation, Release stable Snuffleupagus is a PHP7+ and PHP8+ module designed to drastically raise the cost of attacks against websites. This is achieved by killing entire bug classes and providing a powerful virtual-patching system, allowing the administrator to fix specific vulnerabilities without having to touch the PHP code. Contents 1 Snuffleupagus Documentation, Release stable 2 Contents CHAPTER 1 Documentation 1.1 Features Snuffleupagus has a lot of features that can be divided in two main categories: bug-classes killers and virtual-patching. The first category provides primitives to kill various bug families (like arbitrary code execution via unserialize for example) or raise the cost of exploitation. The second category is a highly configurable system to patch functions in php itself. 1.1.1 Bug classes killed or mitigated system injections The system function executes an external
    [Show full text]
  • Visualization of Client-Side Web Browsing and Email Activity
    Calhoun: The NPS Institutional Archive Theses and Dissertations Thesis Collection 2009-06 Visualization of client-side web browsing and email activity Roussas, Gregory. Monterey, California. Naval Postgraduate School http://hdl.handle.net/10945/4738 NAVAL POSTGRADUATE SCHOOL MONTEREY, CALIFORNIA THESIS VISUALIZATION OF CLIENT-SIDE WEB BROWSING AND EMAIL ACTIVITY by Gregory Roussas June 2009 Thesis Advisor: Cynthia E. Irvine Second Reader: Chris S. Eagle Approved for public release; distribution is unlimited THIS PAGE INTENTIONALLY LEFT BLANK ii Form Approved REPORT DOCUMENTATION PAGE OMB No. 0704–0188 The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704–0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202–4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 1. REPORT DATE (DD–MM–YYYY) 2. REPORT TYPE 3. DATES COVERED (From — To) 22–6–2009 Master’s Thesis 2007-09-21—2009-06-19 4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER 5b. GRANT NUMBER Visualization of Client-Side Web Browsing and Email Activity DUE 0414102 5c.
    [Show full text]