TECHNICAL BACKGROUND OVERVIEW

AGENDA:

What is Spam What is content filtering\compliance Protocols quick overview:

smtp ldap

WHAT IS SPAM

DEFINITION OF SPAM The word "Spam" as applied to Email means

Unsolicited Bulk Email ("UBE").

Unsolicited means that the Recipient has not granted verifiable permission for the message to be sent. Bulk means that the message is sent as part of a larger collection of messages, all having substantively identical content.

A message is Spam only if it is both Unsolicited and Bulk.-Unsolicited Email is normal email(examples: first contact enquiries, job enquiries, sales enquiries)

-Bulk Email is normal email(examples: subscriber newsletters, customer communications, discussion lists)

TECHNICAL DEFINITION OF SPAM An electronic message is "spam" IF:

(1)the recipient's personal identity and context are irrelevant because the message is equally applicable to many other potential recipients;

AND

(2)the recipient has not verifiably granted deliberate, explicit, and still-revocable permission for it to be sent.

THE SPAM AND THE LAW

Various jurisdictions have implemented legislation to control what they call "spam". One particular example is US S.877 (CANSPAM 2004). Each law addresses "spam" in different ways, and as a consequence, often has different definitions of what they cover, whether they call it "spam" or not.

THE LAW AND THE SPAM Spam is an issue about consent, not content. Whether the

UBE message is an advert, a scam, porn, a begging letter or an offer of a free lunch, the content is irrelevant - if the message was sent unsolicited and in bulk then the message is spam.

Spam is not a sub-set of UBE, it is not "UBE that is also a scam or that doesn't contain an unsubscribe link", all email sent unsolicited and in bulk is Spam.

This distinction is important because legislators spend inordinate amounts of time attempting to regulate the content of spam messages, and in doing so come up against free speech issues, without realizing that the spam issue is solely about the delivery method.

DICTIONARY Scam

A confidence trick, confidence game, or con for short (also known as a scam) is an attempt to intentionally mislead a person or persons (known as the mark) usually with the goal of financial or other gain. The confidence trickster, con man, scam artist or con artist often works with an accomplice called the shill, who tries to encourage the mark by pretending to believe the trickster. ...

Phishing The act of sending an e-mail to a user falsely claiming to be an

established legitimate enterprise in an attempt to scam the user into surrendering private information that will be used for identity theft. The e-mail directs the user to visit a Web site where they are asked to update personal information, such as passwords and credit card, social security, and bank account numbers, that the legitimate organization already has. The Web site (or web page), however, is bogus and set up only to steal the user’s information.

WHAT IS CONTENT FILTERING

DEFINITION On the Internet, content filtering (also known as information

filtering) is the use of a program to screen and exclude from access or availability Web pages or e-mail that is deemed objectionable. Content filtering is used by corporations as part of Internet firewall, computers and also by home computer owners, especially by parents to screen the content their children have access to from a computer. Content filtering usually works by specifying character strings that, if matched, indicate undesirable content that is to be screened out. Content is typically screened for pornographic content and sometimes also for violence- or hate-oriented content.

Critics of content filtering programs point out that it is not difficult to unintentionally exclude desirable content.

ANTI SPAM VS CONTENT FILTERING Content filtering\content compliance tools are used to

filter unwanted contents (i.e. words, attachment) form a mail because of company or law requirement

add specific text to a mail like disclaimer to adhere law or company requirement

Block, modify or reroute tagged mail for recipients or group

….. Anti Spam

Recognize Spam Determine administrative action after the spam mail

have been recognize based on administrative rules (policy)

…

PROTOCOLS OVERVIEW:SMTP - LDAP

SMTP Short for Simple Mail Transfer Protocol, a protocol for

sending e-mail messages between servers. Most e-mail systems that send mail over the Internet use SMTP to send messages from one Server to another; the messages can then be retrieved with an e-mail client using either POP or IMAP. In addition, SMTP is generally used to send messages from a mail client to a mail server. This is why you need to specify both the POP or IMAP server and the SMTP server when you configure your e-mail application.

SMTP: THINGS TO REMEMBER Require TCP-IP to run

As well as MX records on DNS Work usually on port 25 It is possible to test a smtp connection usually by simply telnetting host port 25

It’s defined in RFC 821 - Simple Mail Transfer Protocol (SMTP), but a lot of other RFC refers to this protocol adding specifics

as amended by RFC 1123 (STD 3) chapter 5. The protocol used today is also known as ESMTP and defined in RFC 2821.

It’s sender controlled It’s unrelaiableBecause of the last 2 points obviously: smtp services does no requires clustering or other features. Since the services

have to implement those features because of the protocol is connectionless and unrealable. As a mater of fact if a smtp server goes down the sender simply retry the transmission to the next mx if the recipient is unavaible after x seconds.

Mails could be lost since once the sender relayed the mail to any server does not performany control on the delivery.

SMTP FACTS SMTP is a relatively simple, text-based protocol, where one or more recipients

of a message are specified (and in most cases verified to exist) and then the message text is transferred. It is quite easy to test a SMTP server using the telnet program (see below).

SMTP uses TCP port 25. To determine the SMTP server for a given domain name, the MX (Mail eXchange) DNS record is used.

SMTP started becoming widely used in the early 1980s. At the time, it was a complement to UUCP which was better suited to handle e-mail transfers between machines that were intermittently connected. SMTP, on the other hand, works best when both the sending and receiving machines are connected to the network all the time.

The article about sender rewriting contains technical background info about the early SMTP history and source routing before RFC 1123 (1989, obsoleted by RFC 2821 ).

Sendmail was one of the first (if not the first) mail transfer agents to implement SMTP. As of 2001 there are at least 50 programs that implement SMTP as a client (sender of messages) or a server (receiver of messages). Some other popular SMTP server programs include exim, Postfix, qmail, and Microsoft Exchange Server.

Since this protocol started out as purely ASCII text-based, it did not deal well with binary files. Standards such as MIME were developed to encode binary files for transfer through SMTP. Today, most SMTP servers support the 8BITMIME extension, permitting binary files to be transmitted almost as easily as plain text.

SMTP is a "push" protocol that does not allow one to "pull" messages from a remote server on demand. To do this a mail client must use POP3 or IMAP. Another SMTP server can trigger a delivery in SMTP using ETRN.

RELATED RFCS RFC 1870 SMTP Service Extension for Message Size Declaration (Obsoletes: RFC 1653) RFC 2476 Message Submission (obsoleted by approved 2476bis) RFC 2505 Anti-Spam Recommendations for SMTP MTAs (BCP 30) RFC 2554 SMTP Service Extension for Authentication RFC 2821 The Simple Mail Transfer Protocol (obsoletes RFC 821 aka STD 10) RFC 2822 Internet Message Format (obsoletes RFC 822 aka STD 11) RFC 2920 SMTP Service Extension for Command Pipelining (STD 60) RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages RFC 3207 SMTP Service Extension for Returning Enhanced Error Codes (obsoletes RFC

2487 ) RFC 3461 SMTP Service Extension for Delivery Status Notifications (obsoletes RFC 1891 ) RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System

Administrative Messages (obsoletes RFC 1892 ) RFC 3463 Enhanced Status Codes for SMTP (obsoletes RFC 1893 ) RFC 3464 An Extensible Message Format for Delivery Status Notifications (obsoletes RFC

1894 ) RFC 3552 Guidelines for Writing RFC Text on Security Considerations (contains SMTP

example) RFC 3834 Recommendations for Automatic Responses to Electronic Mail

SAMPLE SMTP COMMUNICATIONS

After establishing a connection between the sender (the client) and the receiver (the server), the following is a legal SMTP session. In the following conversation, everything sent by the client is prefaced with C: and everything sent by the server is prefaced with S:. On most computer systems, a connection can be established using the telnet command on the client machine, for example

telnet www.example.com 25 which opens an SMTP connection from the sending

machine to the host www.example.com.

TELNET SESSION HELO S: 220 www.example.com ESMTP Postfix C: HELO mydomain.com S: 250 Hello mydomain.com C: MAIL FROM:<sender@mydomain.com> S: 250 Ok C: RCPT TO:<friend@example.com> S: 250 Ok C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: Subject: test message C: From: sender@mydomain.com C: To: friend@example.com C: C: Hello, C: This is a test. C: Goodbye. C: . S: 250 Ok: queued as 12345 C: QUIT S: 221 Bye

PAY ATTENTION ON HELO VS EHLO Although optional and not shown above, nearly all clients ask the

server which SMTP extensions the server supports, by using the EHLO greeting to invoke Extended SMTP (ESMTP). These clients use HELO only if the server does not respond to EHLO.

Contemporary clients will use the ESMTP extension keyword SIZE to inquire of the server the maximum message size that will be accepted. Older clients and servers will try to transfer huge messages that will be rejected after wasting the network resources, including a lot of connect time to dialup ISPs that are paid by the minute.

For the edit planning of giant files or sending with older clients, users can manually determine in advance the maximum size accepted by ESMTP servers. The user telnets as above, but substitutes "EHLO mydomain.com" for the HELO command line.

TELNET SESSION EHLO S: 220-serverdomain.com ESMTP {postfix version and date} S: 220-NO UCE. {etc., terms of service} C: EHLO mydomain.com S: 250-serverdomain.com Hello mydomain.com [127.0.0.1] S: 250-SIZE 14680064 S: 250-PIPELINING S: 250 HELPThis serverdomain.com declares that it will accept a fixed maximum message

size no larger than 14,680,064 octets (8-bit bytes). Depending on the server's actual resource usage, it may be currently unable to accept a message this large.

In the simplest case, an ESMTP server will declare a maximum SIZE with only the EHLO user interaction. If no number appears after the SIZE keyword, or if the current message limit must exactly determined, the user can further interact by simulating the ESMTP header of a message with an estimated size.

SMTP SEQUENCE DIAGRAM

LDAP In computer networking, the Lightweight Directory Access Protocol, or LDAP,

is a networking protocol for querying and modifying directory services running over TCP/IP. An LDAP directory usually follows the X.500 model: It is a tree of entries, each of which consists of a set of named attributes with values. While some services use a more complicated "forest" model, the vast majority use a simple starting point for their database organization.

An LDAP directory often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. LDAP deployments today tend to use Domain Name System (DNS) names for structuring the most simple levels of the hierarchy. Further into the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else which represents a given tree entry, or multiple entries.

Its current version is LDAPv3, as defined in RFC 3377.

ORIGIN AND INFLUENCES LDAP was originally intended to be a lightweight alternative protocol for accessing X.500

directory services. X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol, or DAP, which required the cumbersome Open Systems Interconnection (OSI) protocol stack. With LDAP, a client could access these directory services through a LDAP-to-DAP gateway. The gateway would translate LDAP requests to DAP requests and DAP responses to LDAP. This model of directory access was borrowed from DIXIE and the Directory Assistance Service.

Standalone LDAP directory servers soon followed, as did directory servers supporting both DAP and LDAP. The former has become popular in enterprises as they removed any need to deploy an OSI network. Today, X.500 directory protocols including DAP can be also used directly over TCP/IP.

The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of ISODE and Wengyik Yeong of Performance Systems International, circa 1993. Further development has been done via the Internet Engineering Task Force (IETF). It is noted that in the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol or LDBP. It was renamed as the scope of the protocol was expanded to not only include directory browsing functions (e.g., search) but also directory update functions (e.g., modify).

LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory (XED), Directory Services Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP).

PROTOCOL OVERVIEW A client starts an LDAP session by connecting to an LDAP server, by default on TCP port

389. The client then sends operation requests to the server, and the server sends responses in return. With some exceptions the client need not wait for a response before sending the next request, and the server may then send the responses in any order.

The basic operations are, in order: Bind - authenticate, and specify LDAP protocol version, Start TLS - protect the connection with Transport Layer Security (TLS), to have a more secure

connection, Search - search for and/or retrieve directory entries, Compare - test if a named entry contains a given attribute value, Add a new entry, Delete an entry, Modify an entry, Modify DN - move or rename an entry, Abandon - abort a previous request, Extended Operation - generic operation used to define other operations, Unbind - close the connection, not the inverse of Bind.

In addition the server may send "Unsolicited Notifications" that are not responses to any request, e.g. before it times out a connection.

LDAP is defined in terms of ASN.1, and protocol messages are encoded in the binary format BER. It uses textual representations for a number of ASN.1 fields/types, however.

DIRECTORY STRUCTURE The protocol accesses LDAP directories, which follow the X.500

model: A directory is a tree of directory entries. An entry consists of a set of attributes. An attribute has a name (an attribute type or attribute description) and

one or more values. The attributes are defined in a schema (see below).

Each entry has an unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN) constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as a full filename and the RDN as a relative filename in a folder.

Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, an UUID is provided in the set of the entry's operational attributes.

DIRECTORY STRUCTUREAn entry can look like this when represented in LDIF format (LDAP itself is a

binary protocol): dn: cn=John Doe,dc=example,dc=com cn: John Doe givenName: John sn: Doe telephoneNumber: +1 555 6789 telephoneNumber: +1 555 1234 mail: john@example.com manager: cn=Barbara Doe,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top

DIRECTORY STRUCTURE dn is the name of the entry; it's not an attribute nor part of the entry.

"cn=John Doe" is the entry's RDN, and "dc=example,dc=com" is the DN of the parent entry. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, and "mail" for e-mail address.

A server holds a subtree starting from a specific entry, e.g. "dc=example,dc=com" and its children. Servers may also hold references to other servers, so an attempt to access "ou=Some department,dc=example,dc=com" could return a referral or continuation reference to a server which holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client.

LDAP rarely defines any ordering: The server may return the values in an attribute, the attributes in an entry, and the entries found by a search operation in any order.

SUPPORTING VENDORS (WHO USE LDAP)

LDAP has gained wide support from vendors such as: Apache (through Apache Directory Server) Apple (through Open Directory/OpenLDAP) AT&T Banyan Critical Path eB2Bcom (through View500) Fedora Directory Server Hewlett-Packard Identyx IBM/Lotus ISODE (through M-Vault server) Microsoft (through Active Directory) Netscape (now in Sun Microsystems and Red Hat products) Novell (through eDirectory) OctetString (through VDE server) Oracle (through Oracle Internet Directory) Radiant Logic (through RadiantOne Virtual Directory Server) Red Hat Directory Server Siemens AG (through DirX server) SGI and Sun (through the iPlanet and Sun ONE directory servers) Symlabs (through Directory Extender)

as well as in open source/free software implementations such as OpenLDAP and Fedora Directory Server. Also the Apache HTTP Server used as a proxy (by the module mod_proxy) supports LDAP.

LDAP IMPLEMENTATIONS Apache Directory Server Critical Path Directory Server and Meta Directory Server Fedora Directory Server Red Hat Directory Server OpenLDAP Novell eDirectory Sun Directory Server IBM SecureWay Directory IBM Tivoli Directory Server (formerly IBM Directory Server) Windows Server 2003 Active Directory Siemens DirX View500

RFCSLDAP is defined by a series of Request for Comments documents:

RFC 1487 - LDAPv2: The initial specification RFC 2251 - LDAPv3: The specification of the LDAP on-the-wire protocol RFC 2252 - LDAPv3: Attribute Syntax Definitions RFC 2253 - LDAPv3: UTF-8 String Representation of Distinguished Names RFC 2254 - LDAPv3: The String Representation of LDAP Search Filters RFC 2255 - LDAPv3: The LDAP URL Format RFC 2256 - LDAPv3: A Summary of the X.500(96) User Schema for use with

LDAPv3 RFC 2829 - LDAPv3: Authentication Methods for LDAP RFC 2830 - LDAPv3: Extension for Transport Layer Security RFC 3377 - LDAPv3: Technical Specification

LDAP EXTENSIONS AND USAGES: RFC 1823 - LDAP API (in C) RFC 2247 - Use of DNS domains in distinguished names RFC 2307 - Using LDAP as a Network Information Service RFC 2798 - inetOrgPerson LDAP Object Class RFC 2849 - The LDAP Data Interchange Format (LDIF) RFC 2891 - Server Side Sorting of Search Results RFC 3062 - LDAP Password Modify Extended Operation RFC 3296 - Named Subordinate References in LDAP Directories RFC 3383 - Internet Assigned Numbers Authority (IANA)

Considerations for the Lightweight Directory Access Protocol (LDAP) RFC 3866 - Language Tags and Ranges in LDAP RFC 3909 - LDAP Cancel Operation Chaining documentation at OpenLDAP - not yet defined in an RFC

THINGS TO REMEMBER: WARNING!!!!! LDAP is not Microsoft Active Directory Microsoft AD is not LDAPAs many vendors do, Microsoft use an LDAP proxy to

represent the AD structures in terms of LDAP objects, but AD is not LDAP at all. Most of the object that have an LDAP representation are actually different from the LDAP schema.

If you plan to create test environments I’ll provide you in the AD section some VBscripts samples to create users and OU in an AD structure. Please do not create them as LDAP queries since you could have unpredictable performance results if doing a test against Microsoft Active Directory

SEE YOU NEXT SESSION

AGENDA:

01) Intro: San Francisco at a glance and Technology Champion Program, we're here to serve and protect 02) technical background overview: protocols (smtp,ldap),spam and content filtering 03) What's new: a technical jurney to the new amazing features (covering platforms, sizeing, HW, MTA,

features and services) 04) Basic troubleshooting: logs,mySQL and Tomcat survival guidelines 05) SMS for SMTP vs SBAS 6.03 and SBAS 6.0.4 (new stuffs good stuffs!!!!) 06) Good news and bad news (what we have, what we don't have, what we would like to have) 07) Appliances VS Software: miths and legends 08) How to Sell It: competition and myths 09) Roadmap for dummy: what the future will bring to us, and when this could be usefoul to sell more 10) Query and answers: just start in advance i'll bring them to SF so i can prepare answers ;)

11) Optional0: probe what the hell is this,why we need and how i can become member of 12) Optional1: install on linux and microsoft 13) Optional2: configuring an MTA basic instruction on sendmail, postifx and IIS 14) Optional3: Syslog dig it understand it survive it 15) Optional4: Active directory and LDAP (covering ADAM too)

PPT FILES antonio01- SMSSMTP5 Overview Final 2006.ppt) Intro: San Francisco at a glance and Technology Champion Program,

we're here to serve and protect antonio02- SMSSMTP5 Overview Final 2006.ppt) technical background overview: protocols (smtp,ldap),spam and content

filtering antonio03- SMSSMTP5 Overview Final 2006.ppt) What's new: a technical jurney to the new amazing features (covering

platforms, sizeing, HW, MTA, features and services) antonio04- SMSSMTP5 Overview Final 2006.ppt) Basic troubleshooting: logs,mySQL and Tomcat survival guidelines antonio05- SMSSMTP5 Overview Final 2006.ppt) SMS for SMTP vs SBAS 6.03 and SBAS 6.0.4 (new stuffs good stuffs!!!!) antonio06- SMSSMTP5 Overview Final 2006.ppt) Good news and bad news (what we have, what we don't have, what we

would like to have) antonio07- SMSSMTP5 Overview Final 2006.ppt) Appliances VS Software: miths and legends antonio08- SMSSMTP5 Overview Final 2006.ppt) How to Sell It: competition and myths antonio09- SMSSMTP5 Overview Final 2006.ppt) Roadmap for dummy: what the future will bring to us, and when this

could be usefoul to sell more antonio10- SMSSMTP5 Overview Final 2006.ppt) Query and answers: just start in advance i'll bring them to SF so i can

prepare answers ;)

antonio11- SMSSMTP5 Overview Final 2006.ppt) Optional0: probe what the hell is this,why we need and how i can become member of

antonio12- SMSSMTP5 Overview Final 2006.ppt) Optional1: install on linux and microsoft antonio13- SMSSMTP5 Overview Final 2006.ppt) Optional2: configuring an MTA basic instruction on sendmail, postifx and

IIS antonio14- SMSSMTP5 Overview Final 2006.ppt) Optional3: Syslog dig it understand it survive it antonio15- SMSSMTP5 Overview Final 2006.ppt) Optional4: Active directory and LDAP (covering ADAM too)