IETF 72, Dublin

Well, Dublin-ish. The IETF meeting was actually at Citywest, 30 minutes outside of Dublin. I guess that was great for the golfers, but I missed being in the city, and having the option of walking out and getting lunch and dinner. They provided dinner buses into Dublin, but that’s not the same as just walking down the street a block or three. It seems that Trinity College Dublin would have been a fine place to have the conference, and I’m sure there are other facilities that’d have worked as well.

Still, it was a good meeting. The facility we did have was somewhat expensive, but otherwise fine, and, of course, the meetings were productive and useful, as always. It was another full week (I had about two hours of free time the whole week, an hour or so each on Wednesday and Thursday), and managed to schedule the rest of the time, including meals, for work.

It’s too bad, someone pointed out, that it was the 72nd meeting, and not the 33rd — if it were the latter, we’d have heard the local presentations welcome us to the “torty-tord IETF”. As it was, we heard that there were almost torteen hundred attendees (or, one tousand tree hundred), so that was nice.

I’m going to keep the meeting summary on the short side this time, with just a few highlights, but it’ll still be a long post. If you want to read about the vacation days after the meeting, and see photos, look for my other post, to come tomorrow. If you’re really interested in this, click here to see the meeting summary.

apparea — Applications Area general session

Among the general announcements were that NFSv4 will probably be done in the Applications Area, and that there’d be a discussion of email standards status on Tuesday (of which I have a summary below). There was a presentation of two follow-ups from the Applications Area workshop in February — netappvlan and netappmodel — but with no ensuing discussion.

There was a brief discussion about FTP extensions. The points are that, while FTP seems quite mature, and not terribly ripe for extensions, it’s still big business and there are five documents that are out as Internet drafts, looking for standardization. Should these go through as individual submissions? Should we form a working group?

It looks like we’ll form a working group, and John Klensin and I have agreed to co-chair it. We expect it to be a short-lived and non-contentious group, and John and I agree that standards going through the group will require some real support behind them, and existing implementations as evidence that they’re real and worth moving forward.

dkim — Domain Keys Identified Mail

We had a quiet session at this meeting, and my co-chair, Stephen, wrote this succinct summary, which I’ll use here:

DKIM met Monday afternoon, 62 people attended.

The main goal of the meeting was to get the ADSP and Overview documents to the start of working group last call. Each had a couple of open issues at the start of the meeting that were discussed and resolved (modulo confirmation on the mailing list). The result was that a new revision of ADSP will be published this week. Working group last call on both documents will start at that point.

The deployment guide was briefly presented, and work on that continues.

A couple of proposals were made for new work that might require re-chartering. There was some, but not overwhelming, interest in pursuing these, but the group won’t have that discussion until after the two current documents are in the hands of the IESG.

idnabis — Internationalized Domain Names update

We had the usual minor issues discussion, but the most significant by far, taking most of the time in the two sessions, was in the “BiDi” (bi-directional text) document: how to deal with left-to-right text, such as numbers, dots, slashes, and the like, in otherwise right-to-left text, such as Hebrew and Arabic. We had a demonstration of what happens when such text is entered, and it’s not pretty. As someone typed “abc2.[Arabic-text].3def.com”, we watched the “.3” get turned around and moved, so it incorrectly appeared to be attached to the Arabic text. To be sure, this is a user-agent problem — the correct characters will be sent on the wire in the correct order — but it’s a very hard one to solve. There’s no resolution yet, but we have more information, and, as we say, “Our best people are working on it.”

We also had a discussion, which included at least one native speaker of Korean, about a request that we add another set of Korean characters to the list of characters forbidden in domain names.

eai — Email Address Internationalization

We had some discussion of EAI issues during a working dinner on Sunday, and came up with a recommended answer to the question of what to do about List-* header fields. I presented that answer in Monday’s EAI session: for List-ID, note that it is meant to be a machine-readable string, not a human-readable one, and should not be in UTF-8; for others, internationalize them by including multiple URIs, and downgrade by removing the UTF-8 version, leaving the non-UTF-8 versions for use after downgrade.

POP and IMAP are almost done, but there’s an issue about POP and downgrade — the document currently has uncertain language about how to downgrade a UTF-8 message if the client isn’t using UTF-8. In the event that an old client is being used to download the message, but that a newer client (perhaps after a software update) is later used against the same local message store, we agreed, after discussion, that it would be good to have a standard downgrade mechanism used, so there’s some hope that the new client can recover the original message. There was agreement to require the use of the standard EAI downgrade.

We decided to wave our hands around the issue of handling mailto URIs. It will eventually require its own document (a UTF-8-enabled mailto), and for now we’ll point out that mailto does not handle UTF-8 addresses, and that something to deal with that is forthcoming.

There was a report on some very successful experiments with the current EAI specs (including downgrade experiments). Many thanks to the organizations that participated in those. Notwithstanding that, it’s clear that the aggressive schedule that was suggested at IETF 71 isn’t realistic, and we’re setting up a new schedule for re-chartering to put the EAI specs on the standards track.

httpbis — HTTP update

There was a long issue list to get through here, and some issues have been harder than the chairs and authors thought they would be to get consensus on. I’m just including some brief notes here.

The next version of the drafts will include a new registry for messages, to parallel the one for status codes.

The formal grammar is being converted to ABNF, and that’s a lot of work to get right. There’s a particular trickiness with cleaning up LWSP, removing it from where it doesn’t belong, while being sure to leave it where it’s appropriate.

Internationalization is, as always, a sticky issue. Despite standard headers, HTTP implementations have done their own things with respect to internationalization, and it’s making it difficult to decide how to go here. There are questions about support of RFC 2047 encoding, internationalization of filenames in content-disposition headers, and such. There was quite some discussion on this.

There was a discussion of issues with the use of the message header registry in HTTP. The registry is for other uses and is shared by HTTP, and there’s concern about having information in the right place, making sure that implementors read everything necessary to get the implementation right, etc.

For more on internationalization, we came to the question of what character sets to allow in new header fields. The decision was to say that new header fields MUST only use US-ASCII, but that implementations SHOULD accept ISO-8859-1 (including UTF-8 as well, at this point, did not get acceptance).

We finished with a presentation and discussion about security requirements for HTTP, an item specifically out of scope for this first round through the working group, but something that might be added to a re-charter.

morg — Message Organization standards

The MORG BOF’s goal was to review a series of individual Internet drafts and ideas that all relate to searching, sorting, and organizing email messages using IMAP, and to consider forming a working group to bring these documents through the standards process.

The BOF chairs came in with a chunky set of drafts, most of them fairly immature, some of them with significant IMAP-community support already and some that are new items. We went through the drafts, got explanations of each, and discussed them — some in considerable detail.

As a result of the discussion, it seems clear that there are enough document authors, reviewers, and server implementors to get through this lot, and enough energy to easily support a working group. There was some concern, though, first brought up by John Klensin, that this could be another set of IMAP extensions that bloats IMAP, and that really isn’t in significant demand. The problem is that we don’t have much participation by client implementors.

Chris Newman supports the formation of a working group here, and I agree. Chris would like to see the chairs manage the work by assessing the implementation commitments, including commitments from client developers, and dropping items that don’t have commitments to implementation in clients. I also agree with that idea.

The “bloat” discussion led to a suggestion to consider “IMAP5”, which would start by removing features to create a minimal protocol with necessary function, making something that’s easier to implement and get right. Randy Gellens has already started a mailing list for that, and there’s been some initial discussion.

asrg — AntiSpam Research Group

There are two primary documents coming out of this research group so far, both dealing with DNS block-lists. The first, which describes how they work, has been reworked to go on the standards track (as an individual submission, since the IRTF can’t publish standards), rather than being an informational document. The second, recommending best practices in operating and managing a block list, still needs work, and will probably go out as a BCP.

We had some discussion about whether another document should be adopted by the ASRG — the decision was not to adopt it — and that discussion led into some talk about how to focus the ASRG on new research. I will discuss the ASRG at the CEAS conference in late August, and try to get more participation from the academic community into the ASRG (possibly recruiting an ASRG co-chair from that community).

vcarddav — VCard update and CardDAV

We had the usual document status update, and went over some open issues. One that seems simple, but that merited some discussion was that dates must currently be complete (day, month, year), but there are times when one doesn’t want them to be, or doesn’t know the full date (for birthdays, for example, one might just want day and month, but no year). We decided to use existing date syntax from the comparators RFC and adapt it for VCard.

The other significant discussion was on how to handle synchronization issues, especially with collision-detection in situations with multiple copies of the information (one on a host server, one on a laptop, and one on each of two or three mobile devices, for example). Included here is the discussion of unique IDs — whether to have per-property UIDs, whether to require persistence of UIDs, how to handle the situation where a particular device or data store can’t keep the UIDs persistently, and so on.

We also had a small discussion about internationalization questions, in light of EAI. I have a suspicion that we’ll encounter effects from EAI that we haven’t yet anticipated. In the end, I don’t think they’ll be serious, but we’ll have to deal with them.

sieve — Sieve mail filtering language

This was an uneventful session for a working group that’s wrapping up its old work and preparing to re-charter to add some new work — work that is itself close to being finished, actually. We went over document status, and there’s nothing notable to say about that. The most difficult document, which this working group is picking up from lemonade, was discussed there (see below).

We talked a little about possible issues that Sieve will have with EAI — most obviously, that it will likely make scripts more complex and ugly, as a script will have to handle multiple versions of the same email address. We expect to have a sieve-eai document in the new charter.

lemonade — Mail extensions for diverse service environments

We still had a full session of final discussion, despite having thought that we wouldn’t meet here at IETF 72, but this group is wrapping up. We made some decisions on the remaining issues, and agreed to move the last document (imap-sieve) to the Sieve working group.

We finished with an incomplete discussion of imap-sieve (we ran out of time), and we’ll continue that discussion on the Sieve mailing list. Ned Freed had brought up a series of thoughts about the extension, in an email message in May, and I’ve summarized that into eight main issues.

Email standards discussion

After our experience with getting RFC 2821 and RFC 2822 updated and through the process of progressing to Draft Standard, a few people thought it would be good to consider setting up a working group chartered to progress those documents to [full] Standard, and to move other Proposed Standard documents to Draft Standard. This dovetails with my idea of creating a long-standing working group for email standards maintenance, a topic that the IAB and IESG discussed in our joint meeting on Sunday.

We have consensus, energy from participants, and IESG support to create such a working group, and we now have a mailing list to discuss a proposed charter. I suggest that we do a three-stage approach:

• In the first stage, set out a list of Draft Standards to progress to Standard, and then re-charter for the next stage.
• In the second stage, set out a list of Proposed Standards to progress to Draft Standard, and then re-charter for the next stage.
• In the third stage, set out a list of work that needs to be done that might result in new Proposed Standards for email.
• Iterate on those three stages. When there’s no immediate work to do, go dormant and periodically review the situation, waking up and picking up work when there’s work to pick up.

Technical plenary

The technical topic at the plenary this time was operational experience with IPv6. We had a panel of five speakers, who talked about their experience with implementing and operating IPv6, and answered questions from the moderator and the attendees.

Internet Architecture Board

In addition to setting up and running the technical plenary panel, the IAB reported on its work as follows:

• Informational documents:
  • We published RFC 5218, “What Makes for a Successful Protocol”, to help provide guidance for protocol designers.
  • We have “Design Choices When Expanding DNS” almost ready for final submission, giving architectural guidance use those who would use DNS for new purposes.
  • Work is wrapping up on “Principles of Internet Host Configuration”, advising on architectural issues involved in configuring Internet hosts.
  • We have a new document, “On RFC Streams Headers and Boilerplates”, dealing with an administrative issue.
• At our IAB meeting in May, we began work on several Internet architectural projects, and two of them have made some progress since:
  • Evolution of the IP Model, looking at architectural problems caused by layer violations as assumptions leak into higher-layer protocols and applications about how the IP layer works.
  • Peer-to-Peer Architecture, covering architectural questions involved in peer-to-peer protocols and applications
• We have set up a process for assigning liaison shepherds from the IAB, to better manage the liaison relationships between the IETF and other organizations, such as ITU-T, OMA, and W3C.
• We set up some new liaison relationships and other inter-organizational work.
• We have proposed a new organization of the RFC Editor job, splitting it into four functional roles that give the flexibility of contracting and managing different roles separately.

Another look at “reply to all”

In the “Profession” column of the July 2008 issue of IEEE Computer magazine, Anne-Françoise Rutkowski and Michiel van Genuchten talk about “e-mail pollution” in an article titled “No More Reply-to-All” (abstract here; the full article is behind a paywall):

Measuring e-mail pollution

As more people flock to the Internet, external pollution — spam — has received considerable attention and become the target of spam filter countermeasures. We, however, focus on internal pollution. Our experience shows that it takes more time to detect internal pollution than external pollution. Deleting outrageous and misleading offers from parts unknown takes only a few seconds. Reading colleagues’ e-mail messages only to find at its end that you were copied only for their convenience can take minutes. The term e-mail pollution addresses such superfluous e-mail. Adding too many recipients typically causes this pollution, whether they appear on the send-to or cc list.

And, yes, that’s absolutely true. Anyone will tell you that your own eyes and brain can detect spam much more accurately than any automated spam filter can, and the delete key/button/icon is right there to hand. But when I get yet another email message in a discussion thread that has long since become irrelevant to me, but that still has a subject that warrants my attention, I have to read it, often sifting through a lot of forwarded text and other mess, in order to see that it’s really just someone thanking someone else for their input. Oh, great.

The authors go on to suggest a metric wherein someone who fans out more message recipients than what comes in is called a “polluter”, while someone who trims distribution lists relative to what comes in is a “cleaner”. It strikes me that in reality there’s a swath of “neutral“ in between the two, but the point is basically there: we want to encourage “cleaners” among our correspondents and in our businesses, and to discourage “polluters”.

They propose three “rules” to help:

1. No more reply to all. They recommend disabling the mail-program button that performs that function.
2. No more copies than originals. This isn’t explained well, but it seems like they mean to say that you should never add recipients to a reply without taking some others off.
3. No more e-mail fights. If you’re going to get into a battle, do it on the telephone, where the bandwidth is higher and the likelihood of misunderstanding is lower.

I’ve no disagreement with rule 3 — it fits perfectly into my rule that one should use the right communication medium for the task at hand. Rule 2, if I understand it, is very much related to rule 1. So I’ll address my comments to rule 1.

Disabling buttons and making absolute rules is a Very Bad Idea. While it’s certainly true that “reply to all” is abused quite often, there are good reasons to use it. See my extensive comments about that from about three months ago.

I propose that the real chance at solutions to what I’ll rather call “recipient pollution” lies in a different set of three points:

1. Technology: Provide a user interface that makes it easy to make the right choice of recipients, without trying to presuppose what that right choice is. This was what I said in April.
2. Company policy: Make it clear that management expects people to think about the distribution lists on their messages, and that employees who are consistently abusive in that regard will be spoken to.
3. Company culture / social pressure: Encourage an environment where people feel free to complain — politely, but firmly — to their colleagues when they see them stepping over the line. If the response to “Please stop copying me unnecessarily,” is usually “Too bad!”, then the problem will persist. On the other hand, if the typical response to persistent unnecessary copies is, “Hey, Bill, please make sure that when you copy me on a message, it’s legitimate, OK? Remember what our Director said last month,” people will be more likely to stay in line.

The problem is that we’re not doing any of that. Most email clients are no help at all, and corporate policy and culture generally lean toward longer distribution lists.

This isn’t really a technological problem, so let’s be careful about trying to solve it as one.

NPR series about email

I was a bit disappointed in the series about email that National Public Radio’s Morning Edition aired last week. It’s not that it was bad, just that I thought it was sort of fluffy, with little real meat. Here’s my executive summary of the series:

• Sunday: Friends and family members send a lot of junk — “jokes”, urban legends, inspirational messages, chain letters. It’s annoying.
• Monday: There’s too much email, and it’s a main factor in information overload. We need strategies to deal with it. And it helps if you don’t contribute to the problem.
• Tuesday: A company has come up with a strategy. Their software makes you assign “importance points” to each message, and you get a limited number of points to assign. Use them wisely.
• Wednesday: Your mail is backed up and archived, and exists forever. Your business mail might be subpoenaed and searched during legal proceedings.
• Thursday: Encryption can keep your mail private, but almost no one uses it. You’re especially exposed if you use public networks. But most people don’t care.
• Friday: Some offices have established mail-free Fridays... and an opinion that that’s just running away from the problem. Also, some talk about stepping away from your BlackBerry.
• Saturday: There's a plethora of ways to communicate (email, IM, text messaging, phone, Skype, social networking...), and senders and recipients have to choose among them, and adapt to each other. Also, a discussion of “friending” on social networking sites.

There’s a bit more stuff on the web site, along with a few links that one might find useful. And, to be fair, it’s likely that I find it a little fluffy because I’ve been intimately involved with email technology for the better part of 30 years. Probably, the average listener found the series interesting. Saturday’s installment was the most interesting to me.

And, too, I’m not sure what I expect them to say. Maybe more advice that’s practical for the average user. Maybe something done in layman’s terms about up-and-coming email or anti-spam technology. Maybe even just a FAQ — despite the ubiquity of all this, I still hear the same questions all the time. Like, “Why is this guy sending me spam?” (A: He’s not; the sender address is faked.), and “How did I get this message? It wasn’t even sent to me.” (A: Yes, it was, on the envelope; it just doesn’t say that in the message.)

Anyway, give the series a listen. And, if you’re so inclined, comment here about what you think of it.

I’m gonna sit right down and write myself a letter
And make believe it came from you
I’m gonna write words, oh, so sweet
They’re gonna knock me off of my feet
A lot of kisses on the bottom
I’ll be glad I got ’em

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.

Instant messaging vs email

One of our local radio talk show hosts, Brian Lehrer, just had a call-in discussion about whether instant messaging is less distracting than email:

A new study from Ohio State University and the University of California, Irvine says that instant messaging is less distracting than email in the workplace.

What do you use at the office to communicate? Let us know!

I find the premise interesting, because I don’t think of the difference as one of “distraction”. It’s more a question of their having different uses, and different modes of interaction.

I find IM useful to have conversations, interactions that go back and forth more than email. I find IM useful to pose a brief question that’s likely to have a brief and readily obtained answer. That’s stuff we would have done on the phone, but it’s much less of an interruption than a phone call is, and it requires a smaller cognitive investment (it’s easier to fit it into the flow of multi-tasking).

And that’s the aspect that perhaps makes it “less distracting” than email: it emphasizes quick, short messages that don’t pull your cognitive processes away from whatever else you’re doing. If I were to get an instant message while writing this, I’d probably finish this sentence, switch over to the IM window (using the keyboard, not the mouse), respond to the IM, switch back here, and continue writing. My mind would still mostly be on this, and it would re-focus easily.

On the other hand, if the phone should ring in the middle of a sentence, I’d feel obliged to answer it immediately — I think most of us would, though many folks do ignore the phone — even before finishing the current sentence. Even with a brief phone call, it’s likely that my mind would be derailed, and it’d take a few moments for me to say, “OK, where was I?“, and to refocus on what I’m writing.

And instead, if I should get email while I’m writing a sentence here, it’d be an entirely different situation. I wouldn’t pay any attention to it at all. Most likely, I wouldn’t even notice that it arrived, because I’m focused on writing and I don’t use email in that way — email doesn’t interrupt tasks that I’ve mentally labelled as not freely interruptible.

If, though, I were reading the New York Times headlines and email should arrive, I might instantly notice the email and switch to my email program. Reading news headlines is a task that I think of as freely interruptible, and I’d go ahead and take the interruption.

The key points here are

1. what I use IM and email for,
2. what expectations the person I’m communicating with has,
3. how the information is presented to me by the IM and email programs, and
4. how I handle interruptions to the work I’m doing.

Instant messaging is a perfect channel for having side conversations during conference calls, and I very often use it for that. Conference calls are much more useful when there’s the ability to get a clarification, make a suggestion, or “raise your hand” to the moderator, and IM works far better than email for those things.

There are also certain things I’d prefer to keep in email, mostly because of the way my information is stored and organized today — and this could change, if we made a fundamental change in how we organize things related to what we work on. Significant information that I want to keep, I prefer to have in email. Sure, I have instant messaging session logs, but they tend to be disconnected blasts of conversation, and aren’t usually a place I go to find things. The information in them isn’t catalogued or indexed in any useful way. I’d like to see that change.

So, if you want me to look at a web page because you think I’ll find it of passing interest or you want me to comment on it, sending the URL in an IM is good. But if it’s something I should look at later, when I have some spare time, or if it’s something important that I’ll be keeping for reference, email is better. It’s less ephemeral.

Tools are best used for what they’re best at. You can bang a nail in with a screwdriver... but it’s better to use a hammer.

The next step in phishing

I’ve recently seen a new angle[1] on phishing — the practice of sending deceptive email messages to try to snag personal information such as account numbers and passwords. Usually, the phishers try to hit your bank account, credit cards, or online payment system, hoping to get direct access to your money. But last week I got a message that tried to get access to an airline frequent-flier account:

Subject: AAdvantage Survey Program

Greetings from AA.com

Welcome to the American Airlines AAdvantage(R) program, the first and largest loyalty program in the world! We are proud to inform you that today June. 26 /2008 AmericanAirlines.com launch a new reward program. Please log in to your American Airlines account and take the 5 questions survey. For your effort you will be rewarded with $50

Your 50 dollars bonus code is AA-001NXX-2008NX22. Please log in to your www.aa.com account and follow the steps.

Thank you very much for your help and your patient and hope you will enjoy the American Airlines reward program in the future

Sincerely,
American Airlines Reward Department
Please do not reply to this auto-answer message

The clues are the errors in grammar and the missing punctuation (and, um, the fact that it’s not “today, June. 26 /2008” yet). The actual link behind the www.aa.com text points to a web server in Russia.

Of course, if they can get at my AAdvantage account, they could cash in my miles. They could also buy tickets with my credit card if I’ve saved my card information in my account (I haven’t). And, of course, if they get any password, they can try using it in other places too. That’s all good reason for me to remind you to use proper passwords on these sorts of accounts, keep them secret, and don’t use the same password for all of them (limit your exposure, so if one is compromised it doesn’t give access to others).

It’s also a good reminder to keep your hand on your wallet. The bad guys will try to break into anything, from your bank account to your email and Facebook accounts. Watch out.
 

---

[1] Get it? Angle, fish, phishing.... Yeah, OK.

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.

On replying to email

A couple of weeks ago, David Pogue posted in his New York Times blog a letter from a reader. It’s short, so here:

A Simple E-Mail Design Idea

A good idea from a reader:

David, I had the simplest of ideas for helping people avoid “Reply-All” nightmares (where you humiliate yourself by clicking Reply to All, blasting your response to a huge group, instead of just Reply). E-mail programs like Outlook or Apple Mail should just not put the Reply-All button anywhere near the regular Reply button!

Visually, when the two are so close to each other, it’s easy to mistakenly click the wrong one. But if you had to go down into, say, the bottom-right corner to find the Reply-All button, that would likely jar you enough so that you wouldn’t make an error.

Hope that someone implements this some day soon!

(To which I add: Or how about, at the very least, requiring that you press a key, like Shift, as you click the Reply button to change it to “Reply to All”?)

It sounds simple; it sounds nice; it sounds like it’d solve a lot of problems, doesn’t it?

The trouble with this idea, as with many of these sorts of ideas is that it’s not as simple as that. Oh, yes, people have thought of both the reader’s suggestion and Mr Pogue’s... and some mail programs do one or the other of them. Guess what: it doesn’t fix anything, not really. It only makes things a bit less convenient.

Some of the commenters have the answer too. And so... let’s look at my comments on it, and on what some of the other commenters say.

First, for everyone who says, “They should hide the ‘reply to all’ button, because it’s almost never what you want to do,” you can find at least one person who says the opposite, that “reply to all” is usually right and people don’t use it enough. The real answer is that each is correct sometimes, which is why both options are proffered.

When I send a note to, say, ten people, and you reply, the question really is whether you’re replying to me or to the group... whether everyone ought to see your reply or not. There really isn’t a way to know, in general, which of those is the case. We can infer the former if the group is large enough — it’s less likely that your reply ought to go to the group as the groups size increases — but deciding on the threshold isn’t easy. 100 probably qualifies. But does 10? I have certainly had group discussions by email with ten people at a time.

The consequences of not including the group on your reply are also not benign. It can confuse the discussion greatly when some people miss a sub-thread of the discussion, and it can make coordination difficult when different people are aware of different fragments of the situation. I was recently involved in trying to get four people to meet, when two of the people were replying only to the sender of each message... and it was horrendous.

So the answer isn’t to hide one of the reply options. The answer is to make it easy for the user to make the correct choice for this reply.

Most of the commenters agree, though, that the “reply to all” button should be hard to get to. They’re annoyed by “inane replies” when the wrong choice is made, and they’re not thinking about the times when they’ll be as annoyed, or more so, by not getting a critical reply that was sent only to one or two people.

One of the commenters, the first one, basically eschews the “WIMP” interface, saying that you should use the keyboard, and refuse to use any program that doesn’t make it easy to use the keyboard instead of clicking buttons. I have a lot of sympathy for that approach — I’m a big fan of keyboard shortcuts, and use them a great deal myself. But, hey, I’m a techie too. My mother is not likely to learn the keyboard shortcuts for every program — which are, by the way, different for every program.

Commenter 3 suggests a confirmation prompt:

“Are you sure you want to reply to all?”
press cancel or OK

There’re two problems with this. One is that by presenting a confirmation prompt for one option and not the other, you’re suggesting that one option is preferred (or, alternatively, that the other is so dangerous that it needs confirmation)... and you’ll wind up discouraging people from using the “reply to all” choice even when it’s the right one.

The other problem with it reflects one of my pet peeves about computer messages: the response choices don’t agree with the question. If you ask me a question for which the answers ought to be “yes” or “no”, make the response choices be “yes” and “no”. Not “OK” and “cancel”. Not “continue” and “stop”. Word the question carefully, and make the responses parallel to the question.

Lots of the comments point out that in many programs the user interface can be customized, and the reply buttons can be moved around. Again, as with the keyboard shortcuts, that’s a fine thing to have for those of us who’ll use it. Most people won’t.

So here’s a plug for the email program that I use, Mulberry. It was written by a friend and colleague, Cyrus Daboo, and it’s now out as open source. I’ve been using it for years. It’s not without its problems — no program like that is — but it has one of the best interfaces I’ve seen for replying to messages. It presents you with a list of all the addressees, showing their roles in the original message (sender, to, cc), and checked off as “to”, “cc”, or “bcc” for the reply. There are buttons to quickly select all recipients or only the sender, and it’s also easy to select just certain ones or eliminate certain ones (important when, say, an executive starts up a conversation, but the participants need to go off without her and have the discussion).

One commenter also points to a project called Kangaroo, which looks interesting:

Users occasionally send email to the wrong recipients — clicking Reply To All instead of Reply, mistyping an email address, or guessing an email address and getting it wrong — and suffer violations of security or privacy as a result. Kangaroo is an extension to webmail systems that aims to alleviate this problem by automatically displaying pictures of the selected recipients in a peripheral display, while the user is composing an email message. Kangaroo currently utilizes google images and facebook searches as techniques for obtaining faces from email addresses. Furthermore, it has the ability to discover mailing list memberships from existing web data sources, and a user interface design that keeps important facecs recognizable while scaling up to hundreds or thousands of recipients. Preliminary experiments suggest that faces significantly improve users’ ability to detect misdirected emails with only a brief glance.

I think I’ll try the Firefox extension, and see what I think.

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/
   

Outlook and Gmail

Tuesday’s New York Times Bits blog has an item about a product that will synchronize between Outlook and Gmail:

Cemaphore Systems, a company that specializes in e-mail backup services, is expected to announce on Wednesday a new product that allows people to automatically synchronize their e-mail, calendar and address books between Microsoft’s Outlook and Google’s Gmail. The service, called MailShadow for Google Apps, is being pitched as a “email continuity and disaster recovery solution.” In other words, it is intended to provide users of Outlook and Exchange, Microsoft’s mail server, with a secure backup. As such, it represents an interesting use of the Google computing “cloud” to provide a service for Microsoft users.

But the technology also would allow businesses to rip out their Exchange servers and run Outlook, which millions of users are familiar with, directly from the Google servers.

It’s the last bit that interests me, in particular.

First, most of that’s already there, using the Internet standards that both Outlook and Gmail support. Outlook users can access their mail in Gmail today, through the IMAP protocol that Gmail recently added support for. There are some limitations in the Gmail implementation, and an annoying bug in the handling of line-end characters (which the Gmail people are aware of and plan to fix), but it’s there. For calendar, both programs support the iCalendar standard, making it possible to move calendar information back and forth. And both allow exporting and importing vCards, so one can move address-book entries also.

There’s value, of course, in setting up a one-click synch, and perhaps that’s what Cemaphore has done.

But it’s bound to disturb corporate IT management, because employees will surely use it to bypass — intentionally or not — corporate security policies by storing corporate email, contact information, and calendar entries (with conference call-in numbers) on Gmail’s servers.

BlackBerry devices have become very popular in the corporate world, and are widely accepted in that environment precisely because they use encryption all the way through the system. Whenever any corporate data passes through a service provider, it’s encrypted... so even if you don’t trust your carrier, it doesn’t matter: they can’t get at the data anyway.

Gmail has done some things right with regard to encryption in accessing their systems: you must use encryption when you use Internet protocols in Gmail. That’s a good thing. But the encryption is only used to move the messages around. When they’re stored on Gmail’s servers, Gmail can read them. And that gives corporate types heartburn.

We’ll have to see what corporate IT management does about it.

Amtrak phishes its own customers

On 13 Feb I received email from “Amtrak <amtrak@amtrak.bfi0.com>”. See the image below (click for full size). In short, the email tells me that “changes are coming”, and that “Prior to this update, we ask that you log in to verify the accuracy of the information in your account.” There are several web links in the message that point to Amtrak web sites, but the key one, the one that says “Go to Amtrak.com Now and Update Your Profile”, links to “http://amtrak.bfi0.com/W0RH01300F84...redacted...30”.

Now... as best I can tell (no, I did not click on the link), this actually is legitimate. I made an Amtrak reservation last week, about two weeks after having received that message, and they have changed the way I have to log in (using my email address, rather than the user name I’d created before).[1] But the email message used Epsilon’s email service (bfi0.com), which they’ve apparently contracted to do their mailings, and the key link points back to Epsilon, not to Amtrak.

If this was, indeed, a legitimate mailing, I have something to say to Amtrak about it: You made a big mistake by contracting your mailings to that company. This email message looks exactly like a phishing message that’s trying to steal my login and password information. Don’t you know, as most of the rest of the world does by now, not to send out messages like that?

More specifically, here’s what makes it look like phishing:

1. The message claims to be from Amtrak, but does not use an amtrak.com address.
2. The premise of the message is the same as in many phishing messages: we’re changing our system, and we need you to log in and “verify” your information. It couldn’t match better if a phisher had written it.
3. All of the links that don’t matter are the real ones, but the operative link, the one you’re meant to click on, points to something else, something that’s not amtrak.com.
4. Making number 3 worse, the funny URL has a lot of random-looking junk in it.
5. It uses one of those suspiciously folksy signatures, “The Amtrak E-commerce Team”. As I said, it looks like a phisher actually wrote it.

And, the clues that it’s real? There are two. One is that it calls me “Barry”, which a phisher would probably not. They could have made a point of telling me that, but they didn’t, and many people would probably not notice it, nor realize that it lends some credibility to the message. On the other hand, clever phishers could do that also, in cases where they have email addresses associated with full names (which would be easy with my address).

The other is that bfi0.com is registered to a legitimate email marketing company, Epsilon (that should know better than to send out crap like this), and a thorough check of the message confirms that it almost certainly did come from bfi0.com, and isn’t just claiming so. The funny URL will get you to amtrak.com’s web site, but sends you through bfi0.com to get there because they’re counting the click-throughs for marketing purposes (maybe just for tracking, but it’s likely they’re getting paid more for more clicks).

So what should they have done? I’m glad you asked:

1. Set up DKIM, send the message out as amtrak.com (not as amtrak.bfi0.com), and make sure that the DKIM signature is verifiable.
2. Make sure all the links in the message clearly go directly to amtrak.com.
3. Do not encourage users to click a link in the message to log in anyway. Tell them in plain text to “go to amtrak.com” and log in there. Tell them that it’s safer if they do it that way, because it’s less likely to put their account information at risk.
4. Be less vague about what’s happening. Part of what makes the message suspicious is the vagueness: we’re changing something, but we’re not giving you any details.

I know that 2 and 3 are not what Epsilon and other marketers want to hear. Without being able to track click-throughs, they have a real problem in knowing how successful their campaigns are, and they can’t use that as a way to write their contract terms. That’s too bad, but, well, that’s just too bad. We just have to stop asking or expecting users to click on links in their email, especially funny-looking ones.

It’s garbage like this that keeps the phishers in business, by teaching people to be careless. Amtrak — and Epsilon — should be ashamed.
 

---

[1]Side issue: I actually hate the practice of using my email address as my login identity. It means that it’s harder for me to use domain-specific login identities, and strongly pushes me to use the same identity everywhere. It’s easy to see why the web sites like it, of course: it makes it easier for people to create accounts because they already have a unique name to use, and it reduces support questions about forgotten login identities — the web sites just tell you to enter your email address.

One problem with it, even for people who would prefer to use the same identity everywhere, is that there’s a strong tendency, because you’re using your email address, to use your email password too. That exposes your email, of course. It also means that you’re likely to have the same identity and password for multiple web sites, so someone who snatches your Amtrak information, say, can go start trying it on other sites, like airlines, stores, banks, PayPal....

Applications Area Architecture Workshop summary

On 11 and 12 February, the IETF’s Applications Area held an architecture workshop, and I promised to post a summary of it here. This will probably interest about 1% of my readers, but it’s also a way for me to put it down for my own reference. I’ll try to find something more stimulating for tomorrow.

I’m going to put the 1% stuff below the click. My apologies to those who read the feed; I don’t know how to get Blogger not to put the whole thing in the feed. So, honk if you’re a geek...

The goal of the workshop, broadly, was to look at possible new work in the Applications Area. We were particularly interested in what new ideas participants have, what they’d like to work on, what they think is missing from the standards right now, and that sort of thing.

We started with about 20 participants and a plenary session to bat the ideas around and to come up with a set of topics for breakout sessions. After each breakout session, we came back into plenary and had brief — well, sometimes not so brief, as the discussion developed — reviews of the breakout work. That there’s a lot of material related to HTTP, is partly due to the recent formation of the httpbis working group, aimed at revisiting the HTTP standard and advancing it along the standards track.

We ended up with the following set of breakout topics, here in no particular order:

• Use of HTTP for more than just web browsing. This group looked into the question of updating BCP 56 (RFC 3205), which gives advice on using HTTP. They started to sketch out what such an update would address, and one of the participants has agreed to work on a draft document.
• Protocol layering, looking at how protocols at the applications layer interact with those at the transport and network layers. The group subdivided the applications layer, conceptually, into sub-layers for semantics and protocol, and noted that the protocol sub-layer really needs some knowledge of lower layers, without considering it a layer violation.
• Localization and identity, considering aspects of protocols that need to change with different locales and different user identities. This also looked at discovery of local services. And it blended somewhat into internationalization.
• Synchronization: although there’s years of work behind this and there are many solutions here, we still have real user problems. Consider the personal address book: it’s just one person’s data, yet it can’t get synchronized properly between phones, cars, and multiple laptops. The group looked at separating semantics and conflict resolution from the transportation of changes and metadata, and they discussed what metadata are required for synchronization.
• XML schemas. The basic issue here is that XML itself doesn’t create interoperability. It needs a schema to lay semantics on top of the XML. I didn’t participate in this discussion, and there aren’t much in the way of workshop notes from it.
• URI templates, standardizing a mechanism for plugging functional templates into URIs. For example, each search engine has its own URI that will initiate a search, with the common aspect that the search terms are substituted into the identifier somewhere. This group looked at how to standardize that concept to make it easier for different services to be swapped in and out.
• HTTP authentication, looking at where to go with it to try to improve on the current state. The main point was to consider how to develop an HTTP authentication protocol that
  1. reduces the opportunity for phishing and
  2. is likely to be deployed (no small order, this).
  We came up with the following steps that would head things in the right direction:
  1. Develop an authorization framework such that:
     1. No identifier/password is transmitted, even over TLS.
     2. Using (a), eliminate the need for a user to ever enter a password in an HTML form. Users would be taught to enter passwords only in a password-entry widget, not in the web page itself. This would be a partial solution, making it easier to keep users from giving the bad guys their passwords.
     3. Use an authentication mechanism (such as a public key method) that makes a password useful only locally (the password is to the local keychain, for instance, which gives access to the private key). Exposure of the password to the bad guys no longer matters, even if they convince the user to do it. This is a more robust solution.
  2. Firefox is a good starting point. Make a Firefox extension prototype a prereq for real work here. The Firefox extension can “discourage” entry of passwords into HTTP forms, to enhance the effectiveness of 1b, above.
  3. Get input about requirements, from “real” phishing targets. To that end:
     1. Engage the Anti Phishing Working Group (APWG).
     2. Look for an HTTP authentication workshop resulting from the “bar BOF” at IETF 70.
     3. A participant noted that talking to banks and such is useless, and suggested engaging congress (senior staffer to chair of House Banking Committee, for instance).
  User-interface changes can make a big difference too:
  1. We discussed the idea of “directed identities” built into the browser — the browser would strongly discourage the user from using an identity directed to, say, boa.com on a bogus site such as b0a.com or boa- login.com.
  2. We discussed the idea of extremely obvious and non-spoofable UI indications, such as colour cues and other OK/warning mechanisms. We noted that anything that will work has to be very hard to miss or misunderstand. We noted also that most have some sort of accessibility issues (colour cues don’t work for the colour-blind, for example).
• Email re-architecture, considering whether it would be wise to do some major redesign of Internet email, and looking at a specific proposal. We started by questioning whether reworking email protocols is even important any more: “Is it the case that we already have more email r