<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:admin="http://webns.net/mvcb/"
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
		<title>John Levine &#45; CircleID</title>
		<link>http://www.circleid.com/</link>
		<description>Postings from John Levine on CircleID</description>
		<dc:language>en</dc:language>
		<dc:rights>Copyright 2012, unless where otherwise noted.</dc:rights>
		<dc:date>2012-02-07T07:03:00-08:00</dc:date>
		

		
		<item>
			<title> Phish or Fair? (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/phish_or_fair</guid>
			<link>http://www.circleid.com/posts/phish_or_fair</link>
			<description><![CDATA[It shouldn't be a big surprise to hear that phishing is a big problem for banks. Criminals send email pretending to be a bank, and set up web sites that look a lot like a bank. One reason that phishing is possible is that e-mail has no built in security, so that if a mail message comes in purporting to be from, say, accounts@bankofamerica.com, there's no easy way to tell whether the message is really from bankofamerica.com, or from a crook. <a href="http://www.circleid.com/posts/phish_or_fair">More...</a>]]></description>
			<dc:date>2012-02-07T07:03:00-08:00</dc:date>
		</item>
		
		<item>
			<title> World Notices That Verisign Said Three Months Ago That They Had a Security Breach Two Years Ago (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20120202_world_notices_verisign_said_3_months_ago_they_had_security_breach</guid>
			<link>http://www.circleid.com/posts/20120202_world_notices_verisign_said_3_months_ago_they_had_security_breach</link>
			<description><![CDATA[The trade press is abuzz today with reports about a security breach at Verisign. While a security breach at the company that runs .COM, .NET, and does the mechanical parts of managing the DNS root is interesting, this shouldn't be news, at least, not now. Since Verisign is a public company, they file a financial report called a 10-Q with the SEC every quarter. According to the SEC's web site, Verisign filed their 10-Q for June through September 2011 on October 28th. <a href="http://www.circleid.com/posts/20120202_world_notices_verisign_said_3_months_ago_they_had_security_breach">More...</a>]]></description>
			<dc:date>2012-02-02T18:48:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The State of Mail Database Marketing (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/the_state_of_mail_database_marketing</guid>
			<link>http://www.circleid.com/posts/the_state_of_mail_database_marketing</link>
			<description><![CDATA[My mail server has a lot of spamtraps. They come from various sources, but one of the most prolific is bad addresses in personal domains. Several of my users have their own domains, such as my own johnlevine.com, in which they use a handful of addresses. Those addresses tend either to be people's first names, for individual mailboxes, or else the names of companies. If I did business with Verizon (which I do not) I might give them an address like verizon@johnlevine.com. All those domains get mail to lots of other addresses, which is 100% spam. <a href="http://www.circleid.com/posts/the_state_of_mail_database_marketing">More...</a>]]></description>
			<dc:date>2012-01-28T16:15:01-08:00</dc:date>
		</item>
		
		<item>
			<title> Filtering Spam at the Transport Level (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20111227_filtering_spam_at_the_transport_level</guid>
			<link>http://www.circleid.com/posts/20111227_filtering_spam_at_the_transport_level</link>
			<description><![CDATA[An interesting new paper from the Naval Postgraduate School describes what appears to be an interesting new twist on spam filtering, looking at the characteristics of the TCP session through which the mail is delivered. They observe that bots typically live on cable or DSL connections with slow congested upstreams. ... This paper tries to see whether it would be practical to use that info to manage spam in real time. <a href="http://www.circleid.com/posts/20111227_filtering_spam_at_the_transport_level">More...</a>]]></description>
			<dc:date>2011-12-27T08:40:00-08:00</dc:date>
		</item>
		
		<item>
			<title> Greylisting Still Works - Part II (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/greylisting_still_works_part_ii</guid>
			<link>http://www.circleid.com/posts/greylisting_still_works_part_ii</link>
			<description><![CDATA[In my last post I blogged about greylisting, a well-known anti-spam technique for rejecting spam sent by botnets. When a mail server receives a an attempt to deliver mail from an IP address that's never sent mail before, it rejects the message with a "soft fail" error which tells the sender to try again later. Real mail senders always retry, badly written spamware often doesn't. I found that even though everyone knows about greylisting, about 2/3 of IPs don't successfully retry. <a href="http://www.circleid.com/posts/greylisting_still_works_part_ii">More...</a>]]></description>
			<dc:date>2011-12-09T12:54:00-08:00</dc:date>
		</item>
		
		<item>
			<title> Greylisting Still Works - Part I (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/greylisting_still_works_part_i</guid>
			<link>http://www.circleid.com/posts/greylisting_still_works_part_i</link>
			<description><![CDATA[Greylisting is a hoary technique for rejecting spam sent by botnets and other poorly written spamware. When a mail server receives an attempt to deliver mail from a hitherto unseen sending host IP address, it rejects the message with a "soft fail" error which tells the sender to try again later. Real mail software does try again, at which point you note that the host knows how to retry and you don't greylist mail from that IP again. <a href="http://www.circleid.com/posts/greylisting_still_works_part_i">More...</a>]]></description>
			<dc:date>2011-12-09T12:53:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The Mainsleaze Blog (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20111018_the_mainsleaze_blog</guid>
			<link>http://www.circleid.com/posts/20111018_the_mainsleaze_blog</link>
			<description><![CDATA[<em>Mainsleaze</em> is nerdy slang for spam sent by large, well-known, otherwise reputable organizations. Although the volume of mainsleaze is dwarfed by the volume of spam for fake drugs, account phishes, and Nigerian 419 fraud, it causes work for mail managers far out of proportion to its volume... The problem with mainsleaze is that it is generally mixed in with mail that the recipients asked for, and there's no way to tell the difference mechanically. <a href="http://www.circleid.com/posts/20111018_the_mainsleaze_blog">More...</a>]]></description>
			<dc:date>2011-10-18T09:58:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The Design of the Domain Name System, Part VIII - Names Outside the DNS (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_viii_names_outside_the_dns</guid>
			<link>http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_viii_names_outside_the_dns</link>
			<description><![CDATA[In previous installments we've been looking at aspects of the design of the DNS. In today's grand finale we look at the the subtle but very knotty issue of names inside and outside the DNS. In the early years of the DNS, domain names were typically resolved to A records which were used to identify a host running a service. With the notable exception of e-mail, once the host was identified, the name no longer mattered. <a href="http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_viii_names_outside_the_dns">More...</a>]]></description>
			<dc:date>2011-09-17T20:11:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The Design of the Domain Name System, Part VII - Related Names Are Not Related (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_vii_related_names_are_not_related</guid>
			<link>http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_vii_related_names_are_not_related</link>
			<description><![CDATA[In previous installments we've been looking at aspects of the design of the DNS. Today we look at the relationship of similar names in the DNS. A poorly appreciated aspect of the DNS is that there is no inherent relationship between similar looking names. <a href="http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_vii_related_names_are_not_related">More...</a>]]></description>
			<dc:date>2011-09-06T09:10:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The Design of the Domain Name System, Part VI - Overloaded Record Types (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_vi_overloaded_record_types</guid>
			<link>http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_vi_overloaded_record_types</link>
			<description><![CDATA[In the five previous exciting installments, we've been looking at aspects of the design of the DNS. Today we look at records types, and how you can tell what a DNS record means. All the records in the DNS are strongly typed. Each record includes an RRTYPE, a small number, which defines both the format of the record and what the record means. It is possible and common to have different record types with the same format, but different meanings. <a href="http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_vi_overloaded_record_types">More...</a>]]></description>
			<dc:date>2011-09-05T08:14:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The Design of the Domain Name System, Part V - Large Data (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_v_large_data</guid>
			<link>http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_v_large_data</link>
			<description><![CDATA[In the previous four installments, we've been looking at aspects of the design of the DNS. Today we look at the amount of data one can ask the DNS to store and to serve to clients. Most DNS queries are made via UDP, a single packet for query and a single packet for the response, with the packet size traditionally limited to 512 bytes. This limits the payload of the returned records in a response packet to about 400 bytes... <a href="http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_v_large_data">More...</a>]]></description>
			<dc:date>2011-09-01T09:25:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The Design of the Domain Name System, Part IV - Global Consistency (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_iv_global_consistency</guid>
			<link>http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_iv_global_consistency</link>
			<description><![CDATA[In the previous installments, we've been looking at aspects of the design of the DNS. Many databases go to great effort to present a globally consistent view of the data they control, since the alternative is to lose credit card charges and double-book airline seats. The DNS has never tried to do that. The data is roughly consistent, but not perfectly so. <a href="http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_iv_global_consistency">More...</a>]]></description>
			<dc:date>2011-08-29T07:27:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The Design of the Domain Name System, Part III - Name Structure and Delegation (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_iii_name_structure_and_delegation</guid>
			<link>http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_iii_name_structure_and_delegation</link>
			<description><![CDATA[In the previous installments, we looked at the overall design of the DNS and the way DNS name matching works. The DNS gains considerable administrative flexibility from its delegation structure. Each zone cut, the place in the DNS name tree where one set of DNS servers hands off to another, offers the option to delegate the administration of a part of the DNS at the delegation point. <a href="http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_iii_name_structure_and_delegation">More...</a>]]></description>
			<dc:date>2011-08-26T10:50:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The Design of the Domain Name System, Part II - Exact and Approximate Name Matching (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/design_of_the_domain_name_system_part_ii_exact_approximate_name_matching</guid>
			<link>http://www.circleid.com/posts/design_of_the_domain_name_system_part_ii_exact_approximate_name_matching</link>
			<description><![CDATA[In the previous installment, we looked at the overall design of the DNS. Today we'll look at the ways it does and does not allow clients to look up data by name. The most important limitation of the DNS, compared to other databases, is that it only does exact match lookups. That is, with a few minor exceptions, the name in the query has to match the name of the desired records exactly. <a href="http://www.circleid.com/posts/design_of_the_domain_name_system_part_ii_exact_approximate_name_matching">More...</a>]]></description>
			<dc:date>2011-08-23T06:33:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The Design of the Domain Name System, Part I (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_i</guid>
			<link>http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_i</link>
			<description><![CDATA[Over the past 30 years the Domain Name System has become an integral part of the operation of the Internet. Due to its ubiquity and good performance, many new applications over the years have used the DNS to publish information. But as the DNS and its applications have grown farther from its original use in publishing information about Internet hosts, questions have arisen about what applications are appropriate for publication in the DNS, and how one should design an application to work well with the DNS. <a href="http://www.circleid.com/posts/the_design_of_the_domain_name_system_part_i">More...</a>]]></description>
			<dc:date>2011-08-22T07:22:00-08:00</dc:date>
		</item>
		
	</channel>
</rss>
