Mail authentication schemes like DKIM and the new dmarc.org group use cryptographic signatures to help authenticate mail and prove that it really is from who it purports to be from. So, if the mail can authenticate the sender, the phishing problem goes away, right?

Unfortunately not. One huge problem is that even if you have all the crypto stuff so you can be 100% sure that a message really is from, say, BANK-AMERICA.COM, you don't know whether BANK-AMERICA.COM is actually your bank or not.

I've made a little game called Phish or Fair. It shows you a domain name, you guess whether it belongs to Bank of America. Try it out and see how you do.

Then see if you can figure out why a bank would use over a thousand different domains. My example here is Bank of America, but they're no worse than other big banks; I picked them because their name is easy to search for.

If banks were serious about phishing, they'd pick one name, one domain, and use that consistently. But they don't.

PS: BANK-AMERICA.COM belongs to some guy in France.

Written by John Levine, Author, Consultant & Speaker

Scotland Yard. Some of the interest is due to marvel that two such sophisticated organizations could be had, some is due to schadenfreude, and some is probably despair: if the bad guys can get at these folks, is anyone safe? To me, though, the interesting thing are the lessons we can learn about what's wrong with security. Many of the failures that led to this incident are endemic in today's world, and much of the advice we're given on what to do is simply wrong or arguably even harmful.

The first issue is how Anonymous managed to record the call. The ways we'd see it done in a movie — tapping a phone line or listening to law enforcement official's cell phone — are comparatively difficult to do. They're not impossible, but they're not the easy way for a task like this. Rather, what appears to have happened is what most outside security experts immediately suspected: Anonymous read an email giving the details of the call, and simply dialed in, in the same way as the intended participants. The message was sent to "more than three dozen people at the bureau, Scotland Yard, and agencies in France, Germany, Ireland, the Netherlands and Sweden;" a single security flaw anywhere along the chain could have resulted in the leak.

Here we see the first flaw: the call details were, effectively, a shared credential. It is quite probable that the conference call moderator had no idea who had dialed in. We see the same phenomenon with role accounts: many people share the password for the login, email access, etc. It may happen in the large — postmaster@example.com — it may happen when a vacationing executive gives a secretary the password to his or her email account; it may happen when spouses or romantic partners share passwords. Whatever the reason, it creates a security risk.

Reading further into the article, we see that "One recipient, a foreign police official, evidently forwarded the notification to a private account". At that point, it's tempting to blame that official, say he or she was poorly trained or disobedient, and stop worrying. Apart from the self-evident fact that a single security lapse shouldn't compromise everything (a proposition easier to state than to make happen), I strongly suspect that this unnamed official was behaving very rationally: he or she either wanted email access that was too inconvenient via the proper mail servers, or wanted a different human interface. If this person had no access to work email from home, or felt that, say, gmail was enough better that their productivity was improved, it's not surprising that this would happen. It shouldn't happen — and one would hope that a police official working on cybercrime would understand the risks — but in a strong sense the failing was organizational: if my hypothesis is correct, they may have failed to make it easy for people to do the right thing. Let me stress this: a security mechanism that is so inconvenient that it tempts employees to evade it is worse than useless, it's downright harmful. (Note well: I'm not saying that this official did the right thing; I'm saying that organizational policies or technologies may have led to too much temptation for people who are trying to be more productive.)

But how did Anonymous know which outside email account to monitor? This article notes that assorted groups have made a habit of targeting law enforcement email servers, with some success against less-sophisticated police organizations. That would yield a list of email addresses, and perhaps passwords. Perhaps more importantly, it can show who was using an outside mail server, one that isn't protected by VPNs, firewalls, one-time passwords, and the like. At that point, the attackers have several ways to proceed.

First, they could try this law enforcement email password against the outside mail server. The odds are high that it will succeed; far too many people reuse passwords. And why do they do this? Because they have too many passwords to remember, especially if they're all "strong". And of course, people are forbidden to write them down.

Most of the advice we get on security starts with "pick a strong password". (Look at CERT's advice: the very first thing it tells people to do is "always select and use strong passwords". Patches, a really effective defensive measure, are mentioned fourth.) Strong passwords are not a bad idea, but you're in much more trouble if you reuse passwords. No one can possibly memorize all of the passwords they have; reuse is the usual answer.

A second way in which the attackers could have compromised the official's account is via a spear-phishing message, booby-trapped to install a keystroke logger. That's been seen, though more often in a national security context. If the attackers did this, even encrypting the emails wouldn't have helped; the same malware that stole the login password could probably steal the private key as well. But I'm pretty sure that no encryption was employed; most encryption systems are too hard to use. Smart-card based decryption would have helped (though such things are far less convenient to use); though there are still attacks, they're more involved, and arguably less available to a group like Anonymous.

It's clear that there wasn't a single failure involved; in particular, the crucial mistake of forwarding work email to a personal account was quite plausibly a rational response to organizational policies. Preventing recurrences of this kind of incident will not be easy; there are too many weak spots.

Written by Steven Bellovin, Professor of Computer Science at Columbia University

What is DMARC?

This is very much a summary of DMARC in a nutshell (I will probably write an article about this in the future), but from the website:

A DMARC policy allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes — such as junk or reject the message. DMARC removes guesswork from the receiver's handling of these failed messages, limiting or eliminating the user's exposure to potentially fraudulent & harmful messages. DMARC also provides a way for the email receiver to report back to the sender about messages that pass and/or fail DMARC evaluation.

When I first heard about DMARC, I said to myself "Self, why do we need another email authentication protocol?" The answer is that DMARC is not another protocol but instead leverages existing email authentication protocols and provides feedback to the spoofed domain.

SPF already provides a way to say: "If this message fails an SPF check, discard the message." It's called a Hard Fail. However, not all hard fails are illegitimate (there are significant false positives with SPF). DKIM, in itself, doesn't provide a way to discard a message if it fails an authentication check. This makes it less useful in securing the Internet (i.e., it is a barrier to adoption).

Besides which, what happens if an SPF check asses but a DKIM check doesn't? And if one of them fails, who should you tell? DMARC provides a mechanism that says: "If one of these checks fails, discard the message." But furthermore, it also provides a way to tell the responsible party that the message failed a check. For example, if security@paypal.com fails a DMARC check (either through SPF or DKIM), the email receiver can send the message to an email address that says "Hey, this message failed an SPF check. Was it legitimate or not?" If it is a false positive (perhaps a new server brought online), Paypal can add it to its SPF check. If it's a phishing message, Paypal can investigate to have the website taken down.

The strength of DMARC is that it is a stronger way to protect a brand from being abused; receivers can discard spoofed messages and senders can figure out just who, exactly, is sending mail as them.

The weak point of DMARC is, unfortunately, the weak point of SPF and DKIM — spammers and phishers don't need to spoof a domain in order to fool users into taking action. If a spammer sends mail from security@paypal.com.yakzas.com (a fictitious domain), many users just see that first part (paypal.com) without being more aware that there is more to the message.

And if a phisher signs up for a cloud service that issues temporary credentials, they can create the account paypale.onmicrosoft.com and send spam from there to avoid IP reputation blocking (and to the spammer that is abusing our Office 365 service, we know what you're doing, you jackass) while hijacking the reputation of another brand in the From address.

The strength of DMARC is not so much that it combats phishing but that if a good domain is authenticated, mail user agents (like Gmail, Hotmail, Outlook, etc) can highlight that the sender is a trusted sender and highlight it in blue or put a little icon beside it. Since users use visual clues to make heuristic decisions, the lack of a trusted symbol can train people to be suspicious.

Anyhow, it's nice to see that the authentication/validation protocols are consolidating.

Written by Terry Zink, Program Manager

This post is about IP address reputation with some background on why IPs are so important and why ISPs focus so heavily on the sending IP.

Why IP addresses?

ISPs built reputation around IP addresses because it was one bit of data that malicious senders / spammers couldn't forge. The connecting IP is a fundamental part of the network transaction and if you forge an IP then SMTP can't work. Because that was the reliable data they had to work with, that's what they used. Even now, when there are other kinds of data, the IP address is still the first thing the receiving MTA sees.

What is IP reputation?

IP reputation can best be summed up as "past performance is an indicator of future results." In other words if recipients responded well to mail from an IP address in the past, then they're likely to respond well to new mail from that IP address.

How is IP reputation measured?

While each spam filtering company and ISP have their own ways of calculating the reputation of an IP address, there are some similarities in what they measure.

• How many non-existent email addresses is this IP attempting to deliver to?
• How many abandoned email addresses is this IP attempting to deliver to?
• How many "known bad" email addresses (spamtraps) is this IP attempting to deliver to?
• How many recipients complain about receiving this mail?
• How many recipients complain about not receiving this mail?
• How respectful of my resources is this IP?
• Does this IP keep connections open for long periods of time?
• Does this IP retry deliveries too aggressively?
• Does this IP stop mailing addresses after receiving a "user unknown" message?
• Is this IP address configured as if the associated machine was infected by a virus?
• Is this IP address listed on blocklists we use?
• That is by no means an exhaustive list of what ISPs measure. If they can measure it they've tried. If the measurement helps them separate spam mail from not-spam mail then they're using it.

How fast does IP reputation change?

IP reputation is often measured over multiple time periods. ISPs can look at a 1 day, 7 day, 30 day and 90 day reputation. A good analogy is stock prices. Prices can be very volatile in the short term, but more consistent over the long term. A single bad day, where one or more reputation measurements go bad, may affect delivery that day or the next day but won't damage an overall good reputation. Likewise, a few days of improved mail may not be sufficient to counter months of poor reputation.

How is IP reputation used?

Mail from IPs with a high reputation is accepted faster and at a higher rate than mail from IPs with a lower or unknown reputation. IP reputation can also influence whether mail is delivered to the inbox or the bulk folder.

Key IP Reputation takeaways

• IP reputation is about how recipients react to mail from that IP. Happy, content recipients turn into good delivery.
• Brief changes (for good or bad) don't necessarily ruin delivery over the long term.
• Steady improvements will result in improved reputation.
• It may takes as much time to change a reputation in one direction or another as it took to establish the reputation in the first place.

Written by Laura Atkins, Founding partner of anti-spam consultancy & software firm Word to the Wise

ACMA receives a major compliment

In 2004, when I first entered the anti-spam arena, this was a mantra that I had to hear very often: "Spam is international. We cannot do anything", spoken with a lot of emphasis and some despair. Unfortunately in 2012 this is still true for many countries. Not because of the fact that it is impossible to do something about spam, no, but due to a lack of initiatives. I think that a great compliment to Australia's ACMA (Australian Communications and Media Authority) was published on CircleID in a comment to an article about the impact of Canada's spam law on local businesses. Brett Watson, an Australian internet engineer, writes:

"However, my present (and general) lack of anything to complain about reflects well on the law and its enforcement… Perhaps what's most telling is that I have, for the first time, subscribed to some advertising newsletters in recent years. I don't feel the need to jealously protect my email address any more, or diligently use uniquely tagged addresses when handing them over. I trust ACMA to keep the companies in line, and the trust seems well placed so far."

This proves that fighting spam is effective and that the combination enforcement with filtering by ISPs keeps mailboxes clean. Spam hasn't gone away, but at national level companies are disciplined and mostly act within the law in the few countries with vigorous enforcement bodies.

Who enforces what?

Privacy and spam are closely related. Spam is seen as an invasion of privacy. But it goes way beyond mere privacy. Privacy sensitive data is often used, sold or worse stolen in order to approach people. Whether to sell a(n illegal) product, phish for more (bank)data or industrial espionage, a stolen e-mail address is often the basis of law violations. The patchwork of enforcement agencies, unclear enforcement powers, the lack of understanding of the issues at stake, of resources, training or powers, the unavailability of online reporting of spam or cyber crime, all make that enforcement is far from optimal in most countries.

Standardisation of spam and cyber crime law

Could a standardised law, with a standardised toolkit for enforcement agencies make a difference? Yes, I think that it would. For the public it would mean that there is the certainty that when the law is broken, it is clear who to report to and that it is likely that an investigation follows. That it makes a difference to complain. For senders it also sets clear boundaries. Their business continues, as is proven in e.g. The Netherlands, but in compliance with the law. Next to that it offers this clearness in 27 states.

As spam, e-fraud, phishing, cyber crime and worse are all so closely related and often involves several countries, it makes sense to be more directive from Brussels. At national level there are so many different laws, ministries and enforcement agencies involved, that coordination there is almost utopian. Next to the fact that success without industry participation is clearly unthinkable. Despite the fact that the Dutch National Cyber Security Centre is a promising initiative, it is obvious that for most countries this form of public-private cooperation is hard to attain.

A proposed course of action for the EU Cyber Security Centre

The discussion about the EU Cyber Security Centre is under way. Let me give a pointer on what the centre could do. To my mind it ought, also, to actively collect, analyse and share data with those involved: public and private entities, universities. This gives the centre coordinative powers in matters cross border and across different enforcement organisations as well. Two difficult hurdles taken… should this come to pass. The combination of the overview and oversight with the transparency caused by available, shared data makes all concerned answerable for their (lack of) actions to the centre and each other. I am also convinced that this model will lay the foundation for cooperation with whole new groups of Internet industry partners that are now harder to reach/convince.

Ambition at Commissioner level

If Commissioners Kroes, Malmström and Reding used their powers to harmonise the laws and enforcement in the way Ms. Reding proposes for privacy, i.e. the same law and enforcement tools, standardised enforcement agencies and a point of case handling, the fighting of privacy infringements, spam, malware and cyber crime may actually take a turn for the better. They are so intertwined that another approach is (well, should be) almost unthinkable.

The combination of a pro-active EU Cyber Security Centre with a layer of harmonisation where enforcement is concerned will prove to be a structural step forward from the present situation in many countries. Yes, this is ambitious, but it is clear that the present approach is not going to change much. Everything cyber is still a field day for criminals and a private company, Microsoft, so far is the most successful in fighting botnets. This ought to be different, shouldn't it?

Written by Wout de Natris, Consultant international cooperation cyber crime + trainer spam enforcement

Known as CASL, the new law aims to crack down on spammers and mailing list companies but in doing so, tightly regulates the way businesses can market to prospective customers via email and online.

In a nutshell, CASL requires a business to obtain consent from the recipient before it sends out commercial electronic messages (CEMs). It isn't limited to email; consent must be given for any electronic message, which could also include messages sent via social media, text messaging, instant messaging, sound or video. If your business operates outside of Canada, you shouldn't assume the Anti-Spam Act doesn't apply to you. If a computer system within Canada is used to send, receive or even route the message, then the law could also apply to you.

It is in obtaining consent before sending an electronic message where the Canadian Anti-Spam Act differs from its American equivalent. The United States' CAN-SPAM Act requires that recipients are given an opt-out option from commercial messages but under CASL, recipients must opt-in to receive electronic messages.

The fines for violating the Anti-Spam Act are hefty. The maximum penalty per violation for an individual is CAD $1,000,000 and $10,000,000 for corporations. With potentially crippling fines waiting in the wings for violators, how can you ensure your company is compliant?

The first thing is to be aware of which messages require consent before they are sent. There are a few exceptions, which include personal relationships or when the company is providing requested information. Consent can usually be implied if there is an existing business arrangement of two years or more, or if an email address has been disclosed in the course of business. You can read more about exceptions to CASL here.

If your electronic message doesn't fall under an exception category, then you will need to obtain consent before sending it. The message should also include an unsubscribe mechanism. To ensure compliance, your company should establish procedures to obtain consent for electronic messages and educate staff on the Anti-Spam Act. The most important thing to remember before you press 'send' is the onus is on your company to prove you received consent.

Do you operate a business in Canada? How do you think the Anti-Spam Act will affect the way you market electronically? Please contribute to the conversation below.

Sources:
Canada's Anti-Spam Legislation: Casting a Wide Net
Anti-spam law draws backlash
Three 2011 developments that changed your inbox forever
Canada: Preparing For Canada's New Anti-Spam And Online Fraud Act
CAN-SPAM Act: A Compliance Guide for Business

Written by Susanna Sharpe, Social Media Manager

Abuse-POC, a.k.a. abuse-c or abuse-mailbox entries are the subject of ongoing developments at AfriNIC, APNIC, ARIN, LACNIC, and RIPE. It may take a while for Regional Registries to converge and complete their work. Abusix.org offers an Abuse Contact DB that can be queried via DNS, until then.

Some network providers allow clients to specify abuse-mailboxes along with other contact info, while others don't. They don't seem to be striving to act as the Internet police. They operate according to their commercial policies, albeit they try and comply with local laws. Thus, mailbox providers don't always have full control on what gets published on the number databases, independently of their behavior.

On the other hand, the DNS was conceived to avoid reliance on numbers and use names instead. The advent of IPv6 may exacerbate that principle. Techniques like DKIM and SPF allow to associate a domain name to a mail message. Such techniques are mature enough to yield results that are more reliable than those supplied by rDNS, which suffers the same limitations of control as number databases. However, there is no standard way to learn whether a domain offers a feedback loop, or what is the email address to be used for (automated) abuse reports. The only hint is abuse@domain, as specified by RFC 2142, which can be deemed heuristic at best. (Contrast that with the fact that abuse-c seems to be going to be mandatory, and that providing false contact data may lead to deregistration of IP blocks, at least at some RIRs.) Abuse.net offers a name-to-abuse-mailbox functionality, but there is no prospect similar to the number case, yet.

There is an IETF working group,

Messaging Abuse Reporting Format (marf)

the same that standardized the ARF format, that might make some decisions about standardizing such reporting-discovery functionality. However, the working group experienced a drop of participants recently, for various causes. The likelihood that it will complete its work is getting lower and lower, unless new people will want to review its drafts and post comments on its mailing list. If this is a call for participation, you have been called!

Written by Alessandro Vesely, Tiny ISP and freelance programmer

Another theory about greylisting is that if you defer mail from a new IP, by the time the sender retries, if it's sending spam it'll have hit spamtraps and been added to blacklists. I recently realized that I have enough log data to check that theory, so I collected some statistics for the past week, which is as long as I keep logs about mail connections from blacklisted hosts. The IPs I greylisted broke down like this:

	Count	Percent
No retry	3,803	35.8%
Retry too soon	3,345	31.5%
One retry	1,183	11.1%
More than one message	1,635	15.4%
Blacklisted	561	5.3%
Retried, blacklisted later	89	0.8%
Total	10,616	100.0%

No retry and Retry too soon are senders that greylisting kept from sending anything, again, about 2/3 of mail. (My greylister requires that the sender wait at least a minute, since some spamware sends several messages a few seconds apart.)

The next two are senders that retried successfully and sent one message, or more than one message. (If a sender retries too soon, then retries again after more than a minute, it's counted in one of those two categories.) Blacklisted means that when the IP retried, the IP was on one of the a blacklists I use, in nearly all cases Spamhaus Zen. The last line is IPs that retried successfully, but were blacklisted when they tried to send other messages later.

The 5.3% for Blacklisted probably overstates how much mail was caught by waiting to see if an IP was blacklisted. My logs don't say whether the delivery attempt that was blacklisted was trying to deliver a message with the same To and From addresses, in which case it would have been delivered, or a different message, in which case it would just have been greylisted again. Spot checking shows IPs that were greylisted repeatedly, before appearing in a blacklist, which suggests that they were sending different messages.

Also, for the few IPs that were blacklisted later, they were generally blacklisted much later, hours or days later, far longer than any reasonable greylisting strategy would force mail to wait.

So greylisting still works, but it's almost entirely because spamware doesn't retry, not because it gets blacklisted.

Written by John Levine, Author, Consultant & Speaker

We've now been using greylisting for close to a decade, and some people have argued that it's no longer useful, since the bad guys could easily fix their spamware to retry, or since bots are so cheap, they could just send everything twice. So does it still work?

I recently went through my greylister's logs and collected some statistics for both a recent week, and the past year, about hosts that I greylisted:

	Week	Year
No retry	12121	294812
One retry	7456	62402
Many messages	4956	74590

The first row is the number of hosts that got a soft fail and never came back. The second row is the number that retried the message that failed, but never sent anything again, and the third row is the number that retried and sent more messages after that.

As you can see, for the week, about half of the greylisted hosts didn't retry, and over a year, about 2/3 didn't. That's still a lot of mail my mail server didn't have to filter. I attribute the different ratios to the shutdown of several botnets over the past year, evidently botnets that didn't retry.

So it's certainly not a magic bullet (what is?) but greylisting still is an effective way to deter a lot of spam cheaply.

Next, Greylisting Still Works - Part II

Written by John Levine, Author, Consultant & Speaker

Signing email transitioned from a proposed standard to a draft standard (RFC6376 — one of the new RFCs) over at the IETF a few days ago. The other is RFC6377.

Let's go through a brief history of DKIM RFCs to refresh our memories –

RFC4871: May 2007 → the original DKIM RFC

RFC5672: August 2009 → an update to RFC4871, which clarifies the nature, roles, and relationship of the 2 DKIM identifier tag values that are candidates for payload delivery to a receiving processing module.

RFC6376: September 2011 → This cleans up the original version(s) of DKIM, thereby knocking off RFC's 4871 & RFC5672.

RFC6377: Recommended practices for using DKIM, mostly focused at mailing list managers — with some useful guidance.

Throwing a little light on DKIM (DomainKeys Identified Mail), it's a method of associating a domain name to an email, allowing a firm/organization to assume responsibility of messages that is validated by recipients. Validation is based on public-key cryptography. This allows mail transfer agents (MTAs) to sign email messages that pass through them — and to also verify a signature attached to an incoming email. These "signatures" — which use public key cryptography - are linked to domain names (as mentioned above), and then the public keys are published via DNS.

Reference: The IETF RFC Index at http://tools.ietf.org/rfc/index

Changes to WHOIS Query Behaviour

ARIN announces a pending change to Whois query behavior on port 43

Prior to 25 June 2011, a query for an IP address in the ARIN region would return with that assignment/allocation within the ARIN region, and a query in the ARIN region for an IP address with no assignment/allocation would result in a "no match" response. On 25 June 2011, a change was misapplied. The intent of this change was to return ARIN's /8 for IP queries within ARIN's region for which there is no assignment/allocation, a behavior meant to align ARIN's Whois output with that of the other RIRs. However, this change introduced an unintended behavior of returning ARIN's /8 (in addition to the desired results) in responses where IP addresses had been assigned or allocated. This change in behavior has created some confusion. On 2 October, ARIN will reinstate the previous behavior for Whois IP queries so that results are returned the way they were before 25 June. ARIN has provided two examples of a Whois query for reference: one with ARIN's /8 returned in the result set hierarchy, and one without ARIN's /8 returned in the result set.

Whois-RWS behavior will not change as it was not affected by the configuration change made on 25 June.

Reference: ARIN's Announcement Archive

Updates at Hotmail's Postmaster Pages:

I can't accurately confirm exactly when they updated their postmaster pages, but I can say its recent. This was split into 2 areas — one for Sender Solutions, and the other for ISP Solutions.

• Sender Solutions is an overview of useful services beneficial to senders. These cover stuff services like a postmaster page, SenderID, Return Path Sender Score Certified Email, Junk Email Reporting Program (JMRP), Smart Network Data Services (SNDS), and deliverability issues support.

• ISP Solutions is an overview of useful services beneficial to Internet Service Providers (ISPs) and mailbox providers (MSPs). These also cover similar services like the Sender Solutions (with the exception of Return Path Sender Score Certified Email).

Hotmail's Postmaster home page is at http://mail.live.com/mail/postmaster.aspx.

Written by Udeme Ukutt, Postmaster

As social networking continues to grow in popularity, so too does our individual online identities. No longer are we members of a close knit circle of local friends and family, but members of a global social circle that breaks geographical barriers. Our friends are now all over the world as opposed to all over the community. Our business partners, customers, and professional peers are no longer found in the office, but across the Internet as a whole.

It may be considered a morbid subject, but planning for your digital life after death, and how your virtual affairs should be handled, is fast becoming just as important as the financial and business affairs we consider common matters for estate planning. Virtual property, just as real property, has equitable value that may be lost when you die. Registered domains, web sites, and the contents of an email inbox, these are all types of virtual property that we simply fail to take into account when planning how our estates and property are to be handled.

When assessing your post-mortem digital footprint, as part as your overall online identity management, there are several key areas to keep in mind.

Registered Domains..If you own a domain that is part of a known or popular brand, do you want your brand to disappear upon your death? If not, you need to determine who will take ownership of the domains and how that will be done legally.

Websites and Intellectual Property. As the owner of a website and associated intellectual works, keep in mind that your website will require maintenance and funding if it is to remain online. Who will take over operations? Will someone continue to pay for hosting?

PayPal, eBay, and other sources of online revenue. If you do business online, maintain some type of charitable contribution system, or handle any other type of online revenue stream, who will assume those accounts and the associated funds? Will your online store or auctions be maintained, and if so, by whom? If funds are currently in your accounts, what happens to those funds?

Social Networking, Online Profiles, and Email. While most of these accounts will simply expire due to inactivity, you should consider the online friends and social circles you participated in. Will you have someone spread word of your passing? Will you remove your accounts, or have someone update your status for a final time?

Before you can plan for how your online identity is managed after you are gone, you must first determine the size of your digital footprint. How many accounts do you own, what services do you use, and where do you store digital assets or intellectual property? Start by compiling a complete list of your accounts, including passwords (making this the perfect opportunity to also assess your personal online security posture.) Note the type of accounts, and what important information you have stored in each.

Once you have a list of online assets, you can begin to plan how each account will be managed. One of the simplest methods is to prepare a formal document, similar to a will, with the list of accounts, passwords, and instructions for each account. While this in itself is not a legally executable document, you can ask a trusted family member or friend to ensure your instructions are carried out upon your death, or incorporate this as a component of a legal will.

Keep in mind, the Terms of Service for many online services strictly forbids the sharing of your account information, or access to your account by anyone other than yourself. By providing someone else with access to your account, you may be violating the terms of service, but an argument can be made that your documented instructions constitute the equivalent of granting a Power of Attorney to someone, and therefore legal. Depending on the types of accounts and the information contained in each, you may want to have an attorney assist in drafting your instructions to ensure they are legally enforceable.

In addition, several leading services, such as Yahoo, for example, have strict Terms of Service and will permanently delete all of your accounts and associated data upon notice of your death. Before formally notifying such services of your death, all data should be retrieved and securely stored as part of your instructions. As part of your planning, take the time to familiarize yourself with the Terms of Service for each online service on your list, noting any that may require special handling prior to notification.

There are also several commercial services available online that, upon notification of your death, can modify, transfer or erase your online accounts, send final email messages, pass on important files, and take other actions on your behalf. LifeEnsured, Entrustet, and LegacyLocker are examples of services that help to manage your online assets in the event of your disability or death.

Lastly, there is the option of doing nothing at all. Your inbox will continue to accumulate new mail until it reaches the mailbox size limit. Your online status updates, tweets, and latest blog posts will cease to change. Your registered domains will eventually expire, and your web site hosting plans will go unpaid and at some point will be removed. Your online friends will wonder where you have gone, and eventually they will grow used to not seeing your online status icon anymore. Your digital footprint will slowly, but inevitably, shrink until your online existence disappears altogether. For those of us who have published online content, references to our work will linger online for years, possibly decades, buried beneath mounds of new content provided by the living, until one day those references are gone, as well.

Going without a plan, however, is not a wise decision. Keep in mind that some of the things that are most valuable to people are those they have shared on the web, such as photos and writings. Without a solid plan, what happens to your online assets will depend in large part on the type of asset and where it is stored. In any case, once you are gone it is too late to plan for those assets.

So, what do you want to happen to your online identity and associated data when you pass on? This is the basic question we should all be asking ourselves, and now is the time to plan.

This article is one of a series of articles from DaileyMuse.com on the subject of digital footprints and online identity management. Each article in the series focuses on a different aspect of our interactions in the global Internet community.

Written by Mike Dailey, IT Architect and Sr. Network Engineer

The judge is treating these two cases as basically a single case. When it came time for arguments, the cases were called together and both Yahoo and Microsoft's lawyers were at the defendant's table.

Oral arguments centered on the question of CDA immunity and to a lesser extent if there is an objective industry standard for blocking and dealing with blocks. Nothing at all was mentioned about the wiretapping arguments.

The judge opened the hearing with a quick summary of the case so far and what he wanted to hear from the lawyers.

Judge Fogel pointed out that current case law suggests that the CDA provides a robust immunity to ISPs to block mail. The plaintiff can't just say that the blocks were done in bad faith, there has to be actual evidence to show bad faith. The law does permit subjective decisions by the ISPs. Also, that it is currently hard to see any proof of bad faith by the defendants.

The judge asked the plaintiff's attorney for his "absolute best argument" as to the bad faith exhibited by the defendants.

The plaintiff responded that they are a competitor who is being stonewalled by the defendants. That their email is not spam (as it is CAN SPAM compliant) and it is wanted email. The defendants are not following the "objective industry standard" as defined by MAAWG.

The judge responded clarifying that the plaintiff really claimed he didn't need to present any evidence. "Yes." Judge Fogel mentioned the Towmbly standard which says that a plaintiff must have enough facts to make their allegations plausible, not just possible.

Yahoo!'s lawyer pointed out that both case law and the statutes require a robust showing to invalidate claims under the CDA. And that the purpose of the CDA is to protect ISPs from second guessing. She started to bring up the absolute numbers of emails, but was interrupted and told the numbers weren't relevant. My notes don't say if that was the judge or Holomaxx's lawyer that interrupted, and the numbers discussion did come up again.

Yahoo continued that the CAN SPAM compliance is not a litmus test for what is spam. The decision for what is and is not spam is left to the subjective judgement of the ISP. She also pointed out that the numbers are important. She defined the amount of spam as a tax on the network and a tax on users.

She also addressed the anti-competitive claim. Even if Holomaxx is right, and neither defendant was conceding the point, and it is doubtful that the anti-competitive point can be proven, competition alone cannot establish bad faith. What evidence is there that either defendant exhibited bad faith? In Yahoo's case there is zero advertiser overlap and in the Microsoft case Holomaxx showed one shared customer.

She then pointed out that the MAAWG document was a stitched collection of experiences from desks. That the document itself says it is not a set of best practices. She also pointed out that there was nothing in the document about how to make spam blocking decisions. That it was solely a recommendation on how to handle people who complain.

According to Yahoo!'s lawyer the plaintiffs brought this suit because they disagreed with the ISPs' standards for blocking and they were upset about how they were treated. That the worst Holomaxx can say is the MS and Y! had bad customer service.

At this point there was some discussion between the judge and lawyers about how they were currently in a "grey area" between Rule 9(b) and Rule 12(b)6. I am not totally sure what this was about (one of my lawyer readers can help me out?) but there was also mention of using these rules in the context of the ISPs' robust immunity under the CDA.

Finally, the judge asked Microsoft's lawyer if he had anything more to add. He reiterated that the MAAWG document was not a standard, it was a collection of options. He also brought up the volume issue again, asserting that even if it is a true standard that the volume of unwanted mail sent by Holomaxx does not mean ISPs need to follow it.

Judge Fogle asked him if he meant there was no legal obligation for the ISPs to be warm and fuzzy.

The judge and defendant lawyers talked around a few general ideas about the MAAWG document. First that there was no obligation to tell senders enough information so that senders could reverse engineer spam filters. Microsoft also brought up the volume issue again, saying that the volume of unwanted 3rd party mail that the plaintiff was sending was, in itself, proof that the mail was bad.

Holomaxx interrupted claiming that the volume is a red herring. Judge Fogel countered with "but the gross number of unwanted emails is a huge number of emails." Holomaxx's lawyer argued that both Yahoo and Microsoft had large, robust networks, and the volume is irrelevant. I thought this was funny, given how often both of them have outages due to volume. However, the Holomaxx lawyer did have a point. Facebook sends billions of emails a day and both Yahoo and Hotmail can cope with that volume of mail and that volume dwarfs what Holomaxx sends.

The judge asked if he should look at the percentage of complaints about the mail rather than the gross number. Holomaxx replied that both were just a drop in the bucket and neither number was relevant.

Holomaxx then claimed again that MAAWG was a standard. The judge pointed out it was a standard for customer service, not a standard for blocking. Holomaxx disagreed and said that the MAAWG document was a standard for both how to block and how to deal with blocks afterwards.

The judge asked Holomaxx if there was any actual evidence of their claims. He talked about a case he heard a few years ago. Some company was suing Google because their search results were not on the front page of Google results. That company didn't prevail because they never offered any actual evidence that Google was deliberately singling them out. He asked Holomaxx how they were being singled out.

Holomaxx replied there was no industry standard to measure against.

The judge wrapped up the hearing by pointing out that he was being asked to show where the exceptions to the CDA were and that he had to consider the implications of his ruling. He agreed that bad faith was clearly an exception to CDA protection, but what was the burden of proof required to identify actual bad faith. He seemed to think this was the most important point and one that would take some deliberation.

Overall, the hearing took about 15 minutes, which seemed in line with the case immediately before this one.

My impression was that the judge was looking for Holomaxx to argue something, anything with facts rather than assertion. But, I am scientist enough to see that may be my own biases at work. But the judge gave Holomaxx the opportunity to show their absolute best evidence, and Holomaxx provided exactly zero, instead falling back to it's true because we said it's true.

The judge will issue a written ruling, I'll keep an eye out for it and post it when it's out.

Written by Laura Atkins, Founding partner of anti-spam consultancy & software firm Word to the Wise

Canada's Anti-Spam Law

To begin with, as a precursor to Canada's Anti-spam Law coming into effect later this year, the Office of the Privacy Commissioner, the Canadian Radio-television Telecommunications Commission, and Industry Canada have all issued regulations, the latter two in draft form with an RFC.

The regulations define express and implied consent, how unsubscribes should work, what disclosure information should be presented to subscribers, and the manner in which it is displayed. The regulations are, in essence, where numerous T's are being crossed, and i's being dotted, and are well worth a glance.

My organization, CAUCE, as well as numerous others will doubtlessly be submitting responses to the RFCs, if you have a dog in the email fight, by all means feel free to comment as an individual, or as a representative of your employer, as appropriate.

CAUCE has written, briefly, about the CRTC and Industry Canada regulations, and will be issuing our full platform, shortly.

Usage-Based Billing

UBB, or usage-based billing is the hot topic of discussion at the CRTC these days, with, well, more than the traditional two sides to the issue.

Basically, the issue is about how big network service providers sell connectivity to smaller ISPs dotting the countryside, most predominately (but not limited to) in rural areas in Canada. Some mega-providers want to place bandwidth limits on their wholesale prices charged to SME ISPs, which would mean an inevitable rise in prices for Internet end-users who use any small or medium-sized provider. The CRTC (Canada's telecoms regulator) was ready to approve UBB, until a consumers' group, OpenMedia.ca began to make a lot of noise, and the previous Minister of Industry warned the CRTC that were they to approve any UBB scheme, the government would nip it in the bud.

This issue has had more twists and turns than a plateful of spaghetti, and I am simplifying to the point of disservice, I suggest you take a dive into Michael Geist's blog where he has kept a running commentary on UBB, which actually began becoming a topic of interest almost a year ago.

Over-the-Top Services

Even casual observers can also see how UBB might have effect upon Apple TV, YouTube, and Netflix, and sure enough, the CRTC is also holding hearings on what they call 'over the top' (OTT) services. The CRTC are, as crazy as it sounds, considering regulating these services here in Canada.

The CRTC are also holding hearings, again, on UBB. Read all about them here.

Lawful Access

You didn't think we were finished did you? Well, we're not! Lawful Access, a passel of bills that have been lurking since 2005 are once again threatening to show up on the order papers for the fall legislative session. They are, as some have put it, a solution in search of a problem.

In the most simple of terms, lawful access allows any police officer in Canada to show up at an ISP, assert a reasonable suspicion about a given account, and the ISP is required under these laws to turn over everything about a given subscriber, no questions asked, no court order necessary. The ISPs were, at one point, against these proposed laws, but only because it would cost them something to actually do the investigative work. Since then, there have been clauses inserted to ensure the police forces pay for each such 'request' they make, and opposition from the ISPs has all but vanished.

This post on the CAUCE website explains Lawful Access in detail.

I'm sure there are people in other parts of the world who are shaking their heads in disbelief at all of this; Canada wants to drive small ISPs out of business, regulate YouTube, and have cops walk into ISPs without court oversight and grab user data. When did Saudi Arabia become the upstairs tenants to America?!? Did the Bush neo-cons find a new gig up north? And, given how short their summer is, why are Canadians wasting all this time in meeting rooms?

These latter questions are rhetorical, and I'd best leave them unanswered.

Written by Neil Schwartzman, Executive Director, CAUCE North America

This new FBL service is a great way for senders to minimize complaints and complaint rates — as well as improve the quality and reputation of sending reputation across outbound mail streams' traffic.

On this website, there's a registration page available to senders and parties with outbound traffic who wish to register for the complaint feedback loop. This would facilitate an approval of an application prior to receiving feedback. Upon approval, complaint reports are forwarded to approved, registered senders. FBLs will come from IPs 66.45.29.185 and 67.217.228.241, and confirmation and FBL messages will come from feedbackloop@fbl.synacor.com. There's also a "Frequently Asked Questions" page at http://fbl.synacor.com/faq.php. The new service is at http://fbl.synacor.com/.

Written by Udeme Ukutt, Postmaster

The revisions to RFC 5335 and 5336 currently nearing completion in the IETF's EAI working group remove most of the complexity from the existing design, and simply define a new international mail stream with UTF-8 text in mail headers, and UTF-8 addresses in the SMTP session. (MIME and the 8BITMIME ESMTP option already handle UTF-8 message bodies.) A mail server announces that it can handle internationalized mail by announcing an ESMTP option, which currently has the ugly placeholder name UTF8SMTPbis, but will presumably be changed to something snappier by the time the revised RFC is issued. I'll call it EAI here.

A mail client, if it sees that a server announces EAI capability, can put the EAI flag on the MAIL FROM command in the SMTP session, to tell the server that this message is an internationalized one, and then sends the message. Any mail server that supports EAI also supports 8BITMIME, so the message can contain any UTF-8 text without special coding. The RFC also defines EAI options for the SMTP commands EXPN and VRFY, which accept and return e-mail addresses, and some new extended return codes for status messages. If a client doesn't use the EAI option, it sends legacy 2821/2822 mail, same as always. The option is set or not for each message, so each message moving through the mail system is an EAI message or a legacy message.

The RFC for internationalized mail bodies allows UTF-8 nearly anywhere that ASCII can occur, other than in a few places intended to be parsed by computers, such as Message IDs and time zones in date stamps. It defines a new MIME body type, message/global, for attached or included internationalized mail messages. And that's about it. All of the down-conversion stuff to turn EAI messages into RFC 2821/2822 compatible mail is gone.

As the diagram above illustrates, this defines a new EAI (or whatever we call it) mail stream that is parallel to the existing legacy SMTP stream. If a message has UTF-8 headers, or a UTF-8 envelope address, it has to go in the EAI stream. If it doesn't it can go in either the legacy stream or the EAI stream.

The solid diagonal arrow shows that a legacy message can always move into the EAI stream, since the spec for the latter is a superset of the spec for the former. The dotted arrow shows that an EAI message can sometimes go into the legacy stream, if an MTA looks through the message and notices that it has an all ASCII body and an all ASCII envelope, something I've nicknamed Deep Message Inspection. (It's not required to do this, just allowed.)

If a client wants to send an EAI message to a server that doesn't handle EAI, too bad, there's no standardized way to downgrade.

This doesn't mean that mail systems are forbidden to downgrade messages, just that the IETF isn't trying to define a standard way to do so. It's easy to imagine useful special cases. For example, if an MSA (the program that accepts mail from user mail programs) is configured with backup legacy addresses for its EAI users, and it noticed EAI mail from one of its users to a legacy address, it could rewrite the message's headers to replace the user's EAI address with her legacy address and MIME encode the UTF-8 header text, turning the message headers into ASCII, and send it along as a legacy message. That sort of thing may turn out to be fairly popular, but at this point, it's not well enough understood to standardize.

There are mail communities where all the users read and write languages written in non-ASCII scripts, so it may turn out that everyone's mail supports EAI, and legacy compatibility doesn't matter. Or they may treat legacy mail as a special case, perhaps by using a different user mail program.

The EAI work has defined the core of a fully internationalized mail system, allowing users to send mail using their preferred language, encoded as UTF-8, in essentially all parts of e-mail messages. The EAI spec is conceptually straightforward, and the changes required for adequate if not superb support in MTAs are fairly simple. (Deep Message Inspection is harder, but it's optional.) The details of migrating from legacy mail to EAI mail are a work in progress, as are the details of how EAI users will send mail to legacy mail users, but the imminent completion of the EAI work is a big forward step for mail in all the world's languages.

Written by John Levine, Author, Consultant & Speaker