Not that you asked...  
   

March 9, 2006

Implementing Email Authentication: A Primer

One of the most basic elements of our work at Return Path is ensuring that clients use best practices in their email delivery processes. A common recommendation we give is to implement email authentication. Email authentication has two primary benefits: It stymies forgery of email messages and allows senders to build a positive reputation with receivers based upon their mailing behavior. Yet many companies, particularly small ones, have never heard of email authentication -- and those who have heard of it have not yet initiated a project to implement it.

How does email authentication work? The most common schemes today -- SPF, SenderID, and DomainKeys -- use the Domain Name System (DNS) to publish “records.” Each record, which is available to the entire Internet community, details the specific machines that are authorized to send mail for a specific email domain.

Before a message arrives in a user’s email inbox, the receiving email server can attempt to verify that the mail is coming from an authorized source by checking email authentication records. Suppose a spammer forges your domain in his spam message. Unless he has hacked your network (a different, and bigger, problem) he is transmitting messages from IP addresses different from yours. When he sends his forged message, a receiver who checks for email authentication records will query for your domain’s records in DNS to determine your authorized mail sending hosts. Since your records won’t include the spammer’s IPs, the receiver can now take greater precautions in handling the message: rejecting it outright, subjecting it to spam-filtering technologies, or directing it straight to a junk folder.

In brief, here’s how to implement email authentication:

Step 1. Find the authentication scheme best suited to your needs. You can find detailed information about the three dominant schemes on the following Web sites:

SPF: www.openspf.org/wizard.html
SenderID: www.microsoft.com/senderid
DomainKeys: http://antispam.yahoo.com/domainkeys

It is also a good idea to coordinate with your IT group early in
this process. They are likely to be familiar with the specifications
and can help in planning the process and publishing your records once
you’ve built them.

Step 2. Take inventory of systems that send your mail.
Identify all machines that send mail on your behalf, which includes all internal and external systems -- from corporate mail servers to third parties authorized to send mail on behalf of your company. Once you identify these senders, you need to obtain the IP addresses and host names for each. Be sure to consider the following potential sources:

  • Advertising/PR agencies
  • Bulk mailings
  • Corporate email
  • Customer support and services
  • Events marketing
  • Forwarding services
  • Human resources
  • Investor relations
  • Newsletters
  • Order and shipping confirmations

Step 3. Create your authentication records. There are excellent online tools available for creating valid SPF and Sender ID records. The following wizards can assist you:

SPF: www.openspf.org/wizard.html
Sender ID: http://www.microsoft.com/senderid

DomainKeys differs slightly in that it requires you to create a
public and private encryption key pair for your record. The public key is then published in your DomainKeys record in DNS. Details can be found at http://antispam.yahoo.com/domainkeys.

Step 4. Publish your authentication records. Work with
whoever manages your DNS records to publish the email authentication
records you’ve collected. The actual publishing is easy -– finding the responsible party who controls your DNS is often the tricky part.

Step 5. Test your authentication records. SPF, SenderID, and
DomainKeys all provide options to publish your records in “test” mode. This provides the opportunity for testing without risking delivery failures for mistakes in your record. Testing will ensure that the mail servers you’ve authorized are being verified by receivers and will determine if you’ve missed identifying any mail servers in your inventory.

Some testing options:

Once the records are published and tested, appoint a staff person to make sure they remain current.

Since your circumstances and sender inventories will vary, some complexities may emerge in your planning and implementation. The benefits of strengthening your company’s reputation for transparency and accountability, however, will be worth the effort.

Posted by gcrgcr at 10:33 PM | Comments (0)

December 21, 2005

CAN-SPAM Act in Time for the Holidays

Just in time for the Holidays comes the FTC's "Effectiveness and enforcement of the CAN-SPAM Act" report to Congress.

Believe it or not it has been two full years since Can Spam was enacted. Part of the law was a requirement that the FTC issue a report on Can Spam's effect on the spam problem after two years. That time has come.

I' ve been through the report, and without doing a detailed review here, I'll just say that it is mostly what I expected. The FTC points out that in general spam volumes are less now than they were two years ago. They demonstrate the Act's use as an enforcement instrument by pointing to 50 or so legal actions brought under the Act in the past two years. Other than that, a lot of information about the spam problem today and how it continues to be fought.

As for next steps, the FTC basically recommends three thing to further improve the effectiveness of CAN-SPAM:

  1. Continued development and use of private-sector technology to combat spam
  2. Support for authentication and other efforts that make it difficult for real spammers to conceal their identity
  3. Support the US Safe Web Act of 2005 bill to enable the FTC in fighting spam from outside the US.
Overall, it is not a bad read - you can get to the full FTC report here: http://www.ftc.gov/reports/canspam05/051220canspamrpt.pdf

Enjoy!

Posted by gcrgcr at 1:14 PM | Comments (0)

November 7, 2005

Concerns with Utah and Michigan Registries

Like many in the email marketing world, I've been keeping tabs on the Child Protection Registry initiatives in Michigan and Utah. It has been difficult to watch an effort which was based in good intentions get implemented in such a painfully bad way. I had my suspicions that these state laws wouldn’t go well and they really haven't.

To summarize the situation, over a year ago Michigan and Utah quietly passed Child Protection Registry statutes. The laws in both states are very similar. Each intend to prohibit particular types of offensive content that can be sent to registered contact points such as email and IM addresses.

Both laws list particular categories of material that are prohibited, things like gambling, tobacco, alcohol and pornography. Again, no one wants to send inappropriate material to anyone who doesn't want it, but particularly not to minors. However, the problems in the implementation are widespread and include:

  • The language of each law beyond the specific category listings of prohibited materials includes broad and general descriptions for anything else that can be deemed harmful for minors to possess or view.
  • It costs money to check the registry. And a lot of money at that. Marketers must pay half a cent for each address they check against the Utah registry and seven tenths of a cent in Michigan. This fee is not for each address matched but for each message checked!
  • There is a private right of action, which means that any Utah or Michigan citizen can file suit against a sender, even if the information received was specifically requested.

Since the laws were drafted under the guise of child protection they were easily passed in both states. The email marketing industry initially took little notice or action. There was a broad presumption by most in the industry that these laws were pre-empted by the federal Can Spam Act of 2003. However, in August of this year, both laws took effect and the collective uproar began.

Many organizations have been lobbying since August against the registries operating. The Email Service Provider Coalition (ESPC) has been very active in both Utah and Michigan. Other trade organizations and freedom protection organizations have been commenting, lobbying, and even planning law suits.

There are numerous points of contention being relayed to the lawmakers in both states. Most deal with security and technology basics – rather than picking on the constitutionality or legitimacy of the law – though there are valid questions there as well. Often mentioned is the point that real spammers who are most prone to send offensive material are the least likely to comply.

Now, unexpected and probably unintended support comes by way of an FTC report which has surfaced. The report is an earlier response to a similar bill proposed in the state of Illinois last year. The 16-page letter emerged this week - and details item by item what a flawed idea the FTC thinks the registries are.

There are a number of sites reporting this latest development, you can read more here:

http://www.clickz.com/news/article.php/3561261
http://www.freep.com/money/business/childads25e_20051025.htm
http://www.marketingvox.com/archives/2005/11/04/ftc_state_email_registries_put_kids_at_risk/
http://www.chicagobusiness.com/cgi-bin/news.pl?id=18394

The ESPC has continued to work aggressively to raise concerns associated with the Utah and Michigan registries. The Michigan law has been postponed since August due to a typo. There are rumors coming out of Michigan that Governor Jennifer Granholm may sign the corrected legislation as early as this week, which would put the Michigan law back into effect.

It seems likely that protecting children from spam and offensive materials can be managed and achieved in other ways – without levying such a tax on email senders.

So, the saga continues to unfold, and like a bad car wreck, I can’t help but continue to watch to see just how ugly it may get.

Posted by gcrgcr at 2:20 PM | Comments (0)

March 24, 2005

My Son the Spam Copywriter...

I've got three kids - two boys and a girl. Ages 7, 5, and 3. My two boys share a bedroom, and last night while getting them into bed I noticed this sign on their door. I'm not sure when it was made and how long it was there, but it took me a minute to "translate" it.

Ceep UTO, no Gerl's. Only Boy's.

Once I read it, twice... Aha! Cute! Classic message for a bedroom door of two boys.

It reminds me of spammers attempts to only slightly obfuscate text of their messages in such a way as to avert textual spam filtering heuristics, but still be translated by a human upon reading it.

If you think about it, our minds translate simple typeos easly and quikly - sort ov on the flie. See whut I meen?

Anyway, AJ either has a career ahead of him writing copy for spammers, or he's slightly dyslexic and may have to hang back in 1st grade for a second time... :)

Posted by gcrgcr at 3:18 PM | Comments (0)

January 28, 2005

Spam, Spim, Cram and Spit...

First there was Spam - ever pervading the lives of those who use email at any level.

Then, Spim was born - IM spam - which I've not really been affected by recently. In the old days when I used ICQ - an early internet chat platform - I used to get lots of unsolicited IM's - it was brutal, frequent, and annoying.

Bloggers have also found that their blog software has been targetted by spammers. Spammers misuse the "comment on this entry" feature to paste in spam messages. People tend to refer to this as "comment spam" - I'll call it "cram" for now. Cram has gotten bad enough that blog software companies have had to offer tips on how to reduce cram - as well as repair software flaws for vulnerabilities that allowed spammers to also email spam through the comment engine.

So not only am I an email user, an IM user, and a blogger - who is therefore dealing with Spam, Spim, and Cram every day, along comes Spit. Read Aunty Spam's account of Spit.

What is Spit? Simply put it is VOIP (Voice Over IP) Spam.

For broadband telephone service customers - of which I recently became one through Lingo - this is an exploit that occurs when you are speaking with someone.

The "Spitter" basically hacks into the call, in a way that the caller can't hear but the receiver can, and plays Audio spam to the person you called.

It may be the most annoying type of spam and I hope it does not become prolific. Services like Vonnage and Lingo should be doing all they can now to eliminate or mitigate this vulnerability.

As of yet, I haven't been "Spit" on - and I hope it doesn't happen. This will be an interesting one to keep an eye on.

More on Spit via Google if you are interested.

Posted by gcrgcr at 9:57 AM | Comments (0) | TrackBack

January 24, 2005

MovableType Comment Flaw Exploited

Spammers discovered an exploit in MovableType's (blogging software - which is used on this blog)
comment feature yesterday and started hitting all servers with MT
installed hard, causing large slowdowns in http requests and mysql
processing (if the MT install used MySql).

The exploit is similar to the old FormMail exploit in that it allows
the spammer to cc/bcc others thru the comment script to send out spam
thru the server hosting the blog. MovableType has issued an updated
release (v3.15) that closes the security hole along with a patch
that's tested for backwards compatibility back to v2.661 (and it may
also work with v2 versions before that but they haven't tested that).

Anyone currently running MT or hosting someone using MT should disable
the mt-comments.cgi file and/or upgrade to v3.15 or install the patch
and then the mt-comments.cgi file can be enabled again.

The updated version and the patch are available here:
http://www.movabletype.org/news/2005/01/movable_type_315_release.shtml

I had been battling comment spam for some time, and took some measures against it. I renamed my version of the comments script - but that only reduced the amount of abuse. Then, I disallowed comments from unregistered users. Spammers hate having to register - and they lie about it anyway.

I'll probably download this patch later tonight and run it - will post as to the results - level of effort and difficulty etc...

Posted by gcrgcr at 10:22 PM | Comments (2) | TrackBack

December 23, 2004

Gmail redux? Not likely...

This blog post by Matt Blumberg caught my attention - regarding AOL's announcement of a free webmail offering.

I find the AOL news to be a "who cares?" as well - so far as their announcement details - which is not much other than intent to enter the free webmail space.

THe last high-profile entrant, Google, really seemed to change the webmail paradigm with their unique offering of 1 GB of storage space. Notice how the market was forced to respond competitively. Microsoft was forced to up the storage limit on free Hotmail accounts from 2 MB to 250 MB. They'll probably have to go higher.

At least Google's web mail entry stirred the market place and brought innovation. Open source programmers are using Gmail as a backend for file storage, photo galleries, and even blogs!

Gmail takes advantage of the same "all you can eat buffet" gamble. The average person eats only so much food. It is practically impossible to fill 1 GB full of text email.

One company has even offered to give the first user who is able to fill up his inbox with legal content and without spam a dedicated server with a Petabyte (PByte) of space. That will be one to watch!

Google also added innovation to the webmail wars in other ways as well. They introduced a unique user interface to email, sorting mail by conservations and threads (though Outlook now does this also). They group things in sense of time and space - new, old, older, oldest - small, big, bigger, biggest. Their intent on filtering mail and serving up relevant ads stirred up privacy controversy everywhere, but generated significant buzz. Finally, their viral method for introducing into the market place - uber geek bloggers bestowed with first generation Gmail accounts and earning invitations to others. A user base that feels blessed, cool and chosen. Lot's of lessons here already, and a tough act that AOL is choosing to follow.

Posted by gcrgcr at 10:27 PM | Comments (0) | TrackBack

 

 

 

  
  footer image