DOCSLIB.ORG

A Formal Approach Towards Assessing the Effectiveness of Anti-Spam Procedures

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Formal Approach Towards Assessing the Effectiveness of Anti-Spam Procedures A Formal Approach towards Assessing the Effectiveness of Anti-spam Procedures Guido Schryen Institute of Business Information Systems, RWTH Aachen University [email protected] Abstract heuristic, anti-spam approaches. A formal framework Spam e-mails have become a serious technological within which the modes of spam delivery, anti-spam and economic problem. So far we have been approaches, and their effectiveness can be reasonably able to resist spam e-mails and use the investigated, may encourage a shift in methodology Internet for regular communication by deploying and pave the way for new, holistic anti-spam complementary anti-spam approaches. However, if approaches. In Section 2 the Internet e-mail we are to avert the danger of losing the Internet e- infrastructure is modeled as a directed graph and a mail service as a valuable, free, and worldwide deterministic finite automaton and the appropriateness medium of open communication, anti-spam activities of the model is proved. In section 3 all possible should be performed more systematically than is done modes of sending (spam) e-mails are derived and in current, mainly heuristic, anti-spam approaches. A presented as regular expressions. These (technically- formal framework within which the modes of spam oriented) expressions are then grouped into categories delivery, anti-spam approaches, and their according to types of organization participating in e- effectiveness can be investigated, may encourage a mail delivery. The effectiveness of today’s most shift in methodology and pave the way for new, important anti-spam approaches is assessed in section holistic anti-spam approaches. 4 by matching them with the modes of spamming. This paper presents a model of the Internet e-mail Section 5 summarizes the results presented in this infrastructure as a directed graph and a deterministic manuscript and outlines future work. finite automaton, and draws on automata theory to formally derive the modes of spam delivery possible. 2. Model of the Internet e-mail Finally the effectiveness of anti-spam approaches in infrastructure terms of coverage of spamming modes is assessed. The Internet e-mail infrastructure can be modeled as a directed graph G which is defined in the first . 1. Introduction subsection. In the second subsection it is shown that all types of e-mail deliveries can be described with a Spam e-mails have become a serious technological set of (directed) paths in G. As each option to send e- and economic problem. So far we have been mails at the same time represents an option to send reasonably able to resist spam e-mails, although spam e-mails the set of spamming options and the set statistics show a proportion of spam higher than 60% of mailing options are regarded to be equal. [11, 12]. The availability of the Internet e-mail system for regular e-mail communication is currently 2.1 Definition ensured by complementary anti-spam approaches, mainly by blocking and filtering procedures. Since the Internet e-mail network infrastructure However, if we are to avert the danger of losing the which the graph is intended to represent is dynamic, it Internet e-mail service as a valuable, free, and is not meaningful to model each concrete e-mail node. worldwide medium of open communication, anti- The different types of Internet e-mail nodes on the spam activities should be performed more other hand are static, and it is these which can serve systematically than is done in current, mainly the purpose. An e-mail node is here defined as a software unit which is involved in the Internet e-mail extensions, also referred to as ESMTP, such as SMTP delivery process and works on the TCP/IP application Service Extension for Authentication (RFC 2554), layer. Consideration of software working exclusively Deliver By SMTP Service Extension (RFC 2852), on lower levels such as routers and bridges is beyond SMTP Service Extension for Returning Enhanced the scope of this work, as are options to send an e- Error (RFC 2034), and SMTP Service Extension for mail without any SMTP communication with an e- Secure SMTP over Transport Layer Security (RFC mail node of the recipient’s organization. However, 3207); see www.iana.org/assignments/mail- this does not seem to be an important restriction, as parameters for a list of SMTP service extensions. * almost all e-mail users receive their e-mails from a The set SMTP contains the set SMTP and all server that is (directly or indirectly) SMTP connected SMTP extensions specified for e-mail submission to the Internet. from a Mail User Agent (MUA) to an e-mail node Let G={V,E,c} be a directed graph with vertex set with an SMTP incoming interface. This e-mail node V and edge set E, and let c: E→L be a total function can be a Mail Transfer Agent (MTA) as specified in on E where L denotes a set of (protocol) labels. First RFC 2821 or a Message Submission Agent (MSA) as the structure of the graph is presented graphically (see specified in RFC 2476. With reference to the latter figure 1) and formally. Its semantics is then explained MTAinc can alternatively be denoted as in more detail. sendOrg inc The set of vertices can be depicted as the disjoint MSAsendOrg and MTArecOrg as MSArecOrg ,respectively. union of five vertex sets V1,…,V5. Each of these sets Port 587 is reserved for e-mail message submission. is attached to one of the organizational units However, while most e-mail clients and servers can participating in e-mail delivery: sender, sending be configured to use port 587 instead of 25, there are organization or e-mail (service) provider, Internet, cases where this is not possible or convenient. A site receiving organization, and recipient. In cases where may use port 25 even for message submission. Using the recipient does not use a receiving organization as an MSA numerous methods can be applied to ensure e-mail service provider (ESP) but runs his own e-mail that only authorized users can submit messages. receiving and processing environment the These methods include authenticated SMTP, IP organizational units receiving organization and address restrictions, secure IP, and prior Post Office recipient merge. This, however, does not affect the Protocol (POP) authentication, where clients are structure of the graph, which retains its general required to authenticate their identity before an SMTP validity. The set of vertices be V=V ∪…∪V with * 1 5 submission session (“SMTP after POP”). SMTP is V = {MTA , MUA ,OtherAgent } set of 1 send send send the union of three sets of protocols. The first contains vertices attached to sender, all Internet application protocols excepting SMTP*, inc set of V2 = {MTAsendOrg , MTAsendOrg ,WebServsendOrg } the second, all proprietary application protocols used vertices attached to sending organization, on the Internet: this inclusion takes tunneling procedures into account. The third set, since use of V3 = {SMTP − Relay,GWSMTP,B ,GWA,SMTP ,GWA,B } application protocols is not mandatory for the set of vertices attached to Internet, exchange of data in a network, are all Internet V = {MTAinc , MTA , MDA , 4 recOrg recOrg recOrg protocols on the transport and network layer of the MailServrecOrg ,WebServrecOrg } Department of Defense (DoD) model, such as TCP set of vertices attached to receiving organization, and and IP. MAP is the set of all e-mail access protocols set of vertices attached to used to transfer e-mails from the recipient’s e-mail V5 = {MUArecOrg } server to his MUA. Internet Message Access Protocol recipient. (IMAP) version 4 (RFC 1730) and POP version 3 The set of (protocol) labels be (RFC 1939) are here among the protocols most * * L = {SMTP, SMTP , SMTP , HTTP(S), INT, MAP}. deployed. The set HTTP(S) contains the protocols E and c are not defined formally here, but shown HTTP (RFC 2616) as well as its secure versions graphically in figure 1. “HTTP over SSL” [3] and “HTTP over TLS” Each vertex corresponds to a type of e-mail node. (RFC2818). Finally, the set INT denotes protocols An edge e=(v1,v2) with a label c(e) ∈ L attached and procedures for internal e-mail delivery, i. e. inside exists if and only if the Internet e-mail infrastructure the receiving organization, such as getting e-mails allows e-mail flow between the corresponding node from an internal MTA and storing them into the types; c(e) denotes the set of feasible protocols. users’ e-mail boxes. The set SMTP contains SMTP (as a protocol) extended by all IANA-registered SMTP service sender sending organization Internet receiving organization recipient SMTP e 1 SMTP e SMTP K 2 e 14 F inc e e inc MTA SMTP MTA 13 18 SMTP MTA send e sendOrg MTAsendOrg recOrg 3 SMTP e31 e19 e4 e15 e e20 SMTP e SMTP A SMTP 17 32 D SMTP SMTP SMTP* G INT e SMTP e MTArecOrg SMTP* 16 21 SMTP SMTP SMTP-Relay SMTP e33 e34 INT SMTP e5 e 6 SMTP* INT e22 e23 e SMTP 7 e SMTP 12 SMTP MDA MUAsend e8 recOrg HTTP(S) WebServsendOrg GWSMTP,B e e24 35 INT B MUArec e E H e e27 9 25 e37 SMTP MailServ MAP SMTP* SMTP* recOrg e26 e36 HTTP(S) INT GW e28 SMTP* A,SMTP e10 I e38 OtherAgentsend e 11 SMTP* SMTP* WebServrecOrg e29 SMTP* C GWA,B J e30 SMTP* Figure 1: Internet e-mail infrastructure as directed graph inc 2.2 Appropriateness vstart ∈Vstart = V1 ∪{MTAsendOrg , MTAsendOrg } and v ∈V = {MailServ , MTA , MTAinc } The meaning of G in the context of e-mail delivery end end recOrg recOrg recOrg is given by the fact that the different types of e-mail and P the set of all these paths.
Load more

Recommended publications
  • Red Hat Enterprise Linux 3 Security Guide
    Red Hat Enterprise Linux 3 Security Guide Red Hat Enterprise Linux 3: Security Guide Copyright © 2003 by Red Hat, Inc. Red Hat, Inc. 1801 Varsity Drive Raleigh NC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park NC 27709 USA rhel-sg(EN)-3-Print-RHI (2003-07-25T17:12) Copyright © 2003 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. Red Hat, Red Hat Network, the Red Hat "Shadow Man" logo, RPM, Maximum RPM, the RPM logo, Linux Library, PowerTools, Linux Undercover, RHmember, RHmember More, Rough Cuts, Rawhide and all Red Hat-based trademarks and logos are trademarks or registered trademarks of Red Hat, Inc. in the United States and other countries. Linux is a registered trademark of Linus Torvalds. Motif and UNIX are registered trademarks of The Open Group. XFree86 is a trademark of The XFree86 Project, Inc, and is pending registration. Intel and Pentium are registered trademarks of Intel Corporation. Itanium and Celeron are trademarks of Intel Corporation. AMD, Opteron, Athlon, Duron, and K6 are registered trademarks of Advanced Micro Devices, Inc.
    [Show full text]
  • Presentations Made by Senders
    SES ���� ��� � �� � � � � � � � ������������� DomainKeys ��������� SPF ��������������������� ���������� ����������������� ������������������������������������������������ Contents Introduction 3 Deployment: For Email Receivers 6 Audience 3 Two Sides of the Coin 6 How to Read this White Paper 3 Recording Trusted Senders Who Passed Authentication 6 A Vision for Spam-Free Email 4 Whitelisting Incoming Forwarders 6 The Problem of Abuse 4 What To Do About Forgeries 6 The Underlying Concept 4 Deployment: For ISPs and Enterprises 7 Drivers; or, Who’s Buying It 4 Complementary considerations for ISPs 7 Vision Walkthrough 5 Deployment: For MTA vendors 8 About Sender Authentication 8 Which specification? 8 An Example 8 Conformance testing 8 History 8 Perform SRS and prepend headers when forwarding 8 How IP-based Authentication Works 9 Add ESMTP support for Submitter 8 The SPF record 9 Record authentication and policy results in the headers 8 How SPF Classic Works 9 Join the developers mailing list 8 How Sender ID works 9 Deployment: For MUA vendors 9 How Cryptographic Techniques Work 0 Displaying Authentication-Results 9 Using Multiple Approaches Automatic switching to port 587 9 Reputation Systems Deployment: For ESPs 20 Deployment: For Email Senders 2 Don’t look like a phisher! 20 First, prepare. 2 Delegation 20 Audit Your Outbound Mailstreams 2 Publish Appropriately 20 Construct the record 2 Deployment: For Spammers 2 Think briefly about PRA and Mail-From contexts. 3 Two Types of Spammers 2 Test the record, part 3 Publish SPF and sign with DomainKeys. 2 Put the record in DNS 3 Stop forging random domains. 2 Test the record, part 2 4 Buy your own domains. 2 Keep Track of Violations 4 Reuse an expired domain.
    [Show full text]
  • TCP/IP Alapok II
    Windows Server 2008 TCP/IP Alapok 2. kötet V1.0 Petrényi József 2010, Petrényi József 1.0 verzió, első kiadás Minden jog fenntartva. A könyv írása során a szerző és a kiadó a legnagyobb gondossággal és körültekintéssel igyekezett eljárni. Ennek ellenére előfordulhat, hogy némely információ nem pontos vagy teljes, esetleg elavulttá vált. Az algoritmusokat és módszereket mindenki csak saját felelősségére alkalmazza. Felhasználás előtt próbálja ki és döntse el saját maga, hogy megfelel-e a céljainak. A könyvben foglalt információk felhasználásából fakadó esetleges károkért sem a szerző, sem a kiadó nem vonható felelősségre. A cégekkel, termékekkel, honlapokkal kapcsolatos listák, hibák és példák kizárólag oktatási jelleggel kerülnek bemutatásra, kedvező vagy kedvezőtlen következtetések nélkül. Az oldalakon előforduló márka- valamint kereskedelmi védjegyek bejegyzőjük tulajdonában állnak. Microsoft Magyarország 2010 Köszönetnyilvánítás: Továbbra is hatalmas köszönet illeti Joseph Davies-t, alias Cable Guy-t az alapos, szemléletformáló írásaiért. A wikipedia most sem hazudtolta meg önmagát, mindenhez hozzá tudott szólni, igaz, nem mindig sikerült érdemben. De becsületesen próbálkozott. "- Felejtsük el az egészet, kedves Tót - mondta nagylelkűen -, és lássunk hozzá a dobozoláshoz. Minden percért kár. Leültek. Tót is. Ugyanaz a Tót, aki az imént még lefitymálta és asszonypepecselésnek nézte ezt a munkát, most örült, hogy dobozolhatott... Pedig senki se hívta; épp csak, hogy helyet szorítottak neki. Persze, akárhogy vigyázott, csupa félresikerült, pofoncsapott doboz került ki a keze alól, de szerencsére ezen se akadt föl senki, legföljebb elnézően összemosolyogtak. Helyreállt a béke. Hosszú negyedórákig senki se beszélt, csak a margóvágó friss kattogása hallatszott. Később friss levegő jött a hegyekből. Szemközt, a Bábony tisztásain a gyantaszüretelők tűzrakásai hunyorogtak. Tóték ezt se látták.
    [Show full text]
  • [MS-OXSMTP]: Simple Mail Transfer Protocol (SMTP) Mail Submission Extensions
    [MS-OXSMTP]: Simple Mail Transfer Protocol (SMTP) Mail Submission Extensions Intellectual Property Rights Notice for Open Specifications Documentation . Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages, standards as well as overviews of the interaction among each of these technologies. Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you may make copies of it in order to develop implementations of the technologies described in the Open Specifications and may distribute portions of it in your implementations using these technologies or your documentation as necessary to properly document the implementation. You may also distribute in your implementation, with or without modification, any schema, IDL’s, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications. No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. Patents. Microsoft has patents that may cover your implementations of the technologies described in the Open Specifications. Neither this notice nor Microsoft's delivery of the documentation grants any licenses under those or any other Microsoft patents. However, a given Open Specification may be covered by Microsoft Open Specification Promise or the Community Promise. If you would prefer a written license, or if the technologies described in the Open Specifications are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting [email protected]. Trademarks. The names of companies and products contained in this documentation may be covered by trademarks or similar intellectual property rights.
    [Show full text]
  • NIST SP 800-177 Trustworthy Email ______
    Archived NIST Technical Series Publication The attached publication has been archived (withdrawn), and is provided solely for historical purposes. It may have been superseded by another publication (indicated below). Archived Publication Series/Number: NIST Special Publication 800-177 Title: Trustworthy Email Publication Date(s): September 2016 Withdrawal Date: February 26, 2019 Withdrawal Note: This publication has been superseded in its entirety by SP 800-177 Revision 1. Superseding Publication(s) The attached publication has been superseded by the following publication(s): Series/Number: NIST Special Publication 800-177 Revision 1 Title: Trustworthy Email Author(s): Scott Rose; J. Stephen Nightingale; Simson L. Garfinkel; Ramaswamy Chandramouli Publication Date(s): February 2019 URL/DOI: https://doi.org/10.6028/NIST.SP.800-177r1 Additional Information (if applicable) Contact: Advanced Network Technology Division (Information Technology Laboratory) Latest revision of the attached publication: Related information: https://www.nist.gov/programs-projects/high-assurance-domains https://csrc.nist.gov/publications/detail/sp/800-177/archive/2016-09-07 Withdrawal N/A announcement (link): Date updated: February 26, 2019 NIST Special Publication 800-177 Trustworthy Email Ramaswamy Chandramouli Simson Garfinkel Stephen Nightingale Scott Rose This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-177 C O M P U T E R S E C U R I T Y NIST Special Publication 800-177 Trustworthy Email Scott Rose, Stephen Nightingale Information Technology Laboratory Advanced Network Technology Division Simson L. Garfinkel Information Technology Laboratory Information Access Division Ramaswamy Chandramouli Information Technology Laboratory Computer Security Division This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-177 September 2016 U.S.
    [Show full text]
  • Rfc4409.Txt.Pdf
    Network Working Group R. Gellens Request for Comments: 4409 QUALCOMM Obsoletes: 2476 J. Klensin Category: Standards Track April 2006 Message Submission for Mail Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server. Message relay and final delivery are unaffected, and continue to use SMTP over port 25. When conforming to this document, message submission uses the protocol specified here, normally over port 587. This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. Gellens & Klensin Standards Track [Page 1] RFC 4409 Message Submission for Mail April 2006 Table of Contents 1. Introduction ....................................................3 2. Document Information ............................................4 2.1. Definitions of Terms Used in This Memo .....................4 2.2. Conventions Used in This Document ..........................5 3. Message Submission ..............................................5
    [Show full text]
  • E-Mail Security (Emailsec - Jan'09)
    E-mail security (emailsec - jan'09) Electronic mail security Antonio Lioy < lioy @ polito.it> Politecnico di Torino Dip. Automatica e Informatica MHS (Message Handling System) MTA MTA MTA chain MSA MSA MS MS MUA MUA MUA (Message User Agent) MSA (Message Submission Agent) MTA (Message Transfer Agent) MS (Message Store) E-mail on multi-user systems Mail Mail editor User User Agent RFC-822 Agent MSA Mail (MTA ) Transfer Agent SMTP SMTP SMTP SMTP MTA MTA MTA © Antonio Lioy - Politecnico di Torino (1995-2009) 1 E-mail security (emailsec - jan'09) E-mail in client-server mode SMTP Mailserver SMTP MTA ... ( MSA ) MilMail User Agent Post Office ... MTA POP, IMAP ( MS ) SMTP Webmail Mailserver SMTP MTA ... ( MSA ) SMTP HTTP web server HTML HTTP virtual engine MUA web browser POP / IMAP Post Office ... MTA ( MS ) SMTP Protocols and ports SMTP (Simple Mail Transfer Protocol) 25/tcp (MTA) 587/tcp (MSA) POP (Post Office Protocol) 110/tcp IMAP (Internet Message Access Protocol) 143/tcp © Antonio Lioy - Politecnico di Torino (1995-2009) 2 E-mail security (emailsec - jan'09) RFC-822 messages only US-ASCII characters on 7 bits lines terminated by <CR> <LF> messages composed by header + body header keywor ds a ttht the beg inn ing o fthf the line continuation lines start with a space body separated from the header by an empty line contains the message Header RFC-822 From: sender (logical) Sender: sender (operational) Organization: organization of the sender To: destination SbjtSubject: subjec t Date: date and hour of sending Received: intermediate steps Message-Id: sending ID CC: copy to Bcc: copy (hidden) to Return-Receipt-To: return receipt to An SMTP / RFC-822 example telnet duke.colorado.edu 25 Trying ....
    [Show full text]
  • Attack Over Email System: Review
    International Journal of Scientific Research & Engineering Trends Volume 3, Issue 5, Sept.-2017, ISSN (Online): 2395-566X Attack over Email System: Review Anuradha Kumari Nitin Agrawal Umesh Lilhore Computer Science & Engineering Computer Science & Engineering Computer Science & Engineering NRI Institute of Information Science & NRI Institute of Information Science & NRI Institute of Information Science & Technology, Bhopal, India Technology, Bhopal, India Technology, Bhopal, India Email: [email protected] Email: [email protected] Email: [email protected] Abstract – Email has become an integral part of our life. Email is reliable and authentic method for exchanging message. But Email systems are facing increasing security threats from local and distributed unethical elements. Keeping the email system secure is of supreme importance to every organization whether running its own emails system or using email services from internet service provider (ISP). Denial of service (DoS) attacks is more prevalent on email system. Various DoS attacks on email system are Chain bombs, error message bombs. Zip bombs and mass mailing bombs. In this paper email architecture and their security issue is discuss and explain their vulnerability with counter measure . Keywords – Email, Web Mining, Dos Attack, Email Bombing, Mass Mailing. I. INTRODUCTION flood the mail server so that mail server becomes occupied or is unserviceable [3]. Mass e-mail attacks also used to Web technology is used to implement the “Web or fake the identity of the intruder, degrade the accessibility www” portion of Web Services. Web servers and web of communications systems, damage the integrity of browsers are communicating client-server computer institution, or secretly share out illegitimate material.
    [Show full text]
  • Draft NIST Special Publication 800-177, Trustworthy Email
    1 DRAFT NIST Special Publication 800-177 2 Trustworthy Email 3 4 5 Ramaswamy Chandramouli 6 Simson Garfinkel 7 Stephen Nightingale 8 Scott Rose 9 10 11 12 13 14 15 16 17 18 19 C O M P U T E R S E C U R I T Y 20 21 22 DRAFT NIST Special Publication 800-177 23 Trustworthy Email 24 25 Scott Rose, Stephen Nightingale 26 Information Technology Laboratory 27 Advanced Network Technology Division 28 29 Simson L. Garfinkel 30 Information Technology Laboratory 31 Information Access Division 32 33 Ramaswamy Chandramouli 34 Information Technology Laboratory 35 Computer Security Division 36 37 38 39 40 41 42 43 September 2015 44 45 46 47 48 49 U.S. Department of Commerce 50 Penny Pritzker, Secretary 51 52 National Institute of Standards and Technology 53 Willie May, Under Secretary of Commerce for Standards and Technology and Director 54 Authority 55 This publication has been developed by NIST in accordance with its statutory responsibilities under the 56 Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3541 et seq., Public Law 57 (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, 58 including minimum requirements for federal information systems, but such standards and guidelines shall 59 not apply to national security systems without the express approval of appropriate federal officials 60 exercising policy authority over such systems. This guideline is consistent with the requirements of the 61 Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information 62 Systems, as analyzed in Circular A-130, Appendix IV: Analysis of Key Sections.
    [Show full text]
  • Draft NIST Special Publication 800-177, Trustworthy Email
    This (First) DRAFT of Special Publication 800-177 document has been superceded by the following draft publication: The first draft has been attached for HISTORICAL PURPOSE – PLEASE refer to the Second Draft (see details below): Publication Number: Second Draft Special Publication 800-177 Title: Trustworthy Email Publication Date: March 2016 Second Draft Publication: http://csrc.nist.gov/publications/PubsDrafts.html#800-177 Information on other publications: http://csrc.nist.gov/publications/ The following information was posted with the attached DRAFT document: NIST requests comments on the second draft of Special Publication (SP) 800-177, Trustworthy Email. This draft is a complimentary guide to NIST SP 800-45 Guidelines on Electronic Mail Security and covers protocol security technologies to secure email transactions. This draft guide includes recommendations for the deployment of domain-based authentication protocols for email as well as end-to-end cryptographic protection for email contents. Technologies recommended in support of core Simple Mail Transfer Protocol (SMTP) and the Domain Name System (DNS) include mechanisms for authenticating a sending domain (Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM) and Domain based Message Authentication, Reporting and Conformance (DMARC). Email content security is facilitated through encryption and authentication of message content using S/MIME and/or Transport Layer Security (TLS) with SMTP. This guide is written for the federal agency email administrator, information
    [Show full text]
  • Personenverzeichnis
    Personenverzeichnis Adelstein, T. 1101 Comer, D. E. 1102 Aho, A. V. 33 Conner-Sax, K. 1103 Albitz, P. 1103 Cooper, M. 46 Alkalay, A. 177 Cutler, E. 1102 Allaert, D. 422 Czyborra, R. 177 Almesberger, W. 477 Anderson, G. 30 Dalheimer, M. K. 1100, 1102 Andreasson, O. 764 Dalheimer, T. 1102 Anvin, H. P. 493 Dawson, T. 237, 1102, 1103 Arcomano, R. 308 Delorie, D. J. 451 Aubepin, F. 1100 Deutz, R. 1103 Aznar, G. 418, 797 Dietz, H. 895 Diffie, B. W. 270 Bach, M. J. 1100 Drake, J. 741 Bacon, J. 1101 Badach, A. 1103 Ebersbach, A. 1103 Barrett, D. J. 1104 Emery, V. 578 Barth, W. 1101 Ewing, L. 9, 10 Bauer, F. L. 586, 1104 Bautts, T. 1102 Fawcett, T. 496 Bayes, T. 817 Fenzi, K. 899 Bic, L. 1099 Frisch, Æ. 1101 Bigelow, C. 189 Bishop, A. M. 574 Garfinkel, S. 1100, 1104 Blaze, M. 582 Garrels, M. 46, 59, 1100 Bolsky, M. I. 1100 Ghosh, S. 304 Bourne, S. R. 33, 46, 1100 Goerzen, J. 290 Bovet, D. P. 679, 1100 Gortmaker, P. 722 Bradley, D. J. 36 Grägert, S. 1103 Brouwer, A. 387 Graham, P. 817 Brown, M. A. 238 Guérard, J.-P. 290 Burgiss, H. 223 Gulbins, J. 1100 Burrows, D. 644 Hahn, H. 1103 Buytaert, K. 890 Haible, B. 177 Cameron, J. 883, 1101 Hall, E. 1103 Card, R. 565 Hammers, C. 456, 900 Cesati, M. 679, 1100 Hards, B. 589 Christenson, N. 404 Hassell, J. 1101 Chuvakin, A. 867 Hattenhauer, R. 1100 Claus, V. 1099 Hazel, P. 802 1106 PERSONENVERZEICHNIS Heinlein, P.
    [Show full text]
  • Analysing Smtp Server and Its Security Aspects
    Vol-3 Issue-5 2017 IJARIIE-ISSN(O)-2395-4396 ANALYSING SMTP SERVER AND ITS SECURITY ASPECTS Lohith N1, T H Sreenivas2 1 Student, Information Science and Engineering, National Institute of Engineering, Karnataka, India 2Professor, Information Science and Engineering, National Institute of Engineering, Karnataka, India ABSTRACT Electronic mail (e-mail) is one of the most popular network services nowadays. Most e-mail systems that send mail over the Internet use simple mail transfer protocol (SMTP) to send messages from one server to another. The messages can then be retrieved with an e-mail client using either post office protocol (POP) or Internet message access protocol (IMAP). SMTP is also generally used to send messages from a mail client to a mail server in “hostbased” (or Unix-based) mail systems, where a simple mbox utility might be on the same system [or via Network File System (NFS) provided by Novell for access without POP or IMAP. SMTP is used as the common mechanism for transporting electronic mail among different hosts within the transmission control protocol/Internet protocol (TCP/IP) suite. It is an application layer protocol. With the increase of electronic communication, spams are widely increased targeting individuals, having a doubtful intension such as stealing personal information to be misused or even to paralyze the event system by injecting viruses. Therefore, to protect email users from spams and viruses, it is crucial to protect our SMTP servers . Keyword : - SMTP, SPF, network security 1. INTRODUCTION Email is nowadays considered to be the most widespread form of digital communication. Email not only accounts for most user communications in corporate environments, but it is also widely used in both residential and mobile environments to support citizens’ personal communications[1] .Network as we realize that Email has ended up mainstream with the dangerous development of the web.
    [Show full text]