Square whole can be voguish and have indulge you through

I’d generally find it tedious to post my spam here. And, certainly, bad grammar in spam is nothing new. But... well, this just has some of the most amazingly bad grammar and eccentric capitalization that I’ve ever seen, and I just couldn’t resist:

Dear Winner

We Apologies, for the delay of your payment and all the Inconveniences And Inflict that we might have indulge you through.

However, we are Having some minor problems with our payment system, this is Inexplicable, And have held us stranded and Indolent, not having the Aspiration to devote our 100% Assiduity in accrediting foreign payments.We Apologies once again from the Records of outstanding winners due for payment With {ABV CYBER PROMOTION} your name and Particular was discovered as next on the list of the outstanding winners who are Yet to received their payments.

Emails were selected anonymously through a Computer ballot system from over 35,000 companies and 70,000 individual E-mail addresses all over the world and your e-mail address emerged as the winner of the 11 selected emailaddress. This program is promoted and sponsored by Orient software corporation (Orient Networks) in collaboration with The Abv Cyber International.

I wish to inform you now that the square peg is now in Square whole and can be voguish for your payment is being processed and will be released to you as soon as you respond to this letter. Also note that from our record in our File, your outstanding winning payment is $950.215.00 (NINE HUNDRED AND FIFTY THOUSAND, TWO HUNDRED AND FIFTEEN DOLLARS).Payment will be made to you in a certified bank draft or wire transfer into a nominated bank Account of your choice, as soon as you get in touched with.

There follows the name, phone number (in England), and email address of the person with whom I’m meant to get in touched (there’s no postal address, of course). So I guess I’d better be voguish right away, lest the square peg fall out of Square whole before I do.

How not to fight spam

There’s been a discussion on the IETF working group chairs mailing list about some of the criteria that are used to look for spam sent to IETF mailing lists. In particular, the IT department is using these four rules:

1. Check that the HELO hostname has an A or MX record, defer if not.
2. Check that the client IP address maps to a name; defer if not.
3. Check that that name maps back to an IP address; defer if not.
4. Check that the name-to-address mapping matches the client IP; defer if not (that is, check that steps 2 and 3 give consistent results).

There are some current cases where these rules are blocking legitimate posts to the mailing lists, and the discussion is about whether these rules are reasonable. I’ve sent the comments below as my contribution to the discussion, and I’m posting them here too, because they lead up to a significant point about how we fight spam.

The HELO command, in an SMTP email session, serves only to start the session and to identify the sending domain for the log file. The domain that’s given there is used for nothing — nothing at all. It’s easy to think that it’s reasonable to at least make sure that it’s a valid domain for sending mail from (the purpose of test 1, above), but the reality is that it can be bypassed by putting any domain at all there. I can send email and use HELO whitehouse.gov and the receiving mail server will be happy.

There’ve been proposals to validate the sending server’s authority to use that domain (CSV, for example), and to actually use the domain for some purpose, such as checking it against a whitelist or blacklist. But unless it’s both validated and used, there’s no value in doing the DNS check.

When a legitimate user at example.com sends email to the IETF, it will usually be a dedicated email server that makes the connection and transmits the mail. Let’s say that server is email1.example.com, and that its Internet address (IP address) is 2.4.68.1. The IETF mail server will see that the connection came from 2.4.68.1, and step 2 will resolve that to email1.example.com. Step 3 will then resolve the name back to the IP address, and step 4 will confirm that it got that same 2.4.68.1 back. That’s fine.

But if mail is sent illegitimately, by some user within example.com, bypassing the normal mail servers — common if spam is sent by an infected zombie computer — it’s possible that one or both of the DNS resolutions in 2 and 3 will fail.

That’s the theory, anyway. The practice is that the transient IP addresses that are usually assigned to users’ computers often do resolve in DNS... and small domains often don’t have all their computers listed (they aren’t expecting people to want/need to resolve them), so they wind up as false positives and get their mail blocked.

And step 4 just seems odd. If the DNS resolutions work in 2 and 3, a failure in 4 would most likely indicate a configuration error, rather than a “bad guy”. It seems strange to use a check like that to block mail. Can that really be catching any spam?

All of these checks seem wrong to me as currently implemented. And in general, I think it’s a bad idea to use anti-spam techniques that address current spammer tactics that are easily changed once the spammers are aware of what we’re doing. It’s rather like rejecting mail that contains certain keywords: the spammers just start misspelling the words. We long ago learned that that’s a pointless skirmish, and that we need to fight more strategic battles.

Conference on Email and AntiSpam (CEAS) call for papers, deadline extended

The 2008 Conference on Email and Anti-Spam submission deadline is approaching, and has been extended by a week, to 10 April. If you have any work to report on in the area of Internet messaging abuse and its prevention — not limited to email spam; see the topic list in the CfP, below — please form it into a paper by next week, and submit it.

---

THE FIFTH CONFERENCE ON EMAIL AND ANTI-SPAM (CEAS 2008)

Thursday August 21 and Friday August 22, 2008
Microsoft Research Silicon Valley
Mountain View, California
<http://www.ceas.cc>

FINAL CALL FOR PAPERS
 

The Conference on Email and Anti-Spam (CEAS) invites the submission of papers for its fifth meeting. Papers are invited on all aspects of electronic communication including email, instant messaging, text messaging, and voice over internet protocol (VoIP). Topics of interest include novel applications of electronic messaging, abatement of abuses of electronic messaging, spam, spit (spam over internet telephony), spim (spam over instant messenger), phishing, identity theft via messaging, viruses, and spyware.

Paper submissions can be either research papers, extended abstracts, industry reports, or law and policy papers. Submissions from practitioners and vendors are encouraged. Papers will be selected by peer review for presentation at CEAS 2008. Papers will be reviewed based on their contribution to the literature.

SUGGESTED TOPICS:

• Message filtering, blocking, authentication
  • Machine learning
  • Natural language processing
  • Adversarial learning
  • Challenge-response
  • Payment schemes
  • Disposable addresses
  • Messaging protocols
  • Digital signatures
• Evaluation
  • Corpus and benchmark creation
  • Measures and methodologies
  • Comparative tests of methods or products
• Analysis
  • Economics of spam, spit, spim, phishing, etc.
  • Abuse tactics and patterns
  • Legitimate use patterns
  • Historical data
• Message organization and search
  • Advanced calendaring and scheduling
  • Automatic foldering
  • Automatic routing
  • Summarization
  • Search
• Systems and network issues
  • Performance & scalability
  • Reliability & security
  • Archival & retrieval
• User issues
  • User interfaces
  • Usability studies
  • Messaging in support of user activities
• Social issues
  • Deducing social networks
  • Costs and benefits of messaging use and abuse
  • Other social impacts
• Industry
  • Cooperation for stopping abuse
  • Messaging and abuse reporting standards
  • Interoperability
• Legal issues
  • Spam, spit, spim and phishing, etc.
  • Identity theft
  • Privacy
  • Freedom of speech
  • Digital rights management

KEY DATES:

• Submission deadline: April 10, 2008 (10:59pm UTC) — EXTENDED DATE
• Notification of acceptance: June 6, 2008.
• Final camera-ready version of papers: June 21, 2008
• Conference: August 21 and 22, 2008

REQUIREMENTS:

Papers may be of one of two types:

• Extended abstracts (up to 2 pages) may outline work in progress, exceptional papers published for different scientific communities, original research, or industry reports.
• Full papers (up to 10 pages). Work may not have been previously published in, or under consideration for publication in any other conference or journal.

Submissions must use the CEAS electronic system at https://cmt.research.microsoft.com/CEAS2008/. The style for submissions and final papers is a two-column, 8.5 by 11 inch format. See http://www.ceas.cc/2008/format.htm for details.

Papers will be reviewed by a committee of experts from academic and industrial research centers. Accepted papers will be made freely available on the web, and will be published on CD-ROM. Authors will retain copyright of their work.

CONTACT:

• The conference chair and co-chairs can be reached at information@ceas.cc

CEAS PRESIDENT:

• Gordon Cormack
  University of Waterloo
  http://plg.uwaterloo.ca/~gvcormac/

GENERAL CONFERENCE CHAIR:

• Aleksander Kolcz
  Microsoft Live Labs
  http://ir.iit.edu/~alek/

PROGRAM CO-CHAIRS:

• Andrej Bratko
  Jozef Stefan Institute
  http://ai.ijs.si/andrej/
   
• Barry Leiba
  IBM Research
  http://www.research.ibm.com/people/l/leiba/
   
• Tobias Scheffer
  Max Planck Institute for Computer Science
  http://www.mpi-inf.mpg.de/~scheffer/
   

Is CAN-SPAM useless?

Earlier this month, the famous spammer Alan Ralsky was indicted for his fraudulent email, using anti-fraud laws as well as the CAN-SPAM Act of 2003.

A man described as one of the nation’s most prolific senders of spam e-mail was among 11 people accused in a federal indictment of defrauding people by manipulating Chinese stock prices.

The man accused, Alan Ralsky, 52, of West Bloomfield Township, Mich., made about $3 million through the scheme in the summer of 2005 alone, a United States attorney, Stephen Murphy, said.

A 41-count indictment accuses Mr. Ralsky and other defendants of sending tens of millions of e-mail messages to computers worldwide, trying to inflate prices for Chinese penny stocks. The defendants then sold the stocks at inflated prices, Mr. Murphy said.

His lawyer, Philip Kushner of Cleveland, told The Detroit News that Mr. Ralsky would fight the charges.

Here’s a New York Times article about Alan Ralsky from when the CAN-SPAM Act was signed into law. At the time, he had this to say:

He stopped sending e-mail offers for everything from debt repayment schemes to time-share vacations even before President Bush, on Dec. 16, signed the new Can Spam Act, a law meant to crack down on marketers like Mr. Ralsky.

He plans to resume in January, he said, after he overcomes some computer problems, and only after he changes his practices to include in his messages a return address and other information required by the law, the title of which stands for Controlling the Assault of Non-Solicited Pornography and Marketing.

That is quite a switch for Mr. Ralsky, who has earned a reputation as a master of cyberdisguise. By his own admission, he once produced more than 70 million messages a day from domains registered with fake names, largely by way of foreign countries — or sometimes even by way of hijacked computers — so that the recipients could not trace the mail back to him.

Most experts in junk e-mail, known as spam, have dismissed the new federal law as largely ineffectual. And many high-volume e-mailers say the law may even improve the situation for them because it wipes away a handful of tougher state laws.

But Mr. Ralsky, who lives in a Detroit suburb, says the law’s potential penalties — fines of up to $6 million and up to five years in jail — are making him rethink his business.

“Of course I’m worried about it,” he said after the law was signed. “You would have to be stupid to try to violate this law.”

This isn’t the first time CAN-SPAM has been used in a criminal indictment. But John Levine, one of those “experts in junk e-mail”, comments on the indictment, questions whether CAN-SPAM is really of any use here:

The thing that strikes me about this indictment is that although it includes a lot of CAN SPAM charges, everything Ralsky and Co. did was already illegal under conventional fraud and computer tampering laws. Lying about who you are to tout worthless stock is already illegal, hijacking other people’s computers is illegal, and collecting the money for fraudulent actions is illegal, too. Sure, they’re throwing the book at them for CAN SPAM violations about fraudulent mail headers and domain registrations, but by my reading, they’d have just as strong a case without CAN SPAM, and the conventional charges will be a lot easier to explain to a judge and a jury.

So it’s a relief that Ralsky, who spent the better part of a decade as the country’s highest profile spammer, is finally headed back to jail. (He’s been there before, for insurance fraud.) But it’s yet another reminder that the US needs effective anti-spam laws, and CAN SPAM isn’t one.

So what are the problems with CAN-SPAM that limit its usefulness? Is it of any use at all?

The principal problem with CAN-SPAM is the most obvious one: it sets up what we call an “opt out” system. It requires email marketers to identify themselves in their messages, and to provide working “unsubscribe” mechanisms. That allows you to “opt out” of future email for that vendor. But such a system means that anyone is legally allowed to send you unsolicited junk email until you opt out. There are some major problems with such a system:

1. Something where spam is allowed by default is clearly not what most users want nor expect. That might be different if most spam were, say, coupons for the local store. But as long as most of it offers to make you a monster in bed or help you get rich with bogus stock tips, an opt-in system is a better answer.
2. Most people are afraid to use the opt-out mechanisms, and with good reason. We’ve been told that responding to spam in any way will only prove that they have a live address and will get you more spam, not less. Even if that’s not so true these days, there are reasons not to try unsubscribing. The ones that tell you to reply to the email message will wind up spamming an innocent party, if the spam is (illegally) using a bogus reply address. The ones that use a web site often have the site set up with software to turn your computer into a “zombie”, if you don’t have the right security patches installed. It’s usually not worth the risk.
3. Even if you do try to unsubscribe, the sender has 10 days to legally continue sending you spam before it has to stop. That might have been necessary in the past, with paper-mail systems, but there’s no good reason to give them that long now. All this stuff is on computers, after all.
4. After you’ve opted out, the senders can use any number of excuses to put you back in. Most commonly, every time you contact the company, they’ll re-subscribe you to all their garbage and you’ll have to opt out all over again. We, the consumers, can help that situation by refusing to do business with companies that do that. But that’s hard, because it’s not usually most people’s priority, and we often don’t know they’ve done it until a while afterward.
5. Email provides “plausible deniability” of receipt. An opt-out system that works by email and that doesn’t send a confirmation can easily be repudiated in court. “Oh, yes, our opt-out system works — here’s proof of that. We probably just never received these requests because of block lists or spam filtering or whatever.” There are, of course, ways to counter those arguments, but it makes it harder to prove, and it makes it a great deal harder to explain to juries of non-technical people.
6. Even though there are clearly stated rules for legal use, any system that allows spamming by default makes it easier for illegal use to get by. Imagine if the law said that you could walk into a store and steal any item valued under $10, unless the store explicitly told you not to. Each store would have to tell each person this, individually. It’d be an impossible mess, and thieves could get away with ignoring the law because of the confusion.

The European Union laws, in contrast, use opt-in provisions — companies may not send you advertising by email unless you explicitly ask for it. Australia’s law works that way too, and it’s often held up as one of the best anti-spam laws in the world. It forbids companies from automatically opting you in under many circumstances, and that sort of thing.

The situation in the U.S. is as it is, of course, because of industry lobbying. There are organizations, such as the Direct Marketing Association, that try to foster proper use of email for marketing, but they’re only giving advice to members, and, however well intentioned they may be, they’re still pushing hard for the retention of opt-out rules.

There are other things wrong with CAN-SPAM, going into details of the definitions and the specifications of what is and isn’t allowed, and I won’t talk about those details here. But as John Levine points out, even when we apply CAN-SPAM, the things it's forbidding are often illegal already under other anti-fraud statutes. And one of the major criticisms of CAN-SPAM when it was passed was that it invalidated a number of state laws that were stricter, broader, and cleaner.

So is there anything good about CAN-SPAM? Well, there’s one, at least, and Mr Ralsky referred to it back in 2003. Repeating the point:

But Mr. Ralsky, who lives in a Detroit suburb, says the law’s potential penalties — fines of up to $6 million and up to five years in jail — are making him rethink his business.

What CAN-SPAM adds to a fraud prosecution is the possibility of stronger penalties. That was meant as a deterrent, though it’s clearly not effective as such. Mr Ralsky might, therefore, get a stiffer prison term and a higher fine, additional penalties prescribed by CAN-SPAM beyond what the fraud charges alone would bring.

But in the end, John’s right when he says that we need more effective anti-spam laws in this country. Something modelled on Australia’s law would be nice.

IETF 70, Vancouver

As I said the other day, I’ve been at the 70th IETF meeting in Vancouver, BC, Canada. As usual, here’s my summary of the meeting, hidden below the “click here if you want to read the boring, geeky bits” link. I’m going to try to keep this shorter than usual. Some of the items will just be notes, rather than complete sentences. But it’s still pretty long.

Read the rest of the post...

Apparea — Applications Area general meeting

1. Announcement of Applications Area workshop, 11/12 Feb 2008.
2. Suggestion of Applications Area interoperability testing events — perhaps a full day of interop testing attached to an IETF meeting.
3. Request for a utf-8 advisor for the nfsv4 working group.
4. Brief discussion of question of identity-based encryption (IBE) and user authentication in email protocols. Issue will be discussed further by interested parties at the bar later.
5. Discussion of BCP 56 (RFC 3205): is this still the best current practice? Specifically, advice that new services should not reuse existing ports, contrasted with the use of http/80 for many non-web-browsing purposes. Conclusion: BCP 56 was meant to make sure people think about these things before they choose. It should stand, though maybe an update would be useful.
6. Presentation of a metadata format for files (see draft-garcia-sipping-file-*).
7. Presentations from netconf participants (Operations and Management Area) about a modeling language. One presentation using XML schemas. Second presentation of a homegrown modeling language called YANG. There was extensive discussion, and some heat. Ultimate question: “If we did a bof with YANG documents and other docs (XSD based), do people think we should do that?” Strong consensus in favour.

Sieve Mail Filtering Language

1. Document status: base doc is un-stuck (had been waiting for internationalization draft), and this frees a bunch of others.
2. Document status: body, notify, notify-mailto, notify-xmpp are in IESG processing.
3. Document status: edit header, mime loops, refuse/reject, regex are still being worked on.
4. Discussion of notify: have to sort out IANA registry issues. Decision to use RFC 2434, and refer to it.
5. Discussion of notify-mailto: Discussion of mail loop issues. Prefer to have a separate document, not from this WG, on mail loop detection and avoidance. Ackowledge that this doc will block on that. Discussion of using null MAIL FROM here. Discussion of not retaining Received headers in notification message.
6. Discussion of IMAP-Sieve (lemonade doc): Main issue is per-user scripts. Probably move to extension, probably leave the feature for delivery scripts, not IMAP-event scripts.
7. Brief discussion of other docs, no substantial issues.

Calsify — Calendaring and Scheduling Standards Simplification

1. 2445bis is in PROTO-shepherd review. One issue: is it OK to have RDATE < DTSTART ? Decision to take the issue back to the mailing list.
2. 2446bis (iTIP) issues discussion. Some small items.
3. Major discussion on RANGE parameter with day changes in recurring meetings.
4. Major discussion on SEQUENCE number — what its purpose is and how it’s used.

HTTPbis — HTTP updates

There were two HTTPbis sessions, but the second one conflicted with DKIM, so I missed it.

1. Presentation of HTTP history and lessons learned.
2. Charter review. Aiming to bring HTTP to “Draft Standard” status.
3. Discussion of the partitioning of the document into 8 parts.
4. Discussion of issues...
5. Loooooooooong discussion on ABNF conversion and logical whitespace (LWS) in ABNF for headers.
6. Some discussion of header-value internationalization. Decision: document reasonable RFC 2047 usage explicitly.
7. Brief discussion of character encoding defaults — existing language conflicts with MIME specifications. Noted that “guessing” is the best mechanism in practice, but someone pointed out that guessing wrong can cause problems that include security exposures.
8. Out of time, remaining items left for second session:
   • ETag in status messages
   • Clarify “requested variant”
   • Header line folding
   • Content negotiation for media types
   • Repeating single-value headers

IPR — Intellectual Property Rights

This session moved right along and ended early. The documents are essentially done, discussion wrapped up the remaining issues, and set us up for closing the working group. There were three proposals for new work; two were soundly rejected, the third had agreement that it should be pursued as an individual submission.

DKIM — Domain Keys Identified Mail

Tony Hansen and Murray Kucherawy presented the results of a DKIMinteroperability workshop that was recently held in the Dallas area.20 companies and organizations participated, and the interoperabilityresults were generally very good. A few minor issues were uncovered:edge conditions in the “relaxed” canonicalization algorithm, an ABNFerror, and similar things. We will submit errata to correct most ofthese issues, and add text to the “deployment” document for some others.

Jim Fenton presented a status update on the SSP draft, giving a reviewof recent changes and going over the open issues. Jim used quotes fromtwo “customers” early in his presentation, which prompted Dave Crockerto comment, and there was some significant discussion of theappropriateness of optimism in this regard, of some aspects of the SSPdraft that Dave considers wrong, and of Dave’s review of SSP, which he’dposted to the DKIM and Apps-Review mailing lists earlier that day. Further discussion of the review has been taken to the DKIM list (andthat discussion has already been quite active).

On the open issues: there was some discussion here and there, but a lotof discussion on one issue in particular: #1399: Clarify i= vs. SSP,“...need to provide the exact semantics in SSP of how a receiverdetermines whether a DKIM signature satisfies the SSP criteria or not.” The result of the discussion is that the chairs think we need one moreround, no more than a week, of discussion on the mailing list before wedetermine a closure for this issue.

We plan to start working-group last call after issue 1399 is closed andafter discussion has finished on Dave Crocker’s comments.

Doug Otis presented a (non-WG) draft, “DKIM Third-Party Authorizationfor Sender Signer Practices”.

Murray Kucherawy presented (non-WG) drafts dealing with passingauthentication results down the line (including all the way to the MUA). There was brief discussion about his draft for using an ESMTP extensionto pass the information, in order to reduce attacks against MUAs behindnon-compliant MTAs.

Tony Hansen presented a very drief status report (and call for reviews)on the Overview document and the new spin-off, Deployment andOperations.

EAI — Email Address Internationalization

1. UTF8headers doc:
   • Issue with specificatin of NO-WS_CTL. Decision to refer to 2822, note upcoming 2822bis.
   • Issue with normalization. Decision to refer to draft-klensin-net-utf8.
2. Core docs (UTF8headers, DSN, SMTPext) now ready to go to IESG.
3. Downgrade doc:
   • Issue with simple downgrade procedure. Decision that current section 8.1 is adequate.
   • Suggestion to split appendix A into a separate doc. Take discussion to the mailing list.
   • Needs review by people who have implemented it, then it’s ready for working-group last call.
4. IMAP and POP docs
   • Should we move “upgrading” — conversion up to UTF-8 — to clients, and remove it from here? Clients are better equipped to do whatever conversions are necessary, and clients know what they want. Also, conversion breaks message signatures. Consensus to remove, let clients do it.
   • Current IMAP draft uses lemonade “ENABLE” IMAP extension.
   • Switch POP to use UTF-8 “mode”, like IMAP, instead of duplicating commands? Decision: yes.
5. Discussion of whether “mailto” URL should be adopted now. Take to the mailing list.
6. Discussion of possible interoperability tests at one of the next IETF meetings.

lemonade — Enhancements to Internet email to Support Diverse Service Environments

1. Report on second interoperability event. Good results; things that were found broken at the first event have since been fixed.
2. Mostly covered document status and minor updates.
3. Some significant discussion on CONVERT, NOTIFY, and ENABLE.
4. Most of the discussion of ENABLE involved when it was allowed. Decision: only in authenticated, non-selected state.
5. Brief review of profile-bis status.

SAVI — Source Address Validation Improvements BOF

Problem statement: IP source addresses can be spoofed. Packet delivery is based only on destination addresses, to the spoofed traffic arrives, and hurts (attacks/threatens) the destination. It’d be nice to stop the spoofing, and existing solutions aren’t sufficient.

There are product solutions for ipv4, sold by Cisco and others, that work within a single switch. The working group wants something standard.

The trouble, as I see it, is that the charter is too limited:

Specifically, the group shall define solutions such that hosts attached to the same router cannot spoof each other’s addresses. The following assumptions apply:

• The WG considers only solutions on layer-3-aware Ethernet switches
• Two solutions are needed, one for IPv4 and another one for IPv6
• The IPv4 solution depends on tracking the DHCP traffic on a port
• The IPv6 solution depends on tracking the Neighbor Discovery and DHCP traffic on a port
• All address assignment mechanisms in IPv6 need to be supported, including stateless, stateful, privacy, and so on
• The solutions are turned on for host ports by configuration, and do not apply to routers

The WG recognizes anti-spoofing deployment efforts, motivation, and best practices development in various forums around the world (including RIPE). The WG is only chartered to deliver two specific solution components that such efforts could employ. The bigger questions are out of scope.

Normally, I would worry that a charter were too broad, but this just doesn’t seem to solve a problem that I think needs a standards-track IETF solution. Any company can already sell a switch with anti-spoofing technology in it. Another company can sell another, with different technology. There’s no issue of interoperability that I can see. The most I can see a need for is a BCP to tell hosts what to do to avoid running afoul of existing anti-spoofing techniques. If there’s a need for a WG to do that, OK (but I’m not convinced). But I really don’t see a standards-track issue here.

CSI — Cga & Send extensIons BOF

I have little to say about this. They have a solid idea of what they want to do, and a good plan for it. Almost everyone agreed that a working group should be chartered for it, they had some 20 or so people who said they’d be active participants, and 8 or 10 who said they’d be document authors. This seems ready to be chartered as a working group.

Peppermint — Provisioning Extensions in Peering Registries for Multimedia INTerconnection BOF

This one is decidedly less well baked, but they said that up front. They have good preliminary ideas about what they need, and used this session to bat it around in preparation for writing a draft charter. They seem to have succeeded in that, so we now have to see what the draft charter looks like.

Porn-spammers sentenced in CAN-SPAM conviction

Two men who were convicted in June under the CAN-SPAM Act of 2003, were sentenced on Friday:

Two men who sent millions of unsolicited pornographic e-mail messages have been sentenced to more than five years in federal prison as part of a prosecution under a federal antispam law, officials from the Department of Justice said Friday.

The men, Jeffrey A. Kilbride of Venice, Calif., and James R. Schaffer of Paradise Valley, Ariz., bought lists of e-mail addresses and sent the owners of those addresses links to pornographic Web sites, prosecutors said.

[...]

The two men were also ordered to forfeit $1.3 million.

A $1.3 million fine and “more than five years” in prison is a pretty good sentence for these guys. But I wonder where the forfeiture amounts come from. The news item says they made “more than $2 million in commissions,” so why didn’t they have to turn over that amount, rather than something approaching a million dollars less?

Still, it’s good to see convictions and decent sentences under CAN-SPAM, which has turned out to be a helpful, if flawed law.

Its major flaw is that it defines an “opt out” system, where spammers are allowed to send you mail until you tell them not to, as long as they follow certain rules, which include not lying about who sent it, and providing a working online mechanism for you to remove your address from future mailings. That sounds OK, but it means that you have to deal with the initial wave of spam, and you have to trust that when you click the “unsubscribe here” link, it doesn’t just get you into more trouble.

And that last is the trickiest bit. Conventional wisdom says that clicking on those will “confirm that they have a good address,” and that it “will only get you more spam.” While recent studies show that’s actually not the case as often as it used to be — that the opt-out links do, indeed, work much of the time — it’s true often enough that it deters people from using the very mechanism that the law puts there. And that’s probably just as well, because the unscrupulous ones not only won’t remove you from their lists, but they’ll also use the opt-out link to try to install zombie software on your computer.

CAN-SPAM should be changed to an opt-in system, as is the case with the European anti-spam laws, as well as the much-lauded Australian law. Under those systems, no one can advertise at you unless you sign up for it. That’s not to say that Europeans and Australians don’t get spam — only that what they do get is more clearly illegal, making the bar for prosecution easier to clear.

Of course, the marketing folks have lobbied strongly against opt-in systems, because they get a lot of benefit from the way things work today.

E-cards

The New York Times has an article about electronic greeting cards, talking about their popularity and focusing on some of the more off-beat ones:

[...] According to the Internet research firm Media Metrix, the top 20 e-card sites in the country had approximately 29 million unique American visitors in July, the most recent month for which data is available. The most popular site, AmericanGreetings.com, had over 7 million hits that month.

In most cases, these e-card sites are deliberately courting mass appeal. “Our sites are popular with a broad range of consumers,” said Frank Cirillo, a spokesman for AG Interactive, the group that owns the e-card sites AmericanGreetings.com, Egreetings.com and BlueMountain.com. “Some of our cards are edgier than others, but for the most part, our material is family-friendly.”

What is not “family-friendly”, though, is the use of fake “you have an e-card” messages as a vector for expanding zombie networks. You’ve seen them, surely; here’s a recent one that I got (click it for a full-sized version):

Yes, complete with the misspelling “recieved”, there it was, eminently plausible. It didn’t say who it was from, of course, but one would just think one was meant to go look at the “card” to see that. The row of text at the top was sent as images, loaded from and linked to the real Hallmark web site. The “send one” link and the row of links at the bottom also go to the real site. It’s only the one key link, the one in, “To see it, click here,” that’s bogus.

And that bogus link sends you to a web page that’s run by the scammer, in this case on a server in the Czech Republic. This one’s not even a sophisticated one: it attempts to directly run a Windows executable program, and so Windows — every version, even as old as Windows 95 — will actually ask permission to run it. You should say “no”, of course. But if you say “yes”, it will set your computer up on the scammer’s zombie network, and your computer will be among those sending out spam... and more fake e-card messages, designed to turn yet more computers into zombies.

The message, by the way, was not really sent “from” hallmark.com, though it says that in the message. It was really sent from a computer using a web hosting service based in the Dallas area. If you know what to look for, all this is easy to find.

But if you don’t know what to look for, how would you find it? If you got the message shown above, would you be sure you knew whether it was real or not? Maybe you’d notice the misspelling and suspect it from that. Maybe not. And if your birthday happened to be at the end of August, you might even be less likely to look at it with a critical eye.

Leave it to spam to ruin everything, eh?

As for me, it’s simple: I don’t care whether it’s “real” or not. I simply throw them away, unopened, unclicked. The truth is that I’ve never been much for greeting cards anyway, preferring someone’s own heartfelt sentiments to some packaged thing written by a drudge in an office, and that goes double for the electronic version. The Times tells us this:

For some repeat customers, these edgier e-cards have taken the place of a tossed-off text or e-mail message.

“I’ve started communicating more-or-less exclusively through Someecards because it says everything I’m thinking,” said Eric Kind, 34, an executive assistant at Lionsgate Television in Los Angeles, who sends upward of 50 cards a week from the site. “A friend from work sent me a card that said, ‘Sorry I thought you were gay.’ Now everyone I know is sending them.”

And yes, that’s really it: too many have gotten too lazy to take the trouble to send a personal note. But come on, surely it’s less time to write six or ten or seventeen words in an email message than it is to navigate the Someecards site to find the one that says, “Sorry I thought you were gay.” (Huh? That’s funny?)

Email’s made it easier than it’s ever been to drop a brief, personal line. And that personal touch from someone is worth more than a chorus of penguins singing to me from my computer.

Halt! Who goes there?

OK, a couple of my colleagues in Internet standards work, Peter St Andre and Dave Cridland, have started on about challenge/response systems (C/R systems, for short). I worry about stepping into it, but I figure that if I can discuss politics and religion in these pages, I can probably take the next step and wade into that swamp. (Next thing you know, I might take on the most socially dangerous subject of all: which text editor is best.)

So first, here’s how a challenge/response system handles an incoming message:

1. Apply various mechanisms to determine whether the message should be accepted or rejected without question. Perhaps the sender is whitelisted (a known correspondent, say) or blacklisted, or the message passes or fails certain content checks.
2. If the message is accepted or rejected, do so, and stop now.
3. If we get to this step, “accept” the message but do not put it in the recipient’s inbox. Store it in a waiting area instead.
4. Send a “challenge” to the sender. This may simply be a message that says “Reply to this if you’re real.” It could also include a CAPTCHA or some other mechanism to try to make it hard on automated systems.
5. If a valid response to the challenge comes back in a reasonable time, deliver the message to the recipient’s inbox. Most systems also whitelist the sender at this point, or provide it as an option.
6. If no valid response is received within a certain time, delete the message.

Instead of rejecting or deleting, the messages can, of course, be put in a “junk” mailbox that the recipient may check.

Proponents often tout C/R systems as “the” solution to the spam problem. They claim no spam and no false positives. Of course, they’ve just defined false positives out of the picture — I would call the challenged messages “false positives”.

The thing is, some of us detest C/R systems passionately. Dave does. I do. Dave explains some of the reasons in his blog entry (linked above), but I’ll repeat them here and add others.

Spammers often send messages with phony sender addresses, often using the address of a real person. That real person gets all the challenges and has to deal with them. The challenges themselves become spam. Dave also explains the difficulty in filtering the bogus challenges, fearing loss of “legitimate” challenge messages.

Of course, challenges could be limited to messages that pass DKIM, SPF, or Sender-ID checks, and that would help with this problem. Only, that would require a decision about the uncertain messages that are left — are they deleted (that might toss real mail, false positives) or delivered (incomplete spam deletion)? And what about messages sent by zombie machines? Such messages can pass these checks and will get challenged, but the challenges will still go to random users who will wonder why they’re getting them. And might they not just reply to them, allowing the spam to be delivered?

Two users of challenge systems might just get into a standoff, where each sends the other a challenge and neither responds. (A worst case of this could be where two badly designed C/R systems actually get into a mail loop, sending challenge messages continuously until one is shut down.)

Spammers can game the system by sending spam that looks like challenge messages.

And there’s the question of whom the challenge is sent to in the first place. Internet email has a number of entities who can be involved. For instance, suppose an executive at a company wants to send a survey to her customers, asking them to do a technical evaluation of the product they recently bought. The exec’s administrative assistant actually sends the message, and replies are directed to the exec’s technical assistant. Delivery-failure notices (“bounces”) go to someone in the sales department for follow-up (to check on the customer and maybe update the contact address).

In mail-header terms, we have something like this:

Return-Path: <sales@example.com>
From: <executive@example.com>
Sender: <admin-asst@example.com>
Reply-To: <tech-asst@example.com>

To which of those do we send the challenge? In this case, any might work, but it’s easy to alter the scenario so that’s not true (perhaps there are contractors involved, who are actually running the survey). A human could probably make a reasonable guess. An algorithm can’t get it right.

A variation on that theme is the case where a C/R user goes to a web site and puts in a trouble report. Mail comes from the customer support system — perhaps an automated reply, or perhaps something from a human support rep — and gets challenged. The result might be that the user does not get the help he needs.

Vary that further, having the challenge annoy someone who’s been asked to do a favour. Helper annoyed, mail ignored, favour not done.

There are legitimate reasons for messages to come from automata — auto-responses for online orders, for example, or things like bank statements and travel itineraries. C/R systems require that the user manually whitelist the senders of these, but the user won’t always know the sending address in advance.

As Dave points out, one reason that challenge/response systems don’t cause more annoyance and damage than they do is that relatively few Internet-mail users use them. St Peter points out that recipients of the challenges don’t seem to mind, but I think that’s because they don’t get that many challenges... and because the ones who would complain might just ignore them and choose not to communicate with him. It simply doesn’t scale, and it if were more widely used it would likely collapse on itself.

Peter also likens the situation to one in the Instant Messaging world, where there’s often some sort of negotiation before people are added to each other’s buddy lists. I think it’s a faulty comparison: email and IM are different environments. They behave differently, and we expect different things from them. Also, the IM challenges are normally handled as instantly as the messages are sent... and yes, I do get annoyed when I want to send an IM to someone and I have to wait a non-trivial amount of time to get the recipient’s approval to do so (because, say, the recipient isn’t at the computer right then).

In the end, Peter might be right about this:

Unfortunately, email is a slum. People take extraordinary measures to keep using the medium despite its slumlike character. These days I think it’s better to use IM, blogs, and well-run discussion lists or web forums. Sad but true.

But whether or not that’s true, if one does use email, and isn’t willing to abandon the email system altogether, I don’t think challenge/response is a good way to try to keep the value in it.

I'm on the radio (in German)

Deutschlandfunk, the German equivalent to NPR, interviewed me briefly by phone on Wednesday morning, and talked with Jim Fenton and Dave Crocker also, for an item about DKIM. The item was broadcast on Saturday afternoon. There's an audio file of it (mp3) and a text transcript. Both are in German, of course, but you can hear Jim, Dave, and me briefly before the German voice-over starts. The title means, roughly, “Pulling spam out by the root”, and the subtitle is “new signature system helps eliminate junk email”.

I find it interesting that these media outlets — first the Chicago Tribune, which had an article about the IETF that I linked to near the beginning of this post, and now German public radio — are talking about DKIM to the general public like this. It's encouraging, and it should push the deployment of DKIM as word gets around... but I wonder how much of the general public really understands what's going on here, despite our attempts to explain it in simple terms.

In any case, the media think it's good to tell people about it, and that makes me happy.

CEAS 2007

I've just returned from the Conference on Email and AntiSpam (CEAS 2007), in Mountain View, CA. I've been on the program committee for the past two years (translation: I've been a paper-review slave), and have been asked to be program chair for next year (translaton: slave driver). We're trying to expand the scope of the conference, but more on that later. First, a summary of the highlights of this year's conference... this is only my opinion of the highlights, with no attempt to cover everything. For more about any of these, see the associated conference papers.

We started with Wietse Venema as the invited speaker. Wietse's the author of the email program Postfix, and he talked about the development of Postfix, including the reasons he did it and the things he learned from it. It was a good talk, and I'm not saying that only because he works upstairs from me.

Other talks of note:

Mark Dredze from University of Pennsylvania talked about the work he and his colleagues have done in cutting the overhead of analyzing email images for spamminess. Their method is basically to figure out the analysis techniques and features that will take too long for this image and eliminate them in favour of the ones that will be faster and work well enough, recognizing the characteristics of the images that lend the image to be more efficiently analyzed by certain algorithms.

Zhe Wang from Priceton University gave a complementary talk about improving efficiency of spam image analysis by separating out a set of “features” from the images, and then using the features to analyze the similarities among images. That allows them to do the analysis with a more limited set of features, streamlining the process.

Lisa Johansen of Penn State discussed a technique that's being used more and more, analyzing email to detect common social networks — in this case, communities with common interests.

Amad Thomason, of the company Six Apart, discussed blog spam, and the issues it raises.

Enrico Blanzeri of the University of Trento (Italy) discussed their experiments with coupling a nearest neighbour algorithm with a support vector machine filter to improve the effectiveness (and decrease the false-positive rate), but at a high computational cost (every message has a different neighbour set, requiring recomputation of the SVM).

Zulfikar Ramzen, of Symantec, gave us a rundown on trends in “phishing” messages in 2006.

Aaron Zinman, of the MIT Media Lab, talked about spam-related issues in social-networking sites such as MySpace, showing that it's much harder to put a black-or-white evaluation on things in that universe.

Vijay Balasubramaniyan of Georgia Tech presented a method of using social network techniques to establish “reputation” for voice-over-IP calls, and using the reputation to fend off potential spam in VoIP telephony.

Victoria Bellotti of the Palo Alto Research Center (PARC) showed us a system they're working on, called TV-ACTA — an activity-centered interface for task management, tying together email, meeting agendas, calendars, and associated files in one user interface that allows you to managed all the information associated with a task or project in one place.

Of course, I won't mention the wonderful talks by my colleague Rich Segal and me. We kicked butt.

On to next year:

We still have to find one or two more program co-chairs, and then look at how to expand the reach of the conference, getting more papers on different kinds of spam and malware, and on other, non-spam aspects of email. We're also looking at venues for 2008... it might actually not be on the west coast next year, woo-hoo!

IETF 69, Chicago

I've just spent the week at the 69th IETF meeting in Chicago. It was the best of weeks, it was the busiest of weeks. And here's a hint for those arranging meetings: regardless of the assurances the hotel gives you, do not believe that the fact that they're doing serious construction and renovations will not interfere with your meetings. A number of sessions were severely disrupted by the noise of jackhammers. The hotel kept promising that it would stop during the meeting hours, but at least through Wednesday it continued.

And I talked with a Chicago Tribune reporter on Thursday (as did the IETF chair and the IAB chair), and his article about the meeting came out in Friday's paper, on the front page, above the fold. Very cool. Here's the electronic version of the article. It's pretty good.

Anyway, here's my summary of the meeting, hidden below the “click here if you want to read the boring, geeky bits” link.

Read the rest of the post...

For me, the week started on Saturday, as the IETF management (the IESG and the IAB) spent the afternoon and evening with our counterparts from ITU-T, the standards body of the International Telecommunication Union. The goal was to meet them, to discuss some technical issues, and to set up a context for working together more effectively. I know that I made some personal contacts in the course of the day that'll be useful to the standards work that I (and those contacts) do, so the meetings served at least part of their purpose. Beyond that, time will tell.

On to the highlights of the standards sessions....

lemonade — Enhancements to Internet email to Support Diverse Service Environments

As usual, we had two busy, full lemonade sessions. We spent the time reviewing document status and updates, and discussing issues with the latest versions. We took a good chunk of the time — about the first hour with a presentation and discussion about the OMA Mobile Email (MEM) Enabler development status. That was followed by a brief discussion of CONVERT and a more extended discussion of NOTIFY, working on resolving a fairly long list of open issues with the document. There wasn't really serious contention, but a number of things needed to be batted around, so it was a good discussion. Streaming needed essentially no discussion.

We started the second session with about five minutes on Message Events, and then hit my IMAP-Sieve draft, which needed quite some time on the open issues (one of which was discussed in more detail in the Sieve session, summarized later). Issues:

• Should we allow transient Editheader functions, for use in prepping the message for Redirect? Resolution: This can be added later, as an extension, if we decide we really do need it.
• Should EXPUNGE be an IMAP-Sieve event? It currently is not. Problems: it introduces inconsistencies and difficult-to-explain (and difficult-to-understand) conditions. But it's not just theoretical; Alexey already has a need for it. No significant support for it in the room, though. Resolution: take it to the mailing list, put a two-week timeout on the discussion, and decide then. If there's no clear choice then, the default will be to consider it as an extension later. (I've already posted the question to the mailing list.)
• Is it clear enough that the meanings of some Sieve actions are different here than in the base Sieve spec, because the context is different? Resolution: current document text is OK.
• Should the references to optional features be normative (they are currently not). Argument: some of the references say things like, “if [action x] is supported, then [action x] is valid in this context,” and that strikes me as non-normative. Chris (Apps area AD) considers that to be in the “grey area”, and suggests taking the less risky path (from a process point of view) of making the references normative. So agreed.

We finished by discussing Profile-bis. Should we add Streaming? No, not a requirement for OMA, and not worth holding Profile-bis up for. Should we drop Idle in favour of Notify? No, already in Profile, so already supported, and essentially it comes “free” with support for Notify anyway. Should we add Quickstart? Needs implementations before deciding; leave it out for now. Some discussion of notifications ensued, with references to Friday's “Biff” BOF.

DKIM — Domain Keys Identified Mail

The meeting's goals were to move the Sender Signing Practices specification along, and to highlight the Overview document and bring the working group's focus to it. We started with a review of document status:

• DKIM base protocol specification is now RFC 4871.
• SSP requirements document is with the IESG, working out some last-call comments and an AD "discuss".

Jim gave a review of the SSP specification, the latest version of which has just been accepted as a working group document, draft-ietf-dkim-ssp-00. Jim covered the principal changes to the document since the last review, in Prague, and discussed three main items in detail:

• Issues involving DNS wildcards.
• The SSP lookup algorithm, as documented in the current spec.
• What SSP publishers can say, outlining, in particular, a new option called "strong", in addition to the original "strict" (if it stays, the name will change).

There was some discussion of the algorithm, but most of the discussion was about what can be stated, and what the relative meanings of "strict" and "strong" are. We considered the idea that we have developed statements that we think the signers will need, but we have to validate them with those who will benefit the most from signing and declaring signing practices. Dave and Phill agreed to interface with MAAWG and APWG, respectively, to try to get their opinions on this. Phill also stressed his opinion that SSP statements should be declarative, not imperative ("I am a financial institution," rather than, "I would like you to delete mail that appears to be from me that is suspicious.").

Tony presented the status of the DKIM Overview document, currently draft-ietf-dkim-overview-05, which has had a lot of work from its authors but which has had relatively little feedback from the working group. The discussion centered on the goals of the document, and strengthened the result from the Prague meeting: the document should be split into multiple ones, to better achieve its several goals. In particlar, there's normative text in the document now, which isn't appropriate for an informational document. Some of that will be resolved by changes to the text, but some may be resolved by splitting a BCP or standards-track document off from the informational portion. The authors will work on this, and we'll keep the ADs involved as we consider changes to the charter for this.

In the few minutes at the end, Murray led a brief discussion of his authentication-results draft, which the working group will follow, and will consider adding to its charter if we (and the ADs) decide it's appropriate.

Sieve — email filtering language

We had minor discussion of the base-spec update, Editheader, MIME Loops, Reject/Refuse, Environment, and iHave. The most significant discussion in Editheader involved what requirements we place on which headers should not be allowed to be changed, and which should be. That went on for a while, with arguments back and forth — the proposal is to say that Received headers MUST NOT be changeable, and that changes to other headers MAY be disallowed by local policy; the question is whether we should specify headers that MUST be changeable, so a script can be assured of something it can change. In the end, we decided that the text that's currently suggested is best.

We had a status update on Notify, and some discussion of Notify-Mailto and the inclusion of Auto-Submitted headers. Conclusion: I will change Notify-Mailto to have it define an RFC 3834 extension (and an IANA registry) with a “Sieve-Notify” value for Auto-Submitted. Appropriate text will go into the spec to define the inclusion and usage of that field.

There was a good deal of discussion on the changes to IMAP-Sieve, mostly focused on the Metadata changes. My changes have the metadata contain the name of a Sieve script; there was a suggestion (and some consensus) to also allow the metadata to contain the script itself — probably with a level of redirection, where the defined metadata entry gives the name of another metadata entry that contains the script. The main point of contention is the need to have more than one script active at once. Randy gave some good reasons for that, involving multiple clients each needing to have their own scripts active, and each being unable to interpret the scripts of the others. Randy will write text to implement what he's asking for.

We spent some time on External Lists, continuing the discussion from Prague about whether having URIs makes sense. We batted operational examples around, and considered the question of authentication to the targets of the URIs. We also discussed limiting Redirect, aiming to prevent misuse and fan-out attacks, but having the side-effect of eliminating the ability to use Sieve to implement a mailing list. This tied into the External Lists discussion too, considering the concept of getting an external list to which a message would be redirected to. We decided that while there are legitimate reasons to use more than one Redirect on a message, we do not want to position Sieve as a way of implementing mailing lists.

We briefly discussed an in-person interoperability event, and decided that it wasn't necessary: any interoperability testing for Sieve can just as well be done by network.

EAI — email address internationalization

There's not a lot I want to say about this. The session was devoted to discussion of the drafts, as usual, and the open issues that need to be resolved. It was a productive meeting, and the schedule for moving the drafts on in the process looks good.

The main thing I want to record here was an issue in the Downgrade specification, involving what happens to messages with DKIM signatures when the messages are downgraded. There was clear consensus that the document needs to point out the issue. But whether the document should make any suggestions about what to do to meliorate the issue (such as having the downgrader verify the DKIM signature and re-sign on its own behalf) wasn't clear. Chris, as Apps area AD, said that he thinks we have to say something about the interaction, but he isn't going to make a declaration of what that should be. Dave thought that this isn't the place to give DKIM implementation advice. I commented that I'd normally agree with that, but these are experimental specifications, and it would serve us well for them to suggest what experiments might be useful.

I think we decided to include some non-normative suggestions, and that any suggestions that involve DKIM will have to be reviewed by the DKIM working group.

SAAG — Security area open meeting

The SAAG meeting always starts with reports from all the security-area working groups, and then has some invited talks. There were two invited talks this time:

1. John Klensin presenting internationalization issues related to security.
2. Morris Dworkin, from NIST, presenting a proposed variant of the Galois Counter Mode, an authenticated encryption mechanism.

John talked about the problems that Internationalized Domain Names (IDNA) was meant to solve, the problems with the first version of IDNA (IDNA2003), and the changes in the update that's under development (IDNA-bis). There weren't any surprises in his presentation for anyone who's been following the work, and there really weren't any security-specific things in it, apart from occasional references to passwords (and the idea that internationalization problems might actually be beneficial for passwords). There was some discussion after the presentation, but, again, nothing especially notable and nothing really security-related.

The GCM presentation was a crypto-technical one, detailing a modification to an encryption algorithm intended to opimize it. I'm not a crypto expert, so I could follow the presentation somewhat, but only somewhat. After the description of the modification, its effects, and its performance, there were some questions and comments from the audience. The discussion involved tag truncation, key size, the speaker's point about “relaxation of IV validation”, and possible other variants of the algorithm (maybe better optimized than this). At the end, the Security area directors asked who in the room thought they could use this variant in their security protocols. No one raised a hand.

HTTP-bis BOF — Updating and advancing HTTP standards

The purpose of the BOF was to propose a working group — they had a proposed charter — to advance RFC 2616 to Draft Standard, along with associated considerations and updates. The principal associated issues were (1) the HTTP authentication mechanisms, (2) cookies (scope and domains), (3) HTTP caching (and association with "logout"), and (4) ETags (involving CalDAV/CardDAV issues).

There were presentations on each of those issues, some of which were a bit hard to follow because of a combination of jackhammers and quiet speakers. The bulk of the discussion then fell on the scope of the work — how much of the numbered stuff above should be included while updating and advancing RFC 2616. In particular: should the HTTP protocol update include the authentication/security issues. Consensus was that the security-related work should be separated, as those with the expertise in the protocol aren't the same as those with expertise about the security aspects.

There was also consensus to include cookies in the HTTPbis work.

It looks like the plans are fairly well baked, and the charter is pretty solid. There was also a good show of hands for people willing to do the work here. It seems that formation of a working group is mostly assured, and that's good.

APM BOF — Application Performance Metrics

The APM BOF's goal was to explain the need for coordination in the definition of performance metrics for higher-layer protocols (SIP was an example given), and to explore the interest in working on such definitions and to look at how to do it (directorate vs working group). Their problem statement points out that the people working on the protocols often do not have the expertise to define performance metrics, and that the documents addressing them do not get much attention (people would rather spend the effort on the protocol).

That sounded good. Unfortunately, once they got past that everything started raveling. The details were ill-defined, there were far more people there than the chairs expected and they asked questions for which the answers were inconclusive or unsatisfying. They proposed a set of options, with apparently no process guidance on how appropriate these options are:

1. Form an APM Directorate that would consult with and advise working groups on the development of APMs.
2. Form a long-running APM working group, which would wake up at appropriate times and develop the APMs in partnership with the protocol working groups.
3. Form a short-term APM working group, which would write a "BCP/framework RFC" and then “evolve” into (1) or (2).

In the end, the chairs had a series of questions that they didn't really have time to get to, which is just as well:

• Who thinks the IETF should work on developing performance metrics?
• How should we do it?: (1), (2), or (3), above, or none of the above.
• How should the choice picked in the the previous question operate?

They got many hands up for the formation of a long-running working group, but I'm sure the people “voting” didn't really know what they were suggesting, or what the process issues are with it. It was not an appropriate question to ask a group of BOF participants.

I think what needs to happen with this is that the organizers should work with the Ops area ADs to better define what they want to do and how they aim to do it, and set this up as a more concrete proposal that defines how it fits into the IETF process. If that happens, they might come back for another BOF that can better explain the result it wants to get, and how it'll be implemented.

vCard and CardDAV BOF

The goal of this BOF is to explore a work