Internet and e-mail policy and practice
including Notes on Internet E-mail


2004
Months
Jan

Click the comments link on any story to see comments or add your own.



RSS feed

Add to My Yahoo!

Subscribe with Bloglines

Subscribe in NewsGator Online



[Valid RSS]

Home

31 Jan 2004

What is on-line identity? Email

The more I think about what identity means in the on-line world, the less I think we're doing a good job with it.

Most on-line identity systems are set up to prove that you're the same person you were last time. For a lot of kinds of e-mail, that's fine, the first time you get mail from someone you can decide pretty quickly whether it's mail you want, and add the person to a whitelist or blacklist. When more mail arrives from the same person, you read it or throw it away.

A more subtle but probably more important kind of identity is proving that people are who you think they are. There's a lot of identity verification that we do in day to day life that doesn't carry over very well into computers. For example, I grow and shave off a beard from time to time. My driver's license picture doesn't have a beard, but people who look at it and at me have no trouble figuring out that even with the beard, it's close enough. Face-to-face, we're good at telling what details matter and what details don't. Online, we aren't. I use a lot of different e-mail addresses, both to keep mail for different roles and jobs separate, and to track mail from correspndents I don't entirely trust, like on-line stores that demand an address when you order something. It's extremely tedious to explain to security software that all of these addresses are equally me, they're just different whiskers. At the least, I need to enter all of the addresses into whatever software creates and verifies certificates, or worse I have to keep a certificate per address and fish out the one that matches whichever address I'm currently using. That rapidly becomes more trouble than it's worth.

Sometimes the exact identity of a person or organization isn't as important as identifying them as a member of a group. For example, when you're looking for a policeman, any real policeman will do, but almost-policemen such as security guards won't. When I want to cash a traveller's check (or these days more likely get a cash advance on my Visa debit card), I need to find a bank but it doesn't much matter which one. Banks are easy to identify, since they have tellers, a vault, and an FDIC sticker on the window. Again, it's not hard to figure out whether a person or an institution is part of a category, using cues so familar that we often don't know what they are.

This sort of category identity is if anything more important on-line than it is in day to day life. If I get e-mail from CITIBANK-ACCOUNTS.COM, is it really about my account at Citibank? Nope. As spammers and phishers have found, there's an unlimited variety of names that are enough like well-known names to fool people. Current signing schemes like SSL don't help, because they can assure you that mail from CITIBANK-ACCOUNTS.COM or the web site WWW.CITIBANK-ACCOUNTS.COM is really from the owner of the domain CITIBANK-ACCOUNTS.COM, but they don't tell you whether that's Citibank.

The obvious solution is industry specific certification. Banking should be the first industry to do that, both because (in the US at least) there is a clear definition of who's a bank, S&L, credit union, or whatever, and who isn't, and because, well, banks have all our money.

There's two ways one might do the certification. The first is a certificate signing agency, sort of like Verisign and the other agencies that do SSL signing now, but just for banks. The signing part would be technically straightforward to set up, but the hard part would be branding, telling consumers that if it doesn't have a Golden Dollar Sign seal, an e-mail message or web page isn't from a real bank.

The second is an industry specific top-level domain. There are some so-called ``sponsored'' TLDs now that restrict registrants to particular industries, including .museum, .coop, .aero, and .pro. So far, the sponsored domains have all been complete failures. Most of them saw the domain as a marketing gimmick, and provided nothing of value to the registrants that they wouldn't get from the domains they already had in .com and .org. For the most part, security and trust in their domains isn't an issue. (``Oh, no, what a fool I was, they said it was a co-op, but it was really a producers' collaborative!'')

The .pro domain is different. It's supposed to be for licensed professionals, doctors, lawyers, and accountants. Applicants have to verify their credentials at registration time, and they say they'll provide SSL certificates with each registration. Unfortunately, .pro seems permanently stuck in the pre-start-up phase and it has as far as I can tell, no registrants at all yet. Too bad, since it would be nice to be able to depend on mail from my accountant coming from pwc.cpa.pro, ey.cpa.pro, deloitte.cpa.pro, or kpmg.cpa.pro, and be confident that a .pro address isn't a creative phisher in Romania.

Would it make sense to set up .bank, overseen by the FDIC and other bank regulators, with registrations limited to regulated banks and similar financial institutions? Heck, yes. I don't understand why they haven't done it yet.


posted at: 23:10 ::
permanent link to this entry :: 0 comments
Trackback link is http://weblog.johnlevine.com/Email/identity.trackback


19 Jan 2004

Mailing list best technical practices Email

You might think that it wouldn't be hard to run an e-mail mailing list, but you'd be sadly mistaken. (By "run", here I mean the technical parts of adding and removing addresses, sending mail, amd receiving responses. At Yahoo Groups, it's Yahoo running the lists, not the list managers.)

I've seen a few BCP (Best Current Practices) documents floating around like ISIPP's standards from a meeting last September.

So as not to miss the boat, here's mine.

  • DO follow all the RFCs, as noted below.

  • DO use real To: and From: addresses. The To: address can be either the list address or the recipient address. The From: address should at the least be something that will catch "unsubscribe" or "remove" responses and act on them them.

  • DO use a consistent From: address, since people use it to sort and whitelist your mail.

  • DO use a valid envelope MAIL FROM. If you send separate messages, use VERP or some other system that will identify the bouncing address.

  • DON'T resend a message that's rejected with a 5xx code.

  • DO wait a reasonable time before retrying a message rejected with 4xx, and only retry it a finite number of times.

  • DO collect and count bounces, and remove addresses that bounce repeatedly.

  • DON'T put removed addresses back on the list "just in case the bounces were a mistake."

  • If your message is in HTML, DO include all of the MIME message headers that identify it as HTML. (You'd think this would be obvious, but mailers from the NY Times to Air Canada send HTML messages missing the MIME-version header.)

  • DON'T use Javascript or other security-challenged features in HTML mail. Most mail programs don't run Javascript in mail messages anyway.

  • DO remove any addresses that people tell you to remove. DON'T insist that people send "remove" from the subscribed address, use your web unsubscribe page, or otherwise argue with remove requests.

  • For new subscriptions, DO positively confirm that the address you have is in fact the one that the user meant to subscribe. A remarkable number of people don't know their own address.

Some less technical points:

  • DO send mail on a regular schedule, like once a week or once a month, so users don't forget that they subscribed.

  • DO use straightforward subject lines and message bodies. Misleading subject lines are a highly reliable way to identify viruses and spam.

  • DO say why the recipient is getting the message, e.g. "you signed up for the cheese of the month list on September 4, 1997." If you get addresses from co-registration, tell the recipient where they signed up, and not just "one of our marketing partners."

  • DO make it easy for people to change or cancel their subscription, like a link at the bottom that takes them to a web page that already knows what their address is. If you make it hard to unsubscribe, users and system managers will block your mail rather than waste time arguing.

  • DON'T send huge messages. If you want to include a 100K graphic or animation, put it on your web server and link to it. Your friends will stop being your friends about the second time they have to download your 200K missive over a dialup link.

  • DON'T believe anything that a list vendor tells you about the source of an "opt-in" list. Whatever the people on the list opted into, it's unlikely to have been mail from you.


posted at: 02:24 :: permanent link to this entry :: 0 comments
Trackback link is http://weblog.johnlevine.com/Email/bcp.trackback


18 Jan 2004

What is it with marketers? Email

Marketers are not all stupid or immoral, despite frequent claims to the contrary in the anti-spam community. But when they try their hand at on-line marketing many of them make what seem like obvious mistakes, due to false analogies between e-mail and other media.

I wrote this note over a year ago, but it's just as relevant today, particularly as CAN SPAM encourages some who were sitting on the fence to give it a try.

... read the mini-paper on-line
... mini-paper printable version


posted at: 01:07 :: permanent link to this entry :: 0 comments
Trackback link is http://weblog.johnlevine.com/Email/mkt.trackback


Selective Sender Email

Several proposals for Lightweight MTA Authentication Protocol (LMAP) have been gathering attention of late. They all define ways for a domain to specify that some particular IP addresses are allowed to send mail for that domain, and others aren't.

LMAP has a variety of technical problems because there are surprisingly many ways that mail can be sent from unexpected places.

Selective Sender, a simpler scheme that has been proposed before under other names, is much simpler.

... read the mini-paper on-line
... mini-paper printable version


posted at: 00:32 :: permanent link to this entry :: 0 comments
Trackback link is http://weblog.johnlevine.com/Email/ss.trackback


Problems with Designated Sender Email

Designated sender (DS) schemes attempt to list the valid IP addresses that can send mail for a domain. They all suffer from a variety of problems that make them less than ideal anti-spam approaches.

... read the mini-paper on-line
... mini-paper printable version


posted at: 00:32 :: permanent link to this entry :: 0 comments
Trackback link is http://weblog.johnlevine.com/Email/lmap.trackback


02 Jan 2004

Welcome to Blogistan Email

Why another weblog? Partly vanity publishing, partly to keep track of all the notes I make about the technology of e-mail. These days the biggest topic is spam filtering, but there's a lot more to e-mail than that. We look at approaches for handling real mail to keep the flood under control, applications layered on e-mail and more.

Welcome aboard.

John Levine


posted at: 12:00 ::
permanent link to this entry :: 0 comments
Trackback link is http://weblog.johnlevine.com/Email/blogistan.trackback


Topics


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

Spam resource
(Al Iverson)

The Spam Diaries
(Ed Falk)

Word to the Wise
(Laura Atkins)

Lextext
(Bret Fausett)

Related sites

IRTF Anti-Spam Research Group

Network Abuse Clearinghouse

Coalition Against Unsolicited Commercial E-mail



© 2005-2008 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.