Email Best Practices
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,840
On Slideshare
1,838
From Embeds
2
Number of Embeds
1

Actions

Shares
Downloads
53
Comments
0
Likes
3

Embeds 2

http://www.slideshare.net 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • How does mail get from here to there? Here's a step by step guide to a very simple email system. So you compose an email on your computer, using an email client like Outlook. You address it to someone@theirdomain.com, and press Send. So what happens next? 1. Your email program sends your email using the Simple Mail Transport Protocol ( SMTP) server where your account is. If you are sending mail to someone else whose mail account is on that server, go to step 7. Otherwise, keep reading. 2. The SMTP server breaks the address someone@theirdomain.com into two parts: someone (the account name) and theirdomain.com (the domain). The SMTP server then contacts a DNS (domain name service) server, and asks for the IP address where theirdomain.com is located. 3. The DNS server sends the address back to the SMTP server. 4. The SMTP server then sends the email message to the SMTP server where theirdomain.com is located. 5. The second SMTP server delivers the email message to someone else's account on the Point of Presence ( POP3 ) or IMAP server. 6. Someone logs on to their computer and opens their email client. Their email client requests the POP3 or IMAP server to send all email from their account to their computer. If you are sending email to someone whose account resides on the same set of mail servers, the SMTP server will simply direct the mail to the local POP3 or IMAP server, where it will be delivered to the appropriate account.
  • Security and Privacy Regulations Regulation/Law: HIPAA– Health Insurance Portability and Accountability Act Enacted/Passed: August 1996 Purpose: Maintain the privacy and security of patient information, while improving the ‘portability’ of the information or records. There are four rules that HIPAA enforces: Privacy Rule, Security Rule, Transaction and Code-Set Standards, and Identifier Standards. The above four rules, respectively, specify – what patient information must be kept private; how companies must secure the information; and the standards for electronic communication between medical providers and insurance companies. Sectors/Companies Affected: Medical providers, insurance companies, claims clearinghouses, and any employers that ‘self-insure’ workers’ health benefits. IT Department Pain-Points: HIPAA regulations are very specific about the technology standards and policies that must be implemented to comply. The primary challenge is to translate these standards and policies into products and services that ensure compliance with current and future HIPAA regulations. An additional critical challenge is meeting the deadlines listed below: Deadlines: Privacy Standards, April 15, 2003; Transaction and Code-Sets, October 15th, 2003; Identifier Standards, July 30th, 2004; and Security, April 21st, 2005 Regulation/Law: Gramm-Leach-Bliley Act Enacted/Passed: November 1999 Purpose: To protect the information financial institutions collect about customers Sectors/Companies Affected: Financial institutions primarily, but also any company that collects name, Social Security number and bank account number from customers or employees. IT Department Pain-Points: On May 23rd, the Act’s SafeGuard Rule came into effect, ‘forcing’ financial institutions to design, implement and maintain the necessary ‘safeguards’. These safeguards affect all aspects of IT security from the workstation to the router to overall security policy. Deadlines: May 23rd, 2003 Regulation/Law: Sarbanes-Oxley Act Enacted/Passed: August 2002 Purpose: To restore the integrity of financial reporting of public companies and hold corporate officers responsible for misrepresentation. Sectors/Companies Affected: Any public company, and as a recommendation – any private company expecting to go public, is strongly advised to abide by the regulations. IT Department Pain-Points: Mainly, ‘Phase II’ of the Act: To automate the process of building audit trails and control procedures into their IT systems; as well as preparing for third party audits, and/or remote monitoring. Deadlines: Section 302, January 2003 (Quarterly Reporting, Controls and Procedures, and Methods); Section 404, June 14th, 2004 (Third Party Audits of Controls and Procedures). Regulation/Law: California Senate Bill 1386 Enacted/Passed: September 2002 Purpose: To give California consumers immediate notice of security compromises in businesses’ computer systems so that they can proactively respond before identity theft occurs. Sectors/Companies Affected: Any company that stores a California resident’s personal information on their computer systems. IT Department Pain-Points: To implement systems that detect and report security breaches; and equally as important, systems that can prevent the breaches, and provide counter measures. Deadlines: In effect
  • Regulation/Law: USA Patriot Act Enacted/Passed: October 2001 Purpose: To empower and strengthen the government’s ability to track and prosecute terrorist activity through increased use of surveillance, information sharing and ‘other’ means. Sectors/Companies Affected: Financial institutions, ISPs, and other companies that handle and store online information. IT Department Pain-Points: To build and maintain an infrastructure that allows the institution to provide the government with level of information granularity that they will be requesting; such as session times and duration (voice and data), IP addresses, credit cards and bank account information, etc. Deadlines: In effect Regulation/Law: The National Strategy to Secure Cyberspace Report Enacted/Passed: February 2003 Purpose: To suggest ‘best practices’ to the private sector for protecting critical infrastructures and businesses from cyber attacks. Sectors/Companies Affected: All private businesses, but especially, those that run critical infrastructures, such as: energy/utility companies, telecom, stock market, transportation, etc. IT Department Pain-Points: To build highly-available and highly-secure voice and data network infrastructures, in addition to having robust – threat assessment, risk assessment, contingency planning, and network continuity plans. Deadlines: In effect Other Anti-spam Regulations: Criminal Spam Act of 2003 (Introduced June 2003) Stop Pornography and Abusive Marketing Act (“The Spam Act”) – June, 2003 The Reduction in Distribution of Spam Act of 2003 (May, 2003) Controlling the Assault of Non-Solicited Pornography and Marketing Act (CAN-SPAM) – April, 2003 Computer Owners’ Bill of Rights (March, 2003) Forthcoming, anti-spam bill/ agreement between US and EU (Proposed July, 2003)
  • In Content Based Filtering in a two-pronged compliance strategy looks at the contents of the message, including the header and subject, message, and any attachments. Based on the regulated content of the email, the message will be automatically encrypted or sent in the clear.
  • With Identity-Based Filtering, you look at both the sender and the receiver. If the sender is authorized to send the communication, then encrypt the email automatically. For example, any email communication by the payroll group or payroll manager is encrypted regardless of the contents of the communication. If the sender is not authorized, then go to stage 2, which investigates the content being sent. If the receiver is designated to receive the communication, then automatically encrypt the email. For example, a patient is the intended recipient of his/her any communication from his/her insurance company. If the receiver is not designated to receive the email, then go to stage 2.
  • Introduction to TLS: The TLS (former SSL) protocol By default all communication on the Internet is done without encryption and without strong authentication. That does mean that everybody with physical access to the communication line along which a network packet will travel can eavesdrop on your communication. Even worse, it might be possible to redirect or alter your communication so that information, that you want to send to a party can be lost or changed without your notice. In order to solve these security issues, the SSL protocol (Secure Socket Layers) was introduced by Netscape, Inc., which now has evolved into the standardized TLS protocol (Transportation Layer Security) as RFC2246 . It offers both encryption of the communication (stopping eavesdropping) and strong authentication (making sure that both parties of a communication are correctly identified and that the communication cannot be altered). RFC2487: Introducing TLS to SMTP The integration of the TLS protocol to Internet mail, SMTP (Simple Mail Transport Protocol) is described in RFC2487 . Unlike the first incarnations of SSL as a wrapper around normal network communications, the TLS protocol is now completely integrated into the ESMTP: during the startup negotiation (EHLO) the server offers the support of TLS by advertising the STARTTLS feature. The client can now send the STARTTLS command to do authentication and switch to encrypted communication. Introduction to S/MIME: S/MIME e-mail provides the ability to add Public Key signatures and/or data encryption to the contents of e-mail messages. This document To use these functions you need to have an S/MIME enabled e-mail client installed on your desktop computer. You also need a key pair and certificate for yourself and access to the Public Key certificates of the people with which you wish to exchange S/MIME e-mail messages. The necessary certificates can be stored on your local machine or retrieved from network directories. People with whom you wish to exchange S/MIME messages need a compatible setup. MIME is a standard for encoding e-mail enclosures (including non-textual data). The S/MIME standard adds security features to the messages. Introduction to PGP: PGP combines some of the best features of both conventional and public key cryptography. PGP is a hybrid cryptosystem. When a user encrypts plaintext with PGP, PGP first compresses the plaintext. Data compression saves modem transmission time and disk space and, more importantly, strengthens cryptographic security. Most cryptanalysis techniques exploit patterns found in the plaintext to crack the cipher. Compression reduces these patterns in the plaintext, thereby greatly enhancing resistance to cryptanalysis. (Files that are too short to compress or which do not compress well are not compressed.) PGP then creates a session key, which is a one-time-only secret key. This key is a random number generated from the random movements of your mouse and the keystrokes you type. The session key works with a very secure, fast conventional encryption algorithm to encrypt the plaintext; the result is ciphertext. Once the data is encrypted, the session key is then encrypted to the recipient’s public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient. Decryption works in the reverse. The recipient’s copy of PGP uses his or her private key to recover the session key, which PGP then uses to decrypt the conventionally encrypted ciphertext. The combination of the two encryption methods combines the convenience of public-key encryption with the speed of conventional encryption. Conventional encryption is about 1,000 times faster than public-key encryption. Public-key encryption in turn provides a solution to key distribution and data transmission issues. Used together, performance and key distribution are improved without any sacrifice in security. Introduction to Secure WebMail: Secure Messenger combines nearly universal reach and extensive mail-routing capabilities. It supports a range of delivery methods, online, offline, and desktop encryption/decryption, granular mail policies, and content filtering based on weighted word analysis. Secure Messenger provides universal message delivery, allowing end-users to receive messages using their desktop mail client or Web-based mail system.
  • New Spam Tricks: The amount of spam has exploded in recent months, experts say, as spammers have adopted new tricks. Research by Postini found a record 93 percent of e-mail was spam from September through November. "The spammers are definitely winning at this point. It's gotten much worse," said Gerald Thain, a professor of consumer law at the University of Wisconsin-Madison who specializes in e-mail issues. One of the newest dodges is sending spam in the form of an image rather than text, allowing it to get past filters that trap spam by hunting down specific words. So-called image e-mails account for some 30 percent of junk e-mails, compared with just 2 percent in 2005, Postini said. Another ploy is called phishing, in which an official-looking e-mail asks recipients for passwords or personal information. "Pump and dump" e-mails urge recipients to buy certain stocks, driving up the price, while in other schemes spammers hijack other computers -- turning them into what pros call zombies -- to deliver their messages. "We recently saw 400,000 new zombies coming online every day," said Atri Chatterjee, senior vice president of marketing at Secure Computing Corp. in Alpharetta, Georgia. "What you have is a very aggressive use of innocent computers," he said. The battle between spammers and anti-spammers is like a game of "cops and robbers," said J.J. Schoch, a security expert at Panda Software, a developer of computer anti-virus systems. "The cops try and outsmart the robbers, the robbers try and outsmart the cops," he said. Not only has the amount of spam ballooned, but its nature has changed, said Druker. "First it was hackers trying to show off how smart they were. Then it shifted to annoying marketers," he said. "Now a large percentage of this stuff is coming from criminal networks who are out to steal your money.“ Origin of the Term “SPAM" to Mean Net Abuse: Much to the chagrin of Hormel Foods , maker of the canned "Shoulder Pork and hAM"/"SPiced hAM" luncheon meat, the term "spam" has today come to mean network abuse, particularly junk E-mail and massive junk postings to USENET. How did the term get this meaning? I went on a mission of etymological research. In this article you'll learn how the term, born of canned ham, moved into BBSs and MUDS and then was applied to USENET postings and E-mail. I've put in a short history of the earliest big spams, including a special page about the first E-mail spam from 1978. (You'll be astounded to see which net celebrity defends the spam. But we were all younger then.) (This is an interesting time for spammiversaries. March 31st, 2003 marked the 10th anniversary of the term Spam being applied to a USENET post, and May 3rd marked the 25th anniversary of the earliest documented E-mail spam.) Plus at the bottom, a bit about the term surfing the net. Most people have some vague awareness that it came from at first from the spam skit by Monty Python's Flying Circus. In the sketch, a restaurant serves all its food with lots of spam, and the waitress repeats the word several times in describing how much spam is in the items. When she does this, a group of Vikings (don't ask) in the corner start a song: "Spam, spam, spam, spam, spam, spam, spam, spam, lovely spam! Wonderful spam!" Until told to shut up. Thus the meaning of the term at least: Something that keeps repeating and repeating to great annoyance. How did the two get connected? The First Spam: Possibly the first spam ever was a message from a DEC marketing rep to every Arpanet address on the west coast, or at least the attempt at that. (You can also learn more about the history of spam.) Below is the spam itself. After it you will find a snippet from some of the reaction it generated, not unlike the reaction to spam today. Look for the celebrity spam-defender! (Of course that was decades ago.) Some explanation by Einar Stefferud, who provided these files and was one of those who were there at the time: It was sent from SNDMSG which had limited space for To and CC and Subject fields. The poor soul that typed in the announcement, also (in those days) had to type in all the addresses, and this person was not trained in the use of SNDMSG. So, she/he started typing addresses into the Subject which overflowed into the TO header, which overflowed into the CC header, and then into the Body, and then the actual message was finally typed in;-)... So, lots of intended recipients did not receive it, including me as I was then STEF@SRI-KA. Obviously here was no such thing as quality control in play. Thus it is some kind of classic example of early screw ups... But the reaction was the same as today's reaction to SPAM ...Stef Amusingly, SpamAssassin scores this as spam. Partly for being in all upper case, but also because the headers of 1978 are considered invalid today! The sender is identified as Gary Thuerk, an aggressive DEC marketer who thought Arpanet users would find it cool that DEC had integrated Arpanet protocol support directly into the new DEC-20 and TOPS-20 OS. DEC was mostly an east coast company, and he had lots of contacts on the east coast to push the new Dec-20 to customers there. But with less presence on the west coast, he wanted to hold some open houses and reach all the people there. In those days, there was a printed directory of all people on the Arpanet. Gary spoke to his technical associate, and arranged to have all the addresses in the directory on the west coast typed in, and then added some customer contacts in other locations, including people at ARPA headquarters who did not, according to Thuerk, complain. The engineer, Carl Gartley, was an early employee at DEC who had been called in to help with promoting the new Decsystem-20. They worked on the message for a few days, going through a few rewrites. Finally, on May 3, Gartley logged on to Gary's account to send the mail. As you see below, the mail program would only accept 320 addresses. The rest overflowed into the body of the message. When they found some recipients had not gotten it, they re-sent the message to the rest of the recipients. According to Thuerk, they were unaware of the "address file" function in the mail program that would have enabled a mailing list. Thuerk thought, and maintains to this day that he didn't think he was doing anything wrong -- even though he gets a moderate amount of spam on his current E-mail account. He felt the Dec-20 was really relevant news to the Arpanet community, the first major system with Arpanet software built into it. Indeed, some of those who commented on the message felt it was definitely more of interest than other small mass mailings they had seen, with baby announcements and personal trivia. Nonetheless, he knew there would be some negative reaction. He primed his boss to be ready for complaint, though he didn't anticipate how strong it would be. The Defense Communications Agency (DCA) which ran the Arpanet, called Thuerk's boss, a former Air Force officer to register a strong complaint. One user from the University of Utah complained the spam had shut down his computer system. Thuerk says only 3 copies were sent to that system, so it was simply an unlucky coincidence that his mailbox disks were very near full when the message arrived. In those days of 56kb links, the thousands of copies of this message were not an insignificant load, however. Some who didn't get the message felt left out, oddly enough, since it became such a topic of conversation. Thuerk continues his career selling systems today, but his spam career was very short lived. In many ways, the negative reaction to that spam probably made sure the problem did not arise again for many years. Here is the First Spam Message: -------------------------------------------------------------------------------- Mail-from: DEC-MARLBORO rcvd at 3-May-78 0955-PDT Date: 1 May 1978 1233-EDT From: THUERK at DEC-MARLBORO Subject: ADRIAN@SRI-KL To: DDAY at SRI-KL, DAY at SRI-KL, DEBOER at UCLA-CCN, To: WASHDC at SRI-KL, LOGICON at USC-ISI, SDAC at USC-ISI, To: DELDO at USC-ISI, DELEOT at USC-ISI, DELFINO at USC-ISI, To: DENICOFF at USC-ISI, DESPAIN at USC-ISI, DEUTSCH at SRI-KL, To: DEUTSCH at PARC-MAXC, EMY at CCA-TENEX, DIETER at USC-ISIB, To: DINES at AMES-67, MERADCON at SRI-KL, EPG-SPEC at SRI-KA, To: DIVELY at SRI-KL, DODD at USC-ISI, DONCHIN at USC-ISIC, To: JED at LLL-COMP, DORIN at CCA-TENEX, NYU at SRI-KA, To: DOUGHERTY at USC-ISI, PACOMJ6 at USC-ISI, To: DEBBY at UCLA-SECURITY, BELL at SRI-KL, JHANNON at SRI-KA, To: DUBOIS at USC-ISI, DUDA at SRI-KL, POH at USC-ISI, To: LES at SU-AI, EAST at BBN-TENEX, DEASTMAN at USC-ECL, To: EBISU at I4-TENEX, NAC at USC-ISIE, ECONOMIDIS at I4-TENEX, To: WALSH at SRI-KL, GEDWARDS at SRI-KL, WEDWARDS at USC-ISI, To: NUSC at SRI-KL, RM at SU-AI, ELKIND at PARC-MAXC, To: ELLENBY at PARC-MAXC, ELLIS at PARC-MAXC, ELLIS at USC-ISIB, To: ENGELBART at SRI-KL, ENGELMORE at SUMEX-AIM, To: ENGLISH at PARC-MAXC, ERNST at I4-TENEX, To: ESTRIN at MIT-MULTICS, EYRES at USC-ISIC, To: FAGAN at SUMEX-AIM, FALCONER at SRI-KL, To: DUF at UCLA-SECURITY, FARBER at RAND-UNIX, PMF at SU-AI, To: HALFF at USC-ISI, RJF at MIT-MC, FEIERBACH at I4-TENEX, To: FEIGENBAUM at USC-ISI, FEINLER at SRI-KL, To: FELDMAN at SUMEX-AIM, FELDMAN at SRI-KL, FERNBACH at LLL-COMP, To: FERRARA at RADC-MULTICS, FERRETTI at SRI-KA, To: FIALA at PARC-MAXC, FICKAS at USC-ISIC, AFIELD at I4-TENEX, To: FIKES at PARC-MAXC, REF at SU-AI, FINK at MIT-MULTICS, To: FINKEL at USC-ISIB, FINN at USC-ISIB, AFGWC at BBN-TENEX, To: FLINT at SRI-KL, WALSH at SRI-KL, DRXAN at SRI-KA, To: FOX at SRI-KL, FRANCESCHINI at MIT-MULTICS, To: SAI at USC-ISIC, FREDRICKSON at RAND-RCC, ETAC at BBN-TENEXB, To: FREYLING at BBN-TENEXE, FRIEDLAND at SUMEX-AIM, To: FRIENDSHUH at SUMEX-AIM, FRITSCH at LLL-COMP, ME at SU-AI, To: FURST at BBN-TENEXB, FUSS at LLL-COMP, OP-FYE at USC-ISIB, To: SCHILL at USC-ISIC, GAGLIARDI at USC-ISIC, To: GAINES at RAND-UNIX, GALLENSON at USC-ISIB, To: GAMBLE at BBN-TENEXE, GAMMILL at RAND-UNIX, To: GANAN at USC-ISI, GARCIA at SUMEX-AIM, To: GARDNER at SUMEX-AIM, MCCUTCHEN at SRI-KL, To: GARDNER at MIT-MULTICS, GARLICK at SRI-KL, To: GARVEY at SRI-KL, GAUTHIER at USC-ISIB, To: USGS-LIA at BBN-TENEX, GEMOETS at I4-TENEX, To: GERHART at USC-ISIB, GERLA at USC-ISIE, GERLACH at I4-TENEX, To: GERMAN at HARV-10, GERPHEIDE at SRI-KA, DANG at SRI-KL, To: GESCHKE at PARC-MAXC, GIBBONS at CMU-10A, To: GIFFORD.COMPSYS at MIT-MULTICS, JGILBERT at BBN-TENEXB, To: SGILBERT at BBN-TENEXB, SDAC at USC-ISI, To: GILLOGLY at RAND-UNIX, STEVE at RAND-UNIX, To: GLEASON at SRI-KL, JAG;BIN(1525) at UCLA-CCN, To: GOLD at LL-11, GOLDBERG at USC-ISIB, GOLDGERG at SRI-KL, To: GROBSTEIN at SRI-KL, GOLDSTEIN at BBN-TENEXB, To: DARPM-NW at BBN-TENEXB, GOODENOUGH at USC-ISIB, To: GEOFF at SRI-KL, GOODRICH at I4-TENEX, GOODWIN at USC-ISI, To: GOVINSKY at SRI-KL, DEAN at I4-TENEX, TEG at MIT-MULTICS, To: CCG at SU-AI, EPG-SPEC at SRI-KA, GRISS at USC-ECL, To: BJG at RAND-UNIX, MCCUTCHEN at SRI-KL, GROBSTEIN at SRI-KL, To: MOBAH at I4-TENEX, GUSTAFSON at USC-ISIB, GUTHARY at SRI-KL, To: GUTTAG at USC-ISIB, GUYTON at RAND-RCC, To: ETAC-AD at BBN-TENEXB, HAGMANN at USC-ECL, HALE at I4-TENEX, To: HALFF at USC-ISI, DEHALL at MIT-MULTICS, To: HAMPEL at LLL-COMP, HANNAH at USC-ISI, To: NORSAR-TIP at USC-ISIC, SCRL at USC-ISI, HAPPY at SRI-KL, To: HARDY at SRI-KL, IMPACT at SRI-KL, KLH at SRI-KL, To: J33PAC at USC-ISI, HARRISON at SRI-KL, WALSH at SRI-KL, To: DRCPM-FF at BBN-TENEXB, HART at AMES-67, HART at SRI-KL, To: HATHAWAY at AMES-67, AFWL at I4-TENEX, BHR at RAND-UNIX, To: RICK at RAND-UNIX, DEBE at USC-ISIB, HEARN at USC-ECL, To: HEATH at UCLA-ATS, HEITMEYER at BBN-TENEX, ADTA at SRI-KA, To: HENDRIX at SRI-KL, CH47M at BBN-TENEXB, HILLIER at SRI-KL, To: HISS at I4-TENEX, ASLAB at USC-ISIC, HOLG at USC-ISIB, To: HOLLINGWORTH at USC-ISIB, HOLLOWAY at HARV-10, To: HOLMES at SRI-KL, HOLSWORTH at SRI-KA, HOLT at LLL-COMP, To: HOLTHAM at LL, DHOLZMAN at RAND-UNIX, HOPPER at USC-ISIC, To: HOROWITZ at USC-ISIB, VSC at USC-ISI, HOWARD at LLL-COMP, To: HOWARD at USC-ISI, PURDUE at USC-ISI, HUBER at RAND-RCC, To: HUNER at RADC-MULTICS, HUTSON at AMES-67, IMUS at USC-ISI, To: JACOBS at USC-ISIE, JACOBS at BBN-TENEXB, To: JACQUES at BBN-TENEXB, JARVIS at PARC-MAXC, To: JEFFERS at PARC-MAXC, JENKINS at PARC-MAXC, To: JENSEN at SRI-KA, JIRAK at SUMEX-AIM, NICKIE at SRI-KL, To: JOHNSON at SUMEX-AIM, JONES at SRI-KL, JONES at LLL-COMP, To: JONES at I4-TENEX, RLJ at MIT-MC, JURAK at USC-ECL, To: KAHLER at SUMEX-AIM, MWK at SU-AI, KAINE at USC-ISIB, To: KALTGRAD at UCLA-ATS, MARK at UCLA-SECURITY, RAK at SU-AI, To: KASTNER at USC-ISIB, KATT at USC-ISIB, To: UCLA-MNC at USC-ISI, ALAN at PARC-MAXC, KEENAN at USC-ISI, To: KEHL at UCLA-CCN, KELLEY at SRI-KL, BANANA at I4-TENEX, To: KELLOGG at USC-ISI, DDI at USC-ISI, KEMERY at SRI-KL, To: KEMMERER at UCLA-ATS, PARVIZ at UCLA-ATS, KING at SUMEX-AIM, To: KIRSTEIN at USC-ISI, SDC at UCLA-SECURITY, To: KLEINROCK at USC-ISI, KLEMBA at SRI-KL, CSK at USC-ISI, To: KNIGHT at SRI-KL, KNOX at USC-ISI, KODA at USC-ISIB, To: KODANI at AMES-67, KOOIJ at USC-ISI, KREMERS at SRI-KL, To: BELL at SRI-KL, KUNZELMAN at SRI-KL, PROJX at SRI-KL, To: LAMPSON at PARC-MAXC, SDL at RAND-UNIX, JOJO at SRI-KL, To: SDC at USC-ISI, NELC3030 at USC-ISI, To: LEDERBERG at SUMEX-AIM, LEDUC at SRI-KL, JSLEE at USC-ECL, To: JACOBS at USC-ISIE, WREN at USC-ISIB, LEMONS at USC-ISIB, To: LEUNG at SRI-KL, J33PAC at USC-ISI, LEVIN at USC-ISIB, To: LEVINTHAL at SUMEX-AIM, LICHTENBERGER at I4-TENEX, To: LICHTENSTEIN at USC-ISI, LIDDLE at PARC-MAXC, To: LIEB at USC-ISIB, LIEBERMAN at SRI-KL, STANL at USC-ISIE, To: LIERE at I4-TENEX, DOCB at USC-ISIC, LINDSAY at SRI-KL, To: LINEBARGER at AMES-67, LIPKIS at USC-ECL, SLES at USC-ISI, To: LIS at SRI-KL, LONDON at USC-ISIB, J33PAC at USC-ISI, To: LOPER at SRI-KA, LOUVIGNY at SRI-KL, LOVELACE at USC-ISIB, To: LUCANIC at SRI-KL, LUCAS at USC-ISIB, DCL at SU-AI, To: LUDLAM at UCLA-CCN, YNGVAR at SRI-KA, LYNCH at SRI-KL, To: LYNN at USC-ISIB, MABREY at SRI-KL, MACKAY at AMES-67, To: MADER at USC-ISIB, MAGILL at SRI-KL, KMAHONEY at BBN-TENEX, To: MANN at USC-ISIB, ZM at SU-AI, MANNING at USC-ISI, To: MANTIPLY at I4-TENEX, MARIN at I4-TENEX, SCRL at USC-ISI, To: HARALD at SRI-KA, GLORIA-JEAN at UCLA-CCN, MARTIN at USC-ISIC, To: WMARTIN at USC-ISI, GRM at RAND-UNIX, MASINTER at USC-ISI, To: MASON at USC-ISIB, MATHIS at SRI-KL, MAYNARD at USC-ISIC, To: MCBREARTY at SRI-KL, MCCALL at SRI-KA, MCCARTHY at SU-AI, To: MCCLELLAND at USC-ISI, DORIS at RAND-UNIX, MCCLURG at SRI-KL, To: JOHN at I4-TENEX, MCCREIGHT at PARC-MAXC, MCCRUMB at USC-ISI, To: DRXTE at SRI-KA cc: BPM at SU-AI Note here how we get to the body of the message and there are still addresses going into it that wouldn't fit! [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] MUNTZ;BIN(1529)@UCLA-CCN [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] UZGALIS;BIN(0836)@UCLA-CCN [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] DIGITAL WILL BE GIVING A PRODUCT PRESENTATION OF THE NEWEST MEMBERS OF THE DECSYSTEM-20 FAMILY; THE DECSYSTEM-2020, 2020T, 2060, AND 2060T. THE DECSYSTEM-20 FAMILY OF COMPUTERS HAS EVOLVED FROM THE TENEX OPERATING SYSTEM AND THE DECSYSTEM-10 COMPUTER ARCHITECTURE. BOTH THE DECSYSTEM-2060T AND 2020T OFFER FULL ARPANET SUPPORT UNDER THE TOPS-20 OPERATING SYSTEM. THE DECSYSTEM-2060 IS AN UPWARD EXTENSION OF THE CURRENT DECSYSTEM 2040 AND 2050 FAMILY. THE DECSYSTEM-2020 IS A NEW LOW END MEMBER OF THE DECSYSTEM-20 FAMILY AND FULLY SOFTWARE COMPATIBLE WITH ALL OF THE OTHER DECSYSTEM-20 MODELS. WE INVITE YOU TO COME SEE THE 2020 AND HEAR ABOUT THE DECSYSTEM-20 FAMILY AT THE TWO PRODUCT PRESENTATIONS WE WILL BE GIVING IN CALIFORNIA THIS MONTH. THE LOCATIONS WILL BE: TUESDAY, MAY 9, 1978 - 2 PM HYATT HOUSE (NEAR THE L.A. AIRPORT) LOS ANGELES, CA THURSDAY, MAY 11, 1978 - 2 PM DUNFEY'S ROYAL COACH SAN MATEO, CA (4 MILES SOUTH OF S.F. AIRPORT AT BAYSHORE, RT 101 AND RT 92) A 2020 WILL BE THERE FOR YOU TO VIEW. ALSO TERMINALS ON-LINE TO OTHER DECSYSTEM-20 SYSTEMS THROUGH THE ARPANET. IF YOU ARE UNABLE TO ATTEND, PLEASE FEEL FREE TO CONTACT THE NEAREST DEC OFFICE FOR MORE INFORMATION ABOUT THE EXCITING DECSYSTEM-20 FAMILY. The Reaction to the First Spam Here's just a snippet of some of the reaction... 10-MAY-78 23:20:30-PDT,1491;000000000001 Mail-from: SRI-KA rcvd at 5-MAY-78 1203-PDT Mail-from: SRI-KL rcvd at 5-May-78 0732-PDT Date: 4 May 1978 1635-PDT From: Feinler at SRI-KL (Jake Feinler) Subject: MSGGROUP# 694 DEC Message To: DEC-MAIL-RECIPIENTS: Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 5 MAY 1978 Date: 4 MAY 1978 0452-PDT To: FEINLER at SRI-KL From: DCACODE535 at USC-ISI JAKE, YOU MAY HAVE RECEIVED THE MSG SENT OUT BY DEC ON MAY 1 ABOUT WHICH I HAVE ALREADY RECEIVED SEVERAL COMPLAINTS AS YOU CAN READILY IMAGINE. CAN YOU FORWARD THE FOLLOWING MESSAGE TO ALL ADDRESSES OF THE SUSPECT MESSAGE PLUS ALL HOST AND TIP LIAISONS? THANKS: NOTE: Please direct your comments, if any, directly to DCACODE535@ISI. Thanks, Jake. -------------------------------------------------------------------------------- ON 2 MAY 78 DIGITAL EQUIPMENT CORPORATION (DEC) SENT OUT AN ARPANET MESSAGE ADVERTISING THEIR NEW COMPUTER SYSTEMS. THIS WAS A FLAGRANT VIOLATION OF THE USE OF ARPANET AS THE NETWORK IS TO BE USED FOR OFFICIAL U.S. GOVERNMENT BUSINESS ONLY. APPROPRIATE ACTION IS BEING TAKEN TO PRECLUDE ITS OCCURRENCE AGAIN. IN ENFORCEMENT OF THIS POLICY DCA IS DEPENDENT ON THE ARPANET SPONSORS, AND HOST AND TIP LIAISONS. IT IS IMPERATIVE YOU INFORM YOUR USERS AND CONTRACTORS WHO ARE PROVIDED ARPANET ACCESS THE MEANING OF THIS POLICY. THANK YOU FOR YOUR COOPERATION. MAJOR RAYMOND CZAHOR CHIEF, ARPANET MANAGEMENT BRANCH, DCA -------------------------------------------------------------------------------- 10-MAY-78 23:20:30-PDT,2192;000000000001 Mail-from: SRI-KL rcvd at 7-MAY-78 1527-PDT Date: 7 May 1978 1527-PDT From: Feinler at SRI-KL (Jake Feinler) Subject: MSGGROUP# 695 Personal comments on DEC message for MsgGroup To: Stef at ISI cc: feinler Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 7 MAY 1978 I was not going to comment (and add to the traffic) on the issue of the DEC message that was sent out, but after having several conversations with people about and around on this issue I think I will add what hopefully will be useful insight to the problem. NOTE: The comments are my own. They do not represent any official message from DCA or the NIC. There are two kinds of message that have been frowned upon on the network. These are advertising of particular products and advertising for or by job applicants. I would like to point out that there are good reasons (other than taking up valuable resources and the fact that some recipients object) for not permitting these kinds of messages. There are many companies in the U.S. and abroad that would like to have access to the Arpanet. Naturally all of them cannot have this access. Consequently if the ones that do have access can advertise their products to a very select market and the others cannot, this is really an unfair advantage. Likewise, if job applicants can be selected amongst some of the best trained around, or if the applicants themselves can advertise to a very select group of prospective employers, this is an unfair advantage to other prospective employees or employers who are not on the net. I have heard some rumblings about 'control' and 'censorship' of the net by the powers-that-be, but I feel in these two particular areas they are leaning over backwards to be fair to the big guys and the small guys alike. In addition, the official message sent out asked us ('us' being network users) to address the issue ourselves. I personally think this is reasonable and think we should lend our support or otherwise be saddled with controls that will be a nuisance to everyone involved. Regards, Jake -------------------------------------------------------------------------------- 10-MAY-78 23:20:30-PDT,3281;000000000001 Mail-from: SU-AI rcvd at 7-MAY-78 2058-PDT Date: 7 May 1978 2057-PDT From: MRC at SU-AI (Mark Crispin) Subject: MSGGROUP# 696 in reply to Jake's message about advertising To: MsgGroup at USC-ISI Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 8 MAY 1978 I agree with Jake about suppressing advertising for many of the same reasons as I disagreed with suppressing subjective messages about QUASAR. The ARPAnet is not, as Jake pointed out, a public resource; it is available to pretty much a select group of people (high school kids regardless!). We are all engaged in activities relating to, or in support of, official US Government business. ARPAnet mail therefore is more of an "interoffice memo" sort of thing than a trade journal, not intended for public distribution although not "top secret" either. Even MsgGroup is in this class; however inappropriate QUASAR is to MsgGroup's intent (and it was inappropriate) I feel that any censorship can only lead to worse things later on. I am sure that DCA realizes this also; otherwise the ARPAnet would have been curbed long ago. Whether or not QUASAR is a fake is a valid topic to be discussed among the computer science community via the ARPAnet; although it is inappropriate for MsgGroup. If there is sufficient interest, another group should be created whose purpose and interests embrace this issue. I don't see any place for advertising on the ARPAnet, however; certainly not the bulk advertising of that DEC message. From the address list, it seems clear to me that the people it was sent to were the Californians listed in the last ARPAnet directory. This was a clear and flagrant abuse of the directory! I am not sure as to how far this should be carried though. I would not mind hearing from DEC about their new products via ARPAnet mail, but I would expect considerably more technical content and considerably less of a sales pitch. Where is the line to be drawn between this sort of thing (if it is to be allowed at all) and advertising? Another point Jake mentioned which concerns me is that of employment hunting (by employee or employer). Is that to be taken to mean that a person cannot establish contacts at another ARPAnet site and poke around about a possible position there? Is this really unfair to non-ARPAnet people? Allow me to point out that at times a job is created in order to have a particular person on the staff, and if that person is unavailable, the job won't exist. This all seems worthy of examination by the MsgGroup community, as it involves how electronic mail is to be used. Something else; I would greatly appreciate it if all comments about this make a distinction between ARPAnet mail and mail on another (possibly commercial) network. Saying that electronic junk mail is a no-no on the ARPAnet doesn't answer the question. I shudder to think about it, but I can envision junk mail being sent to people who implement Dialnet, and no way it could be prevented or stopped. I guess the ultimate solution is the command in your mail reading subsystem which deletes an unwanted message. -- Mark -------------------------------------------------------------------------------- 10-MAY-78 23:20:30-PDT,2250;000000000001 Mail-from: MIT-AI rcvd at 7-MAY-78 2316-PDT Date: 8 MAY 1978 0213-EDT From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 697 Some Thoughts about advertising To: stefferud at USC-ISI Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 8 MAY 1978 1) I didn't receive the DEC message, but I can't imagine I would have been bothered if I have. I get tons of uninteresting mail, and system announcements about babies born, etc. At least a demo MIGHT have been interesting. 2) The amount of harm done by any of the cited "unfair" things the net has been used for is clearly very small. And if they have found any people any jobs, clearly they have done good. If I had a job to offer, I would offer it to my friends first. Is this "evil"? Must I advertise in a paper in every city in the US with population over 50,000 and then go to all of them to interview, all in the name of fairness? Some people, I am afraid, would think so. Such a great insistence on fairness would distort everyone's lives and do much more harm than good. So I state unashamedly that I am in favor of seeing jobs offered via whatever. 3) It has just been suggested that we impose someone's standards on us because otherwise he MIGHT do so. Well, if you feel that those standards are right and necessary, go right ahead and support them. But if you disagree with them, as I do, why hand your opponents the victory on a silver platter? By the suggested reasoning, we should always follow the political views that we don't believe in, and especially those of terrorists, in anticipation of their attempts to impose them on us. If those who think that the job offers are bad are going to try to prevent them, then those of us who think they are unrepugnant should uphold our views. Besides, I doubt that anyone can successfully force a site from outside to impose censorship, if the people there don't fundamentally agree with the desirability of it. 4) Would a dating service for people on the net be "frowned upon" by DCA? I hope not. But even if it is, don't let that stop you from notifying me via net mail if you start one. -------------------------------------------------------------------------------- 10-MAY-78 23:20:30-PDT,685;000000000001 Mail-from: MIT-AI rcvd at 9-MAY-78 1528-PDT Date: 9 MAY 1978 1827-EDT From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 698 DEC message [VERY TASTY!] To: Stefferud at USC-ISI CC: Geoff at SRI-KL Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 9 MAY 1978 Well, Geoff forwarded me a copy of the DEC message, and I eat my words. I sure would have minded it! Nobody should be allowed to send a message with a header that long, no matter what it is about. Forward this if you feel like it. [EDITORS NOTE: ACTUALLY, I THINK RMS@MIT-AI NEEDS SOME MORE COPIES. /STEF] -------------------------------------------------------------------------------- 10-MAY-78 23:20:30-PDT,13632;000000000000 Mail-from: SRI-KA rcvd at 10-MAY-78 0921-PDT Date: 10 May 1978 0910-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP# 699 [THUERK at DEC-MARLBORO: ADRIAN@SRI-KL] From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: msggroup at ISI Message-ID: Begin forwarded message =========================== Mail-from: DEC-MARLBORO rcvd at 3-May-78 0955-PDT Date: 1 May 1978 1233-EDT From: THUERK at DEC-MARLBORO Subject: ADRIAN@SRI-KL To: DDAY at SRI-KL, DAY at SRI-KL, DEBOER at UCLA-CCN, [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP] Canter and Siegel In April of 1994, the term was not born, but it did jump a great deal in popularity when two lawyers from Phoenix named Canter and Siegel posted a message advertising their fairly useless services in an upcoming U.S. "green card" lottery. This wasn't the first such abusive posting, nor the first mass posting to be called a spam, but it was the first deliberate mass posting to commonly get that name. They had posted their message a few times before, but on April 12, they hired an mercenary programmer to write a simple script to post their ad to every single newsgroup (message board) on USENET, the world's largest online conferencing system. There were several thousand such newsgroups, and each one got the ad. Quickly people identified it as "spam" and the word caught on. Future multiple postings soon got the appelation. Some people also applied it to individual unwanted ads that weren't posted a
  • New Spam Tricks: The amount of spam has exploded in recent months, experts say, as spammers have adopted new tricks. Research by Postini found a record 93 percent of e-mail was spam from September through November. "The spammers are definitely winning at this point. It's gotten much worse," said Gerald Thain, a professor of consumer law at the University of Wisconsin-Madison who specializes in e-mail issues. One of the newest dodges is sending spam in the form of an image rather than text, allowing it to get past filters that trap spam by hunting down specific words. So-called image e-mails account for some 30 percent of junk e-mails, compared with just 2 percent in 2005, Postini said. Another ploy is called phishing, in which an official-looking e-mail asks recipients for passwords or personal information. "Pump and dump" e-mails urge recipients to buy certain stocks, driving up the price, while in other schemes spammers hijack other computers -- turning them into what pros call zombies -- to deliver their messages. "We recently saw 400,000 new zombies coming online every day," said Atri Chatterjee, senior vice president of marketing at Secure Computing Corp. in Alpharetta, Georgia. "What you have is a very aggressive use of innocent computers," he said. The battle between spammers and anti-spammers is like a game of "cops and robbers," said J.J. Schoch, a security expert at Panda Software, a developer of computer anti-virus systems. "The cops try and outsmart the robbers, the robbers try and outsmart the cops," he said. Not only has the amount of spam ballooned, but its nature has changed, said Druker. "First it was hackers trying to show off how smart they were. Then it shifted to annoying marketers," he said. "Now a large percentage of this stuff is coming from criminal networks who are out to steal your money.“ Origin of the Term “SPAM" to Mean Net Abuse: Much to the chagrin of Hormel Foods , maker of the canned "Shoulder Pork and hAM"/"SPiced hAM" luncheon meat, the term "spam" has today come to mean network abuse, particularly junk E-mail and massive junk postings to USENET. How did the term get this meaning? I went on a mission of etymological research. In this article you'll learn how the term, born of canned ham, moved into BBSs and MUDS and then was applied to USENET postings and E-mail. I've put in a short history of the earliest big spams, including a special page about the first E-mail spam from 1978. (You'll be astounded to see which net celebrity defends the spam. But we were all younger then.) (This is an interesting time for spammiversaries. March 31st, 2003 marked the 10th anniversary of the term Spam being applied to a USENET post, and May 3rd marked the 25th anniversary of the earliest documented E-mail spam.) Plus at the bottom, a bit about the term surfing the net. Most people have some vague awareness that it came from at first from the spam skit by Monty Python's Flying Circus. In the sketch, a restaurant serves all its food with lots of spam, and the waitress repeats the word several times in describing how much spam is in the items. When she does this, a group of Vikings (don't ask) in the corner start a song: "Spam, spam, spam, spam, spam, spam, spam, spam, lovely spam! Wonderful spam!" Until told to shut up. Thus the meaning of the term at least: Something that keeps repeating and repeating to great annoyance. How did the two get connected? The First Spam: Possibly the first spam ever was a message from a DEC marketing rep to every Arpanet address on the west coast, or at least the attempt at that. (You can also learn more about the history of spam.) Below is the spam itself. After it you will find a snippet from some of the reaction it generated, not unlike the reaction to spam today. Look for the celebrity spam-defender! (Of course that was decades ago.) Some explanation by Einar Stefferud, who provided these files and was one of those who were there at the time: It was sent from SNDMSG which had limited space for To and CC and Subject fields. The poor soul that typed in the announcement, also (in those days) had to type in all the addresses, and this person was not trained in the use of SNDMSG. So, she/he started typing addresses into the Subject which overflowed into the TO header, which overflowed into the CC header, and then into the Body, and then the actual message was finally typed in;-)... So, lots of intended recipients did not receive it, including me as I was then STEF@SRI-KA. Obviously here was no such thing as quality control in play. Thus it is some kind of classic example of early screw ups... But the reaction was the same as today's reaction to SPAM ...Stef Amusingly, SpamAssassin scores this as spam. Partly for being in all upper case, but also because the headers of 1978 are considered invalid today! The sender is identified as Gary Thuerk, an aggressive DEC marketer who thought Arpanet users would find it cool that DEC had integrated Arpanet protocol support directly into the new DEC-20 and TOPS-20 OS. DEC was mostly an east coast company, and he had lots of contacts on the east coast to push the new Dec-20 to customers there. But with less presence on the west coast, he wanted to hold some open houses and reach all the people there. In those days, there was a printed directory of all people on the Arpanet. Gary spoke to his technical associate, and arranged to have all the addresses in the directory on the west coast typed in, and then added some customer contacts in other locations, including people at ARPA headquarters who did not, according to Thuerk, complain. The engineer, Carl Gartley, was an early employee at DEC who had been called in to help with promoting the new Decsystem-20. They worked on the message for a few days, going through a few rewrites. Finally, on May 3, Gartley logged on to Gary's account to send the mail. As you see below, the mail program would only accept 320 addresses. The rest overflowed into the body of the message. When they found some recipients had not gotten it, they re-sent the message to the rest of the recipients. According to Thuerk, they were unaware of the "address file" function in the mail program that would have enabled a mailing list. Thuerk thought, and maintains to this day that he didn't think he was doing anything wrong -- even though he gets a moderate amount of spam on his current E-mail account. He felt the Dec-20 was really relevant news to the Arpanet community, the first major system with Arpanet software built into it. Indeed, some of those who commented on the message felt it was definitely more of interest than other small mass mailings they had seen, with baby announcements and personal trivia. Nonetheless, he knew there would be some negative reaction. He primed his boss to be ready for complaint, though he didn't anticipate how strong it would be. The Defense Communications Agency (DCA) which ran the Arpanet, called Thuerk's boss, a former Air Force officer to register a strong complaint. One user from the University of Utah complained the spam had shut down his computer system. Thuerk says only 3 copies were sent to that system, so it was simply an unlucky coincidence that his mailbox disks were very near full when the message arrived. In those days of 56kb links, the thousands of copies of this message were not an insignificant load, however. Some who didn't get the message felt left out, oddly enough, since it became such a topic of conversation. Thuerk continues his career selling systems today, but his spam career was very short lived. In many ways, the negative reaction to that spam probably made sure the problem did not arise again for many years. Here is the First Spam Message: -------------------------------------------------------------------------------- Mail-from: DEC-MARLBORO rcvd at 3-May-78 0955-PDT Date: 1 May 1978 1233-EDT From: THUERK at DEC-MARLBORO Subject: ADRIAN@SRI-KL To: DDAY at SRI-KL, DAY at SRI-KL, DEBOER at UCLA-CCN, To: WASHDC at SRI-KL, LOGICON at USC-ISI, SDAC at USC-ISI, To: DELDO at USC-ISI, DELEOT at USC-ISI, DELFINO at USC-ISI, To: DENICOFF at USC-ISI, DESPAIN at USC-ISI, DEUTSCH at SRI-KL, To: DEUTSCH at PARC-MAXC, EMY at CCA-TENEX, DIETER at USC-ISIB, To: DINES at AMES-67, MERADCON at SRI-KL, EPG-SPEC at SRI-KA, To: DIVELY at SRI-KL, DODD at USC-ISI, DONCHIN at USC-ISIC, To: JED at LLL-COMP, DORIN at CCA-TENEX, NYU at SRI-KA, To: DOUGHERTY at USC-ISI, PACOMJ6 at USC-ISI, To: DEBBY at UCLA-SECURITY, BELL at SRI-KL, JHANNON at SRI-KA, To: DUBOIS at USC-ISI, DUDA at SRI-KL, POH at USC-ISI, To: LES at SU-AI, EAST at BBN-TENEX, DEASTMAN at USC-ECL, To: EBISU at I4-TENEX, NAC at USC-ISIE, ECONOMIDIS at I4-TENEX, To: WALSH at SRI-KL, GEDWARDS at SRI-KL, WEDWARDS at USC-ISI, To: NUSC at SRI-KL, RM at SU-AI, ELKIND at PARC-MAXC, To: ELLENBY at PARC-MAXC, ELLIS at PARC-MAXC, ELLIS at USC-ISIB, To: ENGELBART at SRI-KL, ENGELMORE at SUMEX-AIM, To: ENGLISH at PARC-MAXC, ERNST at I4-TENEX, To: ESTRIN at MIT-MULTICS, EYRES at USC-ISIC, To: FAGAN at SUMEX-AIM, FALCONER at SRI-KL, To: DUF at UCLA-SECURITY, FARBER at RAND-UNIX, PMF at SU-AI, To: HALFF at USC-ISI, RJF at MIT-MC, FEIERBACH at I4-TENEX, To: FEIGENBAUM at USC-ISI, FEINLER at SRI-KL, To: FELDMAN at SUMEX-AIM, FELDMAN at SRI-KL, FERNBACH at LLL-COMP, To: FERRARA at RADC-MULTICS, FERRETTI at SRI-KA, To: FIALA at PARC-MAXC, FICKAS at USC-ISIC, AFIELD at I4-TENEX, To: FIKES at PARC-MAXC, REF at SU-AI, FINK at MIT-MULTICS, To: FINKEL at USC-ISIB, FINN at USC-ISIB, AFGWC at BBN-TENEX, To: FLINT at SRI-KL, WALSH at SRI-KL, DRXAN at SRI-KA, To: FOX at SRI-KL, FRANCESCHINI at MIT-MULTICS, To: SAI at USC-ISIC, FREDRICKSON at RAND-RCC, ETAC at BBN-TENEXB, To: FREYLING at BBN-TENEXE, FRIEDLAND at SUMEX-AIM, To: FRIENDSHUH at SUMEX-AIM, FRITSCH at LLL-COMP, ME at SU-AI, To: FURST at BBN-TENEXB, FUSS at LLL-COMP, OP-FYE at USC-ISIB, To: SCHILL at USC-ISIC, GAGLIARDI at USC-ISIC, To: GAINES at RAND-UNIX, GALLENSON at USC-ISIB, To: GAMBLE at BBN-TENEXE, GAMMILL at RAND-UNIX, To: GANAN at USC-ISI, GARCIA at SUMEX-AIM, To: GARDNER at SUMEX-AIM, MCCUTCHEN at SRI-KL, To: GARDNER at MIT-MULTICS, GARLICK at SRI-KL, To: GARVEY at SRI-KL, GAUTHIER at USC-ISIB, To: USGS-LIA at BBN-TENEX, GEMOETS at I4-TENEX, To: GERHART at USC-ISIB, GERLA at USC-ISIE, GERLACH at I4-TENEX, To: GERMAN at HARV-10, GERPHEIDE at SRI-KA, DANG at SRI-KL, To: GESCHKE at PARC-MAXC, GIBBONS at CMU-10A, To: GIFFORD.COMPSYS at MIT-MULTICS, JGILBERT at BBN-TENEXB, To: SGILBERT at BBN-TENEXB, SDAC at USC-ISI, To: GILLOGLY at RAND-UNIX, STEVE at RAND-UNIX, To: GLEASON at SRI-KL, JAG;BIN(1525) at UCLA-CCN, To: GOLD at LL-11, GOLDBERG at USC-ISIB, GOLDGERG at SRI-KL, To: GROBSTEIN at SRI-KL, GOLDSTEIN at BBN-TENEXB, To: DARPM-NW at BBN-TENEXB, GOODENOUGH at USC-ISIB, To: GEOFF at SRI-KL, GOODRICH at I4-TENEX, GOODWIN at USC-ISI, To: GOVINSKY at SRI-KL, DEAN at I4-TENEX, TEG at MIT-MULTICS, To: CCG at SU-AI, EPG-SPEC at SRI-KA, GRISS at USC-ECL, To: BJG at RAND-UNIX, MCCUTCHEN at SRI-KL, GROBSTEIN at SRI-KL, To: MOBAH at I4-TENEX, GUSTAFSON at USC-ISIB, GUTHARY at SRI-KL, To: GUTTAG at USC-ISIB, GUYTON at RAND-RCC, To: ETAC-AD at BBN-TENEXB, HAGMANN at USC-ECL, HALE at I4-TENEX, To: HALFF at USC-ISI, DEHALL at MIT-MULTICS, To: HAMPEL at LLL-COMP, HANNAH at USC-ISI, To: NORSAR-TIP at USC-ISIC, SCRL at USC-ISI, HAPPY at SRI-KL, To: HARDY at SRI-KL, IMPACT at SRI-KL, KLH at SRI-KL, To: J33PAC at USC-ISI, HARRISON at SRI-KL, WALSH at SRI-KL, To: DRCPM-FF at BBN-TENEXB, HART at AMES-67, HART at SRI-KL, To: HATHAWAY at AMES-67, AFWL at I4-TENEX, BHR at RAND-UNIX, To: RICK at RAND-UNIX, DEBE at USC-ISIB, HEARN at USC-ECL, To: HEATH at UCLA-ATS, HEITMEYER at BBN-TENEX, ADTA at SRI-KA, To: HENDRIX at SRI-KL, CH47M at BBN-TENEXB, HILLIER at SRI-KL, To: HISS at I4-TENEX, ASLAB at USC-ISIC, HOLG at USC-ISIB, To: HOLLINGWORTH at USC-ISIB, HOLLOWAY at HARV-10, To: HOLMES at SRI-KL, HOLSWORTH at SRI-KA, HOLT at LLL-COMP, To: HOLTHAM at LL, DHOLZMAN at RAND-UNIX, HOPPER at USC-ISIC, To: HOROWITZ at USC-ISIB, VSC at USC-ISI, HOWARD at LLL-COMP, To: HOWARD at USC-ISI, PURDUE at USC-ISI, HUBER at RAND-RCC, To: HUNER at RADC-MULTICS, HUTSON at AMES-67, IMUS at USC-ISI, To: JACOBS at USC-ISIE, JACOBS at BBN-TENEXB, To: JACQUES at BBN-TENEXB, JARVIS at PARC-MAXC, To: JEFFERS at PARC-MAXC, JENKINS at PARC-MAXC, To: JENSEN at SRI-KA, JIRAK at SUMEX-AIM, NICKIE at SRI-KL, To: JOHNSON at SUMEX-AIM, JONES at SRI-KL, JONES at LLL-COMP, To: JONES at I4-TENEX, RLJ at MIT-MC, JURAK at USC-ECL, To: KAHLER at SUMEX-AIM, MWK at SU-AI, KAINE at USC-ISIB, To: KALTGRAD at UCLA-ATS, MARK at UCLA-SECURITY, RAK at SU-AI, To: KASTNER at USC-ISIB, KATT at USC-ISIB, To: UCLA-MNC at USC-ISI, ALAN at PARC-MAXC, KEENAN at USC-ISI, To: KEHL at UCLA-CCN, KELLEY at SRI-KL, BANANA at I4-TENEX, To: KELLOGG at USC-ISI, DDI at USC-ISI, KEMERY at SRI-KL, To: KEMMERER at UCLA-ATS, PARVIZ at UCLA-ATS, KING at SUMEX-AIM, To: KIRSTEIN at USC-ISI, SDC at UCLA-SECURITY, To: KLEINROCK at USC-ISI, KLEMBA at SRI-KL, CSK at USC-ISI, To: KNIGHT at SRI-KL, KNOX at USC-ISI, KODA at USC-ISIB, To: KODANI at AMES-67, KOOIJ at USC-ISI, KREMERS at SRI-KL, To: BELL at SRI-KL, KUNZELMAN at SRI-KL, PROJX at SRI-KL, To: LAMPSON at PARC-MAXC, SDL at RAND-UNIX, JOJO at SRI-KL, To: SDC at USC-ISI, NELC3030 at USC-ISI, To: LEDERBERG at SUMEX-AIM, LEDUC at SRI-KL, JSLEE at USC-ECL, To: JACOBS at USC-ISIE, WREN at USC-ISIB, LEMONS at USC-ISIB, To: LEUNG at SRI-KL, J33PAC at USC-ISI, LEVIN at USC-ISIB, To: LEVINTHAL at SUMEX-AIM, LICHTENBERGER at I4-TENEX, To: LICHTENSTEIN at USC-ISI, LIDDLE at PARC-MAXC, To: LIEB at USC-ISIB, LIEBERMAN at SRI-KL, STANL at USC-ISIE, To: LIERE at I4-TENEX, DOCB at USC-ISIC, LINDSAY at SRI-KL, To: LINEBARGER at AMES-67, LIPKIS at USC-ECL, SLES at USC-ISI, To: LIS at SRI-KL, LONDON at USC-ISIB, J33PAC at USC-ISI, To: LOPER at SRI-KA, LOUVIGNY at SRI-KL, LOVELACE at USC-ISIB, To: LUCANIC at SRI-KL, LUCAS at USC-ISIB, DCL at SU-AI, To: LUDLAM at UCLA-CCN, YNGVAR at SRI-KA, LYNCH at SRI-KL, To: LYNN at USC-ISIB, MABREY at SRI-KL, MACKAY at AMES-67, To: MADER at USC-ISIB, MAGILL at SRI-KL, KMAHONEY at BBN-TENEX, To: MANN at USC-ISIB, ZM at SU-AI, MANNING at USC-ISI, To: MANTIPLY at I4-TENEX, MARIN at I4-TENEX, SCRL at USC-ISI, To: HARALD at SRI-KA, GLORIA-JEAN at UCLA-CCN, MARTIN at USC-ISIC, To: WMARTIN at USC-ISI, GRM at RAND-UNIX, MASINTER at USC-ISI, To: MASON at USC-ISIB, MATHIS at SRI-KL, MAYNARD at USC-ISIC, To: MCBREARTY at SRI-KL, MCCALL at SRI-KA, MCCARTHY at SU-AI, To: MCCLELLAND at USC-ISI, DORIS at RAND-UNIX, MCCLURG at SRI-KL, To: JOHN at I4-TENEX, MCCREIGHT at PARC-MAXC, MCCRUMB at USC-ISI, To: DRXTE at SRI-KA cc: BPM at SU-AI Note here how we get to the body of the message and there are still addresses going into it that wouldn't fit! [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] MUNTZ;BIN(1529)@UCLA-CCN [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] UZGALIS;BIN(0836)@UCLA-CCN [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] [email_address] DIGITAL WILL BE GIVING A PRODUCT PRESENTATION OF THE NEWEST MEMBERS OF THE DECSYSTEM-20 FAMILY; THE DECSYSTEM-2020, 2020T, 2060, AND 2060T. THE DECSYSTEM-20 FAMILY OF COMPUTERS HAS EVOLVED FROM THE TENEX OPERATING SYSTEM AND THE DECSYSTEM-10 COMPUTER ARCHITECTURE. BOTH THE DECSYSTEM-2060T AND 2020T OFFER FULL ARPANET SUPPORT UNDER THE TOPS-20 OPERATING SYSTEM. THE DECSYSTEM-2060 IS AN UPWARD EXTENSION OF THE CURRENT DECSYSTEM 2040 AND 2050 FAMILY. THE DECSYSTEM-2020 IS A NEW LOW END MEMBER OF THE DECSYSTEM-20 FAMILY AND FULLY SOFTWARE COMPATIBLE WITH ALL OF THE OTHER DECSYSTEM-20 MODELS. WE INVITE YOU TO COME SEE THE 2020 AND HEAR ABOUT THE DECSYSTEM-20 FAMILY AT THE TWO PRODUCT PRESENTATIONS WE WILL BE GIVING IN CALIFORNIA THIS MONTH. THE LOCATIONS WILL BE: TUESDAY, MAY 9, 1978 - 2 PM HYATT HOUSE (NEAR THE L.A. AIRPORT) LOS ANGELES, CA THURSDAY, MAY 11, 1978 - 2 PM DUNFEY'S ROYAL COACH SAN MATEO, CA (4 MILES SOUTH OF S.F. AIRPORT AT BAYSHORE, RT 101 AND RT 92) A 2020 WILL BE THERE FOR YOU TO VIEW. ALSO TERMINALS ON-LINE TO OTHER DECSYSTEM-20 SYSTEMS THROUGH THE ARPANET. IF YOU ARE UNABLE TO ATTEND, PLEASE FEEL FREE TO CONTACT THE NEAREST DEC OFFICE FOR MORE INFORMATION ABOUT THE EXCITING DECSYSTEM-20 FAMILY. The Reaction to the First Spam Here's just a snippet of some of the reaction... 10-MAY-78 23:20:30-PDT,1491;000000000001 Mail-from: SRI-KA rcvd at 5-MAY-78 1203-PDT Mail-from: SRI-KL rcvd at 5-May-78 0732-PDT Date: 4 May 1978 1635-PDT From: Feinler at SRI-KL (Jake Feinler) Subject: MSGGROUP# 694 DEC Message To: DEC-MAIL-RECIPIENTS: Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 5 MAY 1978 Date: 4 MAY 1978 0452-PDT To: FEINLER at SRI-KL From: DCACODE535 at USC-ISI JAKE, YOU MAY HAVE RECEIVED THE MSG SENT OUT BY DEC ON MAY 1 ABOUT WHICH I HAVE ALREADY RECEIVED SEVERAL COMPLAINTS AS YOU CAN READILY IMAGINE. CAN YOU FORWARD THE FOLLOWING MESSAGE TO ALL ADDRESSES OF THE SUSPECT MESSAGE PLUS ALL HOST AND TIP LIAISONS? THANKS: NOTE: Please direct your comments, if any, directly to DCACODE535@ISI. Thanks, Jake. -------------------------------------------------------------------------------- ON 2 MAY 78 DIGITAL EQUIPMENT CORPORATION (DEC) SENT OUT AN ARPANET MESSAGE ADVERTISING THEIR NEW COMPUTER SYSTEMS. THIS WAS A FLAGRANT VIOLATION OF THE USE OF ARPANET AS THE NETWORK IS TO BE USED FOR OFFICIAL U.S. GOVERNMENT BUSINESS ONLY. APPROPRIATE ACTION IS BEING TAKEN TO PRECLUDE ITS OCCURRENCE AGAIN. IN ENFORCEMENT OF THIS POLICY DCA IS DEPENDENT ON THE ARPANET SPONSORS, AND HOST AND TIP LIAISONS. IT IS IMPERATIVE YOU INFORM YOUR USERS AND CONTRACTORS WHO ARE PROVIDED ARPANET ACCESS THE MEANING OF THIS POLICY. THANK YOU FOR YOUR COOPERATION. MAJOR RAYMOND CZAHOR CHIEF, ARPANET MANAGEMENT BRANCH, DCA -------------------------------------------------------------------------------- 10-MAY-78 23:20:30-PDT,2192;000000000001 Mail-from: SRI-KL rcvd at 7-MAY-78 1527-PDT Date: 7 May 1978 1527-PDT From: Feinler at SRI-KL (Jake Feinler) Subject: MSGGROUP# 695 Personal comments on DEC message for MsgGroup To: Stef at ISI cc: feinler Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 7 MAY 1978 I was not going to comment (and add to the traffic) on the issue of the DEC message that was sent out, but after having several conversations with people about and around on this issue I think I will add what hopefully will be useful insight to the problem. NOTE: The comments are my own. They do not represent any official message from DCA or the NIC. There are two kinds of message that have been frowned upon on the network. These are advertising of particular products and advertising for or by job applicants. I would like to point out that there are good reasons (other than taking up valuable resources and the fact that some recipients object) for not permitting these kinds of messages. There are many companies in the U.S. and abroad that would like to have access to the Arpanet. Naturally all of them cannot have this access. Consequently if the ones that do have access can advertise their products to a very select market and the others cannot, this is really an unfair advantage. Likewise, if job applicants can be selected amongst some of the best trained around, or if the applicants themselves can advertise to a very select group of prospective employers, this is an unfair advantage to other prospective employees or employers who are not on the net. I have heard some rumblings about 'control' and 'censorship' of the net by the powers-that-be, but I feel in these two particular areas they are leaning over backwards to be fair to the big guys and the small guys alike. In addition, the official message sent out asked us ('us' being network users) to address the issue ourselves. I personally think this is reasonable and think we should lend our support or otherwise be saddled with controls that will be a nuisance to everyone involved. Regards, Jake -------------------------------------------------------------------------------- 10-MAY-78 23:20:30-PDT,3281;000000000001 Mail-from: SU-AI rcvd at 7-MAY-78 2058-PDT Date: 7 May 1978 2057-PDT From: MRC at SU-AI (Mark Crispin) Subject: MSGGROUP# 696 in reply to Jake's message about advertising To: MsgGroup at USC-ISI Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 8 MAY 1978 I agree with Jake about suppressing advertising for many of the same reasons as I disagreed with suppressing subjective messages about QUASAR. The ARPAnet is not, as Jake pointed out, a public resource; it is available to pretty much a select group of people (high school kids regardless!). We are all engaged in activities relating to, or in support of, official US Government business. ARPAnet mail therefore is more of an "interoffice memo" sort of thing than a trade journal, not intended for public distribution although not "top secret" either. Even MsgGroup is in this class; however inappropriate QUASAR is to MsgGroup's intent (and it was inappropriate) I feel that any censorship can only lead to worse things later on. I am sure that DCA realizes this also; otherwise the ARPAnet would have been curbed long ago. Whether or not QUASAR is a fake is a valid topic to be discussed among the computer science community via the ARPAnet; although it is inappropriate for MsgGroup. If there is sufficient interest, another group should be created whose purpose and interests embrace this issue. I don't see any place for advertising on the ARPAnet, however; certainly not the bulk advertising of that DEC message. From the address list, it seems clear to me that the people it was sent to were the Californians listed in the last ARPAnet directory. This was a clear and flagrant abuse of the directory! I am not sure as to how far this should be carried though. I would not mind hearing from DEC about their new products via ARPAnet mail, but I would expect considerably more technical content and considerably less of a sales pitch. Where is the line to be drawn between this sort of thing (if it is to be allowed at all) and advertising? Another point Jake mentioned which concerns me is that of employment hunting (by employee or employer). Is that to be taken to mean that a person cannot establish contacts at another ARPAnet site and poke around about a possible position there? Is this really unfair to non-ARPAnet people? Allow me to point out that at times a job is created in order to have a particular person on the staff, and if that person is unavailable, the job won't exist. This all seems worthy of examination by the MsgGroup community, as it involves how electronic mail is to be used. Something else; I would greatly appreciate it if all comments about this make a distinction between ARPAnet mail and mail on another (possibly commercial) network. Saying that electronic junk mail is a no-no on the ARPAnet doesn't answer the question. I shudder to think about it, but I can envision junk mail being sent to people who implement Dialnet, and no way it could be prevented or stopped. I guess the ultimate solution is the command in your mail reading subsystem which deletes an unwanted message. -- Mark -------------------------------------------------------------------------------- 10-MAY-78 23:20:30-PDT,2250;000000000001 Mail-from: MIT-AI rcvd at 7-MAY-78 2316-PDT Date: 8 MAY 1978 0213-EDT From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 697 Some Thoughts about advertising To: stefferud at USC-ISI Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 8 MAY 1978 1) I didn't receive the DEC message, but I can't imagine I would have been bothered if I have. I get tons of uninteresting mail, and system announcements about babies born, etc. At least a demo MIGHT have been interesting. 2) The amount of harm done by any of the cited "unfair" things the net has been used for is clearly very small. And if they have found any people any jobs, clearly they have done good. If I had a job to offer, I would offer it to my friends first. Is this "evil"? Must I advertise in a paper in every city in the US with population over 50,000 and then go to all of them to interview, all in the name of fairness? Some people, I am afraid, would think so. Such a great insistence on fairness would distort everyone's lives and do much more harm than good. So I state unashamedly that I am in favor of seeing jobs offered via whatever. 3) It has just been suggested that we impose someone's standards on us because otherwise he MIGHT do so. Well, if you feel that those standards are right and necessary, go right ahead and support them. But if you disagree with them, as I do, why hand your opponents the victory on a silver platter? By the suggested reasoning, we should always follow the political views that we don't believe in, and especially those of terrorists, in anticipation of their attempts to impose them on us. If those who think that the job offers are bad are going to try to prevent them, then those of us who think they are unrepugnant should uphold our views. Besides, I doubt that anyone can successfully force a site from outside to impose censorship, if the people there don't fundamentally agree with the desirability of it. 4) Would a dating service for people on the net be "frowned upon" by DCA? I hope not. But even if it is, don't let that stop you from notifying me via net mail if you start one. -------------------------------------------------------------------------------- 10-MAY-78 23:20:30-PDT,685;000000000001 Mail-from: MIT-AI rcvd at 9-MAY-78 1528-PDT Date: 9 MAY 1978 1827-EDT From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 698 DEC message [VERY TASTY!] To: Stefferud at USC-ISI CC: Geoff at SRI-KL Redistributed-To: [ISI]Mailing.List;154: Redistributed-By: STEFFERUD (connected to MSGGROUP) Redistributed-Date: 9 MAY 1978 Well, Geoff forwarded me a copy of the DEC message, and I eat my words. I sure would have minded it! Nobody should be allowed to send a message with a header that long, no matter what it is about. Forward this if you feel like it. [EDITORS NOTE: ACTUALLY, I THINK RMS@MIT-AI NEEDS SOME MORE COPIES. /STEF] -------------------------------------------------------------------------------- 10-MAY-78 23:20:30-PDT,13632;000000000000 Mail-from: SRI-KA rcvd at 10-MAY-78 0921-PDT Date: 10 May 1978 0910-PDT Sender: GEOFF at SRI-KA Subject: MSGGROUP# 699 [THUERK at DEC-MARLBORO: ADRIAN@SRI-KL] From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: msggroup at ISI Message-ID: Begin forwarded message =========================== Mail-from: DEC-MARLBORO rcvd at 3-May-78 0955-PDT Date: 1 May 1978 1233-EDT From: THUERK at DEC-MARLBORO Subject: ADRIAN@SRI-KL To: DDAY at SRI-KL, DAY at SRI-KL, DEBOER at UCLA-CCN, [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP] Canter and Siegel In April of 1994, the term was not born, but it did jump a great deal in popularity when two lawyers from Phoenix named Canter and Siegel posted a message advertising their fairly useless services in an upcoming U.S. "green card" lottery. This wasn't the first such abusive posting, nor the first mass posting to be called a spam, but it was the first deliberate mass posting to commonly get that name. They had posted their message a few times before, but on April 12, they hired an mercenary programmer to write a simple script to post their ad to every single newsgroup (message board) on USENET, the world's largest online conferencing system. There were several thousand such newsgroups, and each one got the ad. Quickly people identified it as "spam" and the word caught on. Future multiple postings soon got the appelation. Some people also applied it to individual unwanted ads that weren't posted a
  • 1st box: Attackers send spam, phishing, viruses, DoS, and DHA attacks from all over the Internet broadcasting information about open relays, gathering email addresses and selling them to various firms, etc. These attacks make spammers money, but clog up precious email resources. 2 nd box: DNS Mail Exchanger (MX) records have mistakes and are weighted incorrectly. This causes email to clog up queues on some relays while leaving other relays completely idle. No DNS A Records for outbound mail gateways causes email to be rejected by remote email gateways. 3 rd box: Zero redundancy means that any hardware failures result in considerable downtime. No recipient verification causes the email gateways to be overloaded with email to people that don’t exist. Open ports and MX back doors allow spam and viruses to bypass the email gateway completely. 4 th box: Spam bounces back to bad sender addresses to invalid recipients and gets stuck in retry queues at the email gateways for days at a time. Queues build up with hundreds of thousands of useless bounced email. 5 th box: End users are plagued with hundreds of useless email porn, phishing attacks, newsletters, schemes, prescription drug, and image based spam. This wastes time and money.
  • 1 st box: Spammers are identified at the source and they are blocked by technologies such as reputation filtering almost before they begin. 2 nd box: Techniques using reverse DNS lookups stop spam from unknown email gateways. DNS black lists (DNSBL) contain lists of addresses linked to spamming. Most mail transport agent (mail server) software can be configured to reject or flag messages which have been sent from a site listed on one or more such lists. 3 rd box: Gateway based clustering and load balancing ensures uptime. Edge Defense for DoS and DHA attacks thwart about 90% of malicious network attacks. Spam filtering removes about 99.5% of remaining spam. Email policies enforce compliance by automatically encrypting email with TLS, S/MIME, PGP, or Secure WebMail. 4 th box: Server based clustering and load balancing guarantees that both inbound and outbound email routes are protected. 5 th box: Offensive email disappears, encryption options are numerous, and compliance is transparent.

Transcript

  • 1. Email Security Overview David Maislin – Director, North American Sales Engineering May 4, 2010
  • 2. Understanding Email
  • 3. Understanding Email COMPOSE SEND TRANSPORT ROUTE DELIVER RECEIVE READ Clients Outlook Notes GroupWise Web Email Other Protocols SMTP: 25 Proprietary Servers Exchange Domino GroupWise AppleMail Gateways Other Protocols DNS: 53 LDAP: 389 SLDAP: 636 AD: 3268 (S)AD: 3269 SMTP: 25 TLS: 25 Routes MX Records or Static IPs Servers Exchange Domino GroupWise AppleMail Gateways Other Clients Outlook Notes GroupWise Web Email Other Protocols POP: 110 IMAP: 143 Proprietary
  • 4.
    • As organizations grow expertise is segregated
    Size Matters S 1-2 Shared Knowledge
    • Email Servers
    • LDAP / AD
    Shared Knowledge
    • Network
    • DNS
    • Firewall
    Shared Knowledge
    • Database
    Internal
    • Antispam
    • Consultant(s)
    • Web Servers
    Outsource M 3-6 Limited Sharing
    • Email Servers
    • LDAP / AD
    Limited Sharing
    • Network
    • DNS
    • Firewall
    Knowledge Expert
    • Database(s)
    Internal
    • Antispam
    • Programmer(s)
    • Consultant(s)
    • Web Servers
    • IT Management
    Outsource L 7-20 Knowledge Expert
    • Email Servers
    • LDAP / AD
    Knowledge Expert
    • Network
    • DNS
    • Firewall
    • Compliance
    Knowledge Expert
    • Database(s)
    Internal
    • Antispam
    • Programmer(s)
    • Consultant(s)
    • Web Servers
    • IT Management
    • Help Desk
    Outsource VS IT Staff: Outsourced
    • Email Servers
    • LDAP / AD
    • Antispam
    • Network
    • DNS
    • Firewall
    • Database
    • Web Servers
    Shared Knowledge
    • Generalist
    1 XL 20-100+ Knowledge Expert
    • Email Servers
    • LDAP / AD
    Knowledge Expert Knowledge Expert
    • Database(s)
    Internal
    • Antispam
    • Programmer(s)
    • Consultant(s)
    • Web Servers
    • IT Management
    • Help Desk
    • Change Control
    Outsource
    • Network
    • DNS
    • Firewall
    • Compliance
  • 5. Understanding Compliance
  • 6. Understanding Major Security & Privacy Regulations
    • HIPAA: Health Insurance Portability & Accountability Act
      • Mandates specific technology standards and policies that healthcare organizations must implement for compliance.
    • GLBA: Gramm-Leach-Bliley Act
      • Forces financial institutions to design, implement and maintain necessary safeguards to protect consumers’ nonpublic personal information.
    • SOX: Sarbanes-Oxley Act
      • Requires public companies to automate their processes of building audit trails and control procedures into their IT systems.
    • CA SB 1386: California Senate Bill 1386
      • A state regulation that requires companies to implement systems to detect and prevent security breaches, as well as provide counter-measures and publicly report breaches
  • 7. Other Regulations
    • SEC 17a-4 and NASD 3010
      • Requires public companies to keep records for auditing security transactions, including review of brokers’ communications with the public
    • FDA 21 CFR Part 11
      • Controls the authenticity, integrity, non-repudiation and confidentiality of electronic records
    • Payment Card Industry (PCI) Data Security Standard
      • Mandates the protection of credit cardholder and account information across public networks
    • USA Patriot Act – Homeland Security
      • Requires companies to build and maintain an infrastructure that can report details of information handled and stored online
  • 8. Email Filtering Compliance Strategy Content-Based Filtering Email Email Sender Receiver Subject Message Attachment Sender Receiver Subject Message Attachment Message Subject Manual Trigger? Send In The Clear Yes No Attachment Regulated Content? Encrypt Yes No Sender Receiver Content-Based Filtering Strategy
  • 9. Email Filtering Compliance Strategy Identity-Based Filtering Email Email Sender Receiver Subject Message Attachment Sender Receiver Subject Message Attachment Who is the sender? Who is the receiver? Designated? Authorized? Encrypt Content Filter Yes No Encrypt Content Filter Yes No Sender Receiver Identity-Based Filtering Strategy
  • 10. Understanding Email Encryption
  • 11. Understanding Email Encryption TLS encrypts the network: server to server encryption S/MIME and PGP can encrypt or sign email: server to server, server to client, client to server, and client to client. Also for authentication purposes Secure WebMail: Stores encrypted email on the server, retrieved by client
  • 12. Email Encryption Methods - TLS
    • TLS: Transport Layer Security
      • Creates a secure connection between email gateways over which any amount of data can be sent securely using SSL. Note: SSL encryption is only in effect when the email is in transit.
      • Gateway to Gateway (company to company) encryption
    • Benefits:
      • Seamless partner to partner encryption
      • Completely transparent to the sender and receiver
    Email Servers Email Gateway Email Servers Email Gateway Internet
  • 13. Email Encryption Methods – S/MIME and PGP
    • S/MIME and PGP
      • Encrypts and decrypts the email body and attachments S/MIME certificates
      • Gateway to Gateway (company to company)
      • Gateway to Client (from your company to an external recipient)
      • Client to Gateway (from external sender to your company)
    • Benefits:
      • Seamless partner to partner encryption
      • Completely transparent to the sender and receiver
      • Automatic harvesting of inbound signing/public certificates
      • Generates proxy certificates for any internal employees via email
      • Proxy encryption and signing
      • Proxy decryption
    Email Servers Email Gateway Email Servers Email Gateway Internet
  • 14. Email Encryption Methods – Secure WebMail
    • Encrypts email and provides access through a secure web portal
      • Gateway to client (from your company to any external recipient)
      • Universal (zero client side software requirements)
      • Online and offline secure email
      • Self registration, zero registration, and automated user management
      • Very large email attachment support
      • Tracking by recipient, by message, and by attachment
      • Delivery profiles for message, inbox, and portal branding
      • Roles for message expiration, password requirements, domain limits, message size, and message quotas.
    • Benefits:
      • No learning curve
      • No client side software
    Email Servers Internet Email notification SSL
  • 15.
    • Employee to Employee Encryption
      • Protects sensitive internal messages to the desktop
      • Provides senders with a “Send Secure” button
      • Solves problems of enrollment, key distribution, authentication
      • Uses S/MIME encryption standards
      • New users receive messages via Web system with links for enrollment
    • Benefits:
      • Adds layer of protection for key internal users
      • External users receive Secure WebMail
      • No change to user paradigm
      • Removes the hassles of managing PKI-based
    Email Encryption Methods – Desktop Messenger Email Servers Email Gateway Sensitive Internal Communication Internet Enrollment Key Mgt Authentication Email notification SSL
  • 16.
    • File Messenger
      • Large files route around email servers
    • Benefits:
      • End users send files with email applications
      • Large files don’t waste space on email servers
      • Track by recipient and attachment
      • Completely secure
      • Uses existing standards based technologies
      • Supports digital signing and encryption using existing email standards
    Messaging Delivery Methods – File Messenger Email Servers Internet Email notification SSL Automatically routes large files
  • 17. Hosted Solutions
    • Hosted solutions present several issues
      • Sensitivity of data
      • Archive and recovery of sensitive email
      • Who is liable if data is lost?
      • Viability and volatility of hosting company
      • Sender and recipient email addresses can be considered identifiers
      • Recipient must sign up with external service to read their confidential data
      • Service may use email address lists for other purposes
  • 18. Steganography
      • The art and science of writing hidden messages in such a way that no one apart from the intended recipient knows of the existence of the message
      • In contrast to cryptography, where the existence of the message itself is not disguised, but the content is obscured. Quite often, steganography is hidden in pictures.
      • Aren’t we trying to block image based spam already?
    A GIF carrier file containing the airport map Original message or attachment
  • 19. Email Encryption – Best Delivery Approaches Business-to-Business Business-to-Consumer Employee-to-Employee Desktop to Desktop Gateway to Desktop Secure Web Delivery Gateway to Gateway Best Practice Best Practice Best Practice Best Practice Who? How?
    • Tips:
    • Seek encryption transparency
    • Select vendor solutions that support industry standards and interoperability
    • Look for vendor solutions that can provide transparency for both outbound and inbound secure email
    • Look to automate the acceptance of customer/member/patient email messages through a Web portal
  • 20. Domain Key Identified Mail (DKIM)
    • Authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs).
    • The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing".
  • 21. Why Do Spammers Send Spam?
  • 22. Malicious Threats - Worldwide
  • 23. Understanding Malicious Threats – Denials of Service Attacks They start attacking from network, from all over the Internet… Denial of Service Attack (DoS) Too many connections from the one IP addresses Distributed Denial of Service Attack (DDoS) Too many connections from the many IP addresses (zombies) Bounce Flood Attack (Smurf) Attacks of networks using spoofed domains, causing email bounces to the intended victim domains
  • 24. Bounce Address Tag Validation (BATV)
    • Bounce Address Tag Validation (BATV) defines a framework for mechanisms that validate the value in the “mail from” command.
    • Header policies can tag the “mail from” header for outbound email
      • MAIL FROM: david.maislin@tumbleweed.com
      • Is transformed to…
      • MAIL FROM: tag=david.maislin=KEY123@tumbleweed.com
      • Where =KEY123 is the Bounce Tag
    • Only accept inbound email bounces with unique tag in “mail from” header
    • Reports can be generated on all BATV violations
  • 25. Understanding Malicious Threats – Directory Harvest Attacks Directory Harvest Attack (DHA) 550 Email Bounce During a directory harvest attack, spammers use brute force against an email server to compile comprehensive lists of valid email addresses to use or sell. Meantime, the plethora of probes overwhelms the email server, creating a denial of service from the vast amount of non-delivery reports the attack generates. [email_address] [email_address] [email_address]
  • 26. Understanding Spamming Techniques
  • 27. Basic Email Network
    • Enterprise threats are typically inbound
    Out of Control Disk Growth Performance Degradation Spam/Viruses inside network No Recipient Validation Email Server(s)
  • 28. Basic ISP Email Network
    • ISPs are completely different
      • Threats are inbound
      • Threats are outbound
      • Threats are domain to domain
    Domain 2 Domain X Domain 1 Internet
  • 29. Recipient Validation Issues
    • Not all invalid recipient email is rejected by all Mail Servers
    • Mail servers can be part of the problem
    • Spam can still get through
    From: "Kim Browne" [akstcbarnhardmnsdgs@barnhard.com] Sent: 11/26/2006 07:49 PM To: bfrederick@company.com Subject: Mississippi catfish Out-milton are different things, though the words are often used synonymously. a person may be proud without"perhaps," said darcy, "i should have judged better, had i sought an introduction; but i am Fuzzy logic sent this email to: [email_address]
  • 30. Some Spam is Hard to Detect
    • Not all email is easily recognized as spam
    • Spammer techniques evolve to bypass filters
    From: "Kim Browne" [akstcbarnhardmnsdgs@barnhard.com] Sent: 11/26/2006 07:49 PM To: bfrederick@company.com Subject: Mississippi catfish Out-milton are different things, though the words are often used synonymously. a person may be proud without"perhaps," said darcy, "i should have judged better, had i sought an introduction; but i am Random phrases containing Nonsense and gibberish
  • 31. Phishing Attacks FAKE REAL
  • 32. The Image Spam Problem
    • Image spam presents a new challenge to spam filters
      • Messages are sent as images instead of text
      • Gibberish text is inserted to fool content filters
      • Image files are randomized to avoid signature detection
    • Spammers alter every possible file attribute to trick filters
      • Changing image size, margins, color shades
      • Adding random noise, “dust” and “speckles”
      • Splitting or breaking images
      • Assembling multiple images into animated GIFs
    • The impact has been significant
      • Spam rates have increased sharply as image spam bypasses many legacy spam filters
      • Most vendors have lacked the ability to view or filter image content
    Growth in Image Spam Quantity Tumbleweed Message Protection Lab, Nov. 2006
  • 33. Image Spam Techniques Gibberish text to fool Bayesian filters Obscure fonts to bypass OCR scanning Randomized pixel “noise” stripes Random dots and “ dust specks” Changing background colors and patterns Shifting text height and position to fool OCR scanning Altering text & background colors and textures
  • 34. Adaptive Image Filtering Use this image… to identify this image ... or this image.
  • 35. Clever spamming techniques
    • Can you spot the difference between these two penguins?
  • 36. Original Image
    • Original Image
    • HTML Table
    • Each table cell represents a colored pixel
    JPG Image 2.97K HTML Table 273K
  • 37. Adaptive Image Filtering Techniques Varying Image Spam ≈ Sample Wavelet Transforms Wavelet Transforms ђэьѓзщҒёҝѕ Signature Query Image Database ђэьѓзщҒёҝѕ ЌχϋУέЫЄИ дҖλЗςұпж ўЫҝЎЉθξӘ Image Signatures New Spam
  • 38. New Breed of Viruses / Malware
    • Rapid spread by zombies and botnets
    • Signature-based approach not keeping up
    • 10 hours to develop signatures vs. 3-7 hours for attacks to peak
    Early days: Typical Viral propagation 0% 20% 40% 60% 80% 100% 0 hr Peak: 6-10 hrs 20 hrs Intensity Short Span attack 0% 20% 40% 60% 80% 100% 0 hr 3-7 hrs Intensity Now: Serial Variants Attack 0% 20% 40% 60% 80% 100% V.1 V.2 V.3 V.4 Variants Release Timeline Intensity
  • 39. Zero-Hour vs. Traditional Anti-Virus
    • Virus Outbreak Production complements
    • Signature-based Antivirus products
    McAfee, Kaspersky signature-based AV Virus Outbreak Protection Within 5-10 hours Within 1-2 minutes Response time Email, Web, IM Email only Services protected Yes Yes Defend Yes No Clean and Repair Scan after updates Block infection Spyware Defense Periodic update of signature pack Real-time pull Update mechanism Heavy load Lightweight CPU Impact Let some through Catch them all Multi-wave attacks
  • 40. The Continuing Fight Against Spammers
    • Effective anti-spam requires expertise, constant adaptation, layering of new techniques
    2 3 4 Content Filtering
    • Lexical Analysis
    • Weighted Word lists
    • Regular Expressions
    • Signature/Hash
    Content Filtering
    • Lexical Analysis
    • Weighted Word lists
    • Regular Expressions
    • Signature/Hash
    Content Filtering
    • Lexical Analysis
    • Weighted Word lists
    • Regular Expressions
    • Signature/Hash
    Behavioral Analysis
    • Heuristics
    • Bayesian
    • Statistical Analysis
    • Message intent - AI
    Behavioral Analysis
    • Heuristics
    • Bayesian
    • Statistical Analysis
    • Message intent - AI
    1998-2002 2002-2004 2005 Pattern Detection
    • Edge Defense
    • Outbreak detection
    • Reputation
    • Recurrent Pattern
    Content Filtering Behavioral Analysis
    • Heuristics
    • Bayesian
    • Statistical Analysis
    • Message intent - AI
    Pattern Detection
    • Edge Defense
    • Outbreak detection
    • IP Reputation
    • Recurrent Pattern
    • Lexical Analysis
    • Weighted Word lists
    • Regular Expressions
    • Signature/Hash
    2007 5 Image Filtering
    • Image Pattern Analysis
    • Adaptive Image Filtering
    • Dynamic Engine Update
  • 41. Common Architectural Deployment Mistakes
  • 42. The Single Box Solution? MX Record: mycompany.com 215.23.3.130 Email Server 192.168.1.125 Firewall 192.168.1.130 Spam Appliance 1 If it can fail, it will! One box, no matter how amazing the architecture is still a single point of failure. Networks can fail too. Remember that email is the most important and ubiquitous application in your company.
  • 43. The Single Box Solution? MX Record: mycompany.com 215.23.3.130 Email Server 192.168.1.125 Firewall Plan for redundancy and failure around hardware and networks! Start with the best hardware and work down, not the cheapest. 192.168.2.130 192.168.1.130 Spam Appliance 1 Spam Appliance 2
  • 44. LDAP Mistakes Email Server 192.168.1.125 Firewall Everything looks great Redundancy is everywhere What could go wrong? 192.168.2.130 192.168.1.110 Service Account Bind Service Account Bind 192.168.1.130 192.168.1.111 Spam Appliance 1 Spam Appliance 2 LDAP 1 LDAP 2
  • 45. LDAP Mistakes Email Server 192.168.1.125 Firewall LDAP account gets locked out Moved LDAP user when bind DN was unique Resetting password is pointless as it will automatically lock again Customer perceives this is as a product issue 192.168.2.130 192.168.1.110 Service Account Bind Service Account Bind 192.168.1.130 192.168.1.111 Spam Appliance 1 Spam Appliance 2 LDAP 1 LDAP 2
  • 46. Network Mistakes Email Server 192.168.1.125 Firewall Recipient validation stopped working Customer blames product States nothing has changed 192.168.2.130 192.168.1.110 LDAP Bind LDAP Bind 192.168.1.130 192.168.1.111 Spam Appliance 1 Spam Appliance 2 LDAP 1 LDAP 2
  • 47. Network Mistakes Email Server 192.168.1.125 Firewall The Firewall rules changed The ISP changed The DNS Changed They are using DNS names instead of IP Address 192.168.2.130 192.168.1.110 LDAP Bind LDAP Bind 192.168.1.130 192.168.1.111 Spam Appliance 1 Spam Appliance 2 LDAP 1 LDAP 2
  • 48. Incompetence - Spam Still Gets Through! Email Server MX Record: mycompany.com 215.23.3.130 192.168.1.125 192.168.1.130 192.168.1.131 192.168.1.132 Firewall Spam Appliance 1 Spam Appliance 2 Spam Appliance 3
  • 49. Solutions Work…. The Email Architecture Does Not Email Server MX Record 1: mycompany.com 215.23.3.130 192.168.1.125 192.168.1.130 192.168.1.131 192.168.1.132 MX Record 2: mycompany.com 215.23.3.125 MX Record 3: isp.mycompany.com 220.1.23.5 WebMail: webmail.mycompany.com 215.23.3.131 Examine All MX Records! Examine All WebMail Ports! Firewall Spam Appliance 1 Spam Appliance 2 Spam Appliance 3 ISP Mail Server
  • 50. The Case of the Nasty NAT Firewall Email Server & WebMail MX Record: mycompany.com 215.23.3.120 Firewall NATs 215.23.3.120 to 192.168.1.125 192.168.1.125 DNS Record: webmail.mycompany.com 215.23.3.120
  • 51. The Case of the Nasty NAT: What Happens to WebMail? Firewall Email Server & WebMail MX Record: mycompany.com 215.23.3.120 Firewall now NATs 215.23.3.120 to 192.168.1.130 192.168.1.125 DNS Record: webmail.mycompany.com 215.23.3.120 192.168.1.130 Spam Appliance
  • 52. The Case of the Nasty NAT: Add Public IP & NAT to WebMail Firewall Email Server & WebMail MX Record: mycompany.com 215.23.3.120 Firewall now NATs 215.23.3.120 to 192.168.1.130 192.168.1.125 DNS Record: webmail.mycompany.com 215.23.3.125 192.168.1.130 It is not always a drop-in appliance solution. It is a consultative approach to solving real world problems Spam Appliance
  • 53. Email Architecture Issues
    • Tiered MX records can cause performance issues
    • Uneven distribution of inbound and outbound email
    • Email queues can backup during email peak periods
    Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Internet Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers SMTP1 SMTP2 SMTP3 SMTP4 SMTP5 SMTP6 SMTP7 SMTP8 MX 10 30% MX 20 20% MX 30 10% MX 40 5% MX 50 5% MX 60 5% MX 70 10% MX 80 15% Datacenter 1 Datacenter 2
  • 54. Load Balancers Deployed, but No Recipient Validation
    • No recipient validation passes mail to email server
    • Some email servers use closest match and some spam makes it through
    • Emails bounce and are processed many times causing extra network traffic, slow performance, quarantining of invalid email, and backup of invalid email
    Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers SMTP1 SMTP2 SMTP3 SMTP4 MX10 50% MX10 50% Load Balancer Load Balancer Internet Datacenter 1 Datacenter 2
  • 55. Load Balancers and Recipient Validation Deployed
    • Recipient validation allows email in for valid recipients only
    • 100% of invalid recipient email dropped at gateway
    • No more email bounces
    • Improved mail server performance, no more quarantining invalid email
    Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Spam Gateway Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers Mail Servers SMTP1 SMTP2 SMTP3 SMTP4 SMTP5 SMTP6 SMTP7 SMTP8 MX10 50% MX10 50% Load Balancer Load Balancer LDAP2 LDAP4 LDAP3 LDAP1 Internet Datacenter 1 Datacenter 2
  • 56. Trends by Content and IP
  • 57. Trends by DNS Black List and IP
  • 58. Trends by Denial of Server and IP
  • 59. Trending Produces Results
  • 60. IP Layer Blocking
    • Trends occur by IP address
    • Permanently block ranges of IP addresses at the network layer
    • No need to ever scan content when a connection can’t be made
    • Spammers can’t circumvent IP blocks
  • 61. Inbound Email Best Practices – Before Spam, phishing, viruses, DoS, and DHA attacks sent from all over the Internet. No recipient verification causes email bounces. These emails clog up queues on some relays while leaving others completely idle. With no redundancy and no load balancing, hardware failures will result in considerable downtime Spam bounces cause queues to build up with useless NDR bounced emails End user and email administrator time is wasted with unwanted emails and countless help desk calls.
  • 62. Inbound Email Best Practices – After Spammers are identified at the source and blocked by real-time messaging technologies and reputation filters. Server-based clustering and load balancing guarantees that both inbound and outbound email routes are protected Offensive emails disappear, encryption options are numerous, and compliance is transparent. Recipient verification, reverse DNS lookups, anti-spam technologies and trend analysis put an end to spam. Gateway based clustering and load balancing ensures uptime
  • 63. Questions?