News, technical help and self-indulgent geek speak

Viral Marketing and the Australian eMarketing Code of Practice

Last modified: Nov 4th 2008, 08:06 | | | Comments(0)
Please note that this post should not be construed as legal advice.
I am by no stretch of the imagination qualified to give that.
Your situation may differ from those described below in important ways.

When it comes to ensuring that commercial email practises abide by Australian anti-spam laws, the Australian eMarketing Code of Practice (see here) forms an invaluable checklist.

A particularly hairy area is the subject of “Viral Marketing and Member-Get-Member schemes”. In our area, this covers any commercial website which offers a facility for users to send an electronic communication (usually an email) to friends, associates or family members. Users may wish to do this in order to share a novel or interesting campaign with people they know, or less frequently there may be some direct motivation such as a prize for referring the largest number of new members. When the content of the communication is commercial in nature, anti-spam laws still need to be adhered to.

It seems that in a legal sense under these circumstances the individual considered to have authorised the message needs to be the user initiating the action. The organization running the campaign do not, in general, have advance permission (either explicit or implied) from the recipient to send commercial content to them.

Relevant sections of the code place some responsibilities on the Message Originator or Message Service Provider (that is, those running the campaign):

  6.2.1 ensure that it is made clear to the end Recipient on receipt of 
  the forwarded Commercial Communication, that the communication has been 
  authorised and sent by the initial Recipient who is clearly identified 
  within the communication;

6.2.2 ensure that the end Recipient can easily reply to the initial Recipient who forwarded the message to them; 6.2.3 not collect any data or contact details relating to the end Recipient until such times as the end Recipient personally provides such information to the Message Originator, Message Authoriser or Message Service Provider; 6.2.4 ensure the initial Recipient is made aware of the content of any Commercial Communication generated by the Forwarding Facility that will be included in the message sent to the end Recipient; and 6.2.5 ensure that the forwarded Commercial Communication includes information explaining how the end Recipient can Unsubscribe from receiving further Commercial Communications from the initial Recipient. 6.3 Where an end Recipient’s contact details are provided to the Message Originator or Message Service Provider by a third party, such as a customer, the referred details will be considered a Third Party Contact for the purposes of the Code and the Message Originator or Message Service Provider must comply with clause 4 above.

Note that neither the code of practice, nor the 2003 Spam Act, seem to go into any level of technical detail about what is and is not acceptable. This seems to be because the intent of the Act is to cover a wide range of electronic messaging systems which can carry commercial content. To do so would limit the scope of the Act to systems currently in place, and render it useless as old systems change and new systems develop.

In the past at Nextstudio we have covered section 6.2.2 in particular by (i) requiring users to supply a syntactically valid email address, and (ii) setting an appropriate Reply-To header on any outgoing e-mail, using that supplied address. This allows recipients to easily contact the sender (by means of the “reply” option in any standard MUA), and also partly services to identify the sender to the recipient, contributing towards sections 6.2.1 and 6.2.5.

Recently we have run into troubles though. Legal advice received by a Client Who Shall Remain Nameless seemed to indicate that commercial email, triggered by a third-party user, but with a From header within the website’s domain, may be in breach of the Act. Now to my mind this is ridiculous. Sending email on behalf of an identified person is one thing, but actually masquerading as that person strikes me as a heinously fraudulent act of forgery. Despite this, taking a look around it really is not uncommon. Armed with an email address on an SPF protected domain I have personally tried out the “viral marketing” component on no less than a dozen currently promotions running Australia-wide, and in better than 80% of those I have received bounce messages from the recipient warning that the sending agent is not permitted to send email from that domain. For those not familiar with it, the good folks over at OpenSPF explain the SPF system better than I possibly could. In short though it is a system designed to avoid exactly what these promotions are doing – pretending to be someone they are not when sending email. My personal conviction is that (i) lawyers do not understand nuances regarding email headers in the same way that I do not understand nuances regarding the law, (ii) the approach taken in the past is perfectly ethical, and satisfies the intent of the law insofar as I understand its intent, as a layman.

In any case, after a bit of head-scratching, a lot of Google (actually, the final result is the same approach that Google’s GMail uses), and some light revision of the mechanics of SMTP transactions, it turns out that there’s a solution which should both keep the lawyers happy and be ethical. The answer comes in the form of RFC822: Standard for ARPA Internet Text Messages, in section 4.4.2, which talks about the Sender header.

 This field contains the authenticated identity  of  the  AGENT
 (person,  system  or  process)  that sends the message.  It is
 intended for use when the sender is not the author of the mes-
 sage,  or  to  indicate  who among a group of authors actually
 sent the message.  If the contents of the "Sender" field would
 be  completely  redundant  with  the  "From"  field,  then the
 "Sender" field need not be present and its use is  discouraged
 (though  still legal).  In particular, the "Sender" field MUST
 be present if it is NOT the same as the "From" Field.

If our valiant customer, sender@example.com is determined to let their friend recipient@example.com know about our great promotion, and we own the address _promotion_forwarding@example.com_ then the following should be acceptable:

  • a To header of recipient@example.com
  • an envelope-sender of _promotion_forwarding@example.com_
  • a Sender header of _promotion_forwarding@example.com_
  • a From header of sender@example.com

As an added bonus, apparently MS Outlook will display the sender as “promotion_forwarding@example.com on behalf of sender@example.com“, clearly identifying the relationship. Other mail agents may or may not show the Sender header. Our receiving mailserver though will perform its SPF and other checks against _promotion_forwarding@example.com_, meaning that the mail will actually be received by its intended recipients. If the recipient replies to the email, it will go back to the sender. The mail’s Return-path will be _promotion_forwarding@example.com_, so bounces and other delivery issues will come back to the promoter. The end result is practically indifferentiable from our original solution, but the lawyers get to see somebody else’s address in their From header.

Add a comment

New commenters only

New commenters only

If you've left a comment with us before, just skip down to the "All commenters" section below.

All commenters

All commenters

We hate spam! We won't display your email address (even mangled) on the site, nor will we show it to any third party. We will send a verification email the first time you submit a comment, and any other time someone tries to submit a comment using your email address without providing your password. If we send you anything else, it will be personally written and solely in response to your comment.

Leave the password blank if this is your first time posting or you do not have easy access to your password. If the password is blank you will receive an email containing both your password and a confirmation link.

If this is your first time posting, be sure to fill our your name and (optional) website address above.

To prevent automated (spam) comments, we require that you copy the letters and/or numbers from the image above into this input box.