Subject: [Asrg] Charging for e-mail

From: Craig Cockburn <[email-masked]>
Date: Mon, 6 Feb 2006 19:46:04 +0000

The thin end of the wedge?
http://news.bbc.co.uk/1/hi/technology/4684942.stm

-- 
Craig Cockburn ("coburn"). http://www.SiliconGlen.com/
Please sign the Spam Petition: http://www.siliconglen.com/spampetition/
Home to the first online guide to Scotland, founded 1994.
Scottish FAQ, weddings, website design, stop spam and more!

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 07 Feb 2006 01:37:29 +0100

> http://news.bbc.co.uk/1/hi/technology/4684942.stm

A techology overview is apparently here:
http://www.goodmailsystems.com/certifiedmail/

2+3 is apparently some kind of outsourced "hashcash"
  5 is wishful thinking (aka "receiver policy")
  9 is some kind of webbug / DSN / privacy nightmare

You catch it near 5 by rejecting all wannabe-goodmail.

                    Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 07 Feb 2006 21:54:48 +0100

> 2+3 is apparently some kind of outsourced "hashcash"

I've got two replies saying that it's a bit like DKIM.

Thinking about this for some time:  Apparently receivers
"see" what's a "good mail" without asking third parties,
for DKIM that would be DNS, here it could be "good mail".

If they don't ask third parties it must be something
they can check for themselves.  A header field, and it
is probably better than "X-TrustMe".  A simple kind of
cookie would be good enough for the webbug-function and
the bulkmail-fee (goodmail can identify valid cookies),
but it's not enough to catch forged cookies.  Something
like "hashcash" (spiced with security by obscurity) is
possible, and that would be rather different from DKIM.

If step (5) "the receiver checks for a valid token" is
really independent of any third party.  Hard to guess,
but Yahoo! wouldn't buy snake oil, or would they ?  Bye

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 07 Feb 2006 21:54:48 +0100

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 07 Feb 2006 21:54:48 +0100

---

From: Bart Schaefer <[email-masked]>
Date: Wed, 08 Feb 2006 02:08:41 +0000

On Feb 7,  9:54pm, Frank Ellermann wrote:
}
} I've got two replies saying that it's a bit like DKIM.

Yes.  Like DKIM, except that when the sender computes his
cryptographic hash of the message, he must "phone home" to
the Goodmail server to obtain a validating token.

} Thinking about this for some time:  Apparently receivers
} "see" what's a "good mail" without asking third parties,

AIUI, the receiver just has to compare the message content
to the crypto in the header.  Proprietary software supplied
by Goodmail is necessary at both sender and receiver sites,
so you must own a brand-name MTA that has partnered with
Goodmail.

---

From: Bart Schaefer <[email-masked]>
Date: Wed, 08 Feb 2006 17:41:39 +0000

On Feb 8, 12:33pm, Jeff Macdonald wrote:
} Subject: Re: [Asrg] Re: Charging for e-mail
}
} On Wed, Feb 08, 2006 at 02:08:41AM +0000, Bart Schaefer wrote:
} > so you must own a brand-name MTA that has partnered with
} > Goodmail.
} 
} One can buy a SDK. It doesn't have to be part of a MTA.

According to the info I got from Goodmail yesterday, they are not
yet making the SDK available, and haven't decided when they will.
You have to use an MTA that already has it integrated.

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 09 Feb 2006 02:08:00 +0000

On Feb 8,  1:52pm, Jeff Macdonald wrote:
}
} > According to the info I got from Goodmail yesterday, they are not
} > yet making the SDK available, and haven't decided when they will.
} 
} That doesn't jive from what I've heard from a Goodmail representive (a VP of
} Engineering I believe) last week.

Here's the quote, from email from a Goodmail SVP who shall for now remain
anonymous:

> Date: February 7, 2006 7:01:31 AM PST

> Goodmail Systems is working with a range of technology partners to help
> senders that operate a bulk email marketing infrastructure.
> 
> *	Purchase a Goodmail-approved Imprinter Appliance from technology
> partners Port25 and Strongmail. This quick and easy implementation is a
> straightforward solution that will get you up and running quickly.
> 
> *	Upgrade existing MTA software to include Goodmail Imprinter
> capabilities from any of Goodmail's technology affiliates.
> 
> At this point, we are not offering the SDK broadly to senders to integrate
> into proprietary MTAs.

Perhaps e-dialog qualifies as a "technology affiliate"?

---

From: Craig Cockburn <[email-masked]>
Date: Fri, 10 Feb 2006 08:54:13 +0000

In message <[email-masked]>, Bart Schaefer 
<[email-masked]> writes
>so you must own a brand-name MTA that has partnered with

Here's an alternative perspective on the problem
http://www.vanquish.com//news/letter_0206.shtml

more detail:
http://www.vanquish.com/sb1/goodmail_indepth.htm

---

From: Dave Crocker <[email-masked]>
Date: Sun, 12 Feb 2006 16:36:56 -0800

> http://www.vanquish.com/sb1/goodmail_indepth.htm

The problem with these sorts of articles is that they are not "perspectives". 
They are rants.  Frankly, I am rather tired of them.

They ignore current facts and they ignore trade-offs in trying to deal with a 
serious problem.  So, instead, they focus on creating a sense of fear and even 
hysteria.

It's not that a mechanism like certified mail cannot be abused.  Rather, it is 
that there is a legitimate spectrum of uses for vetting mechanisms -- as there 
is for any interesting technique -- and articles like these distract us from 
serious consideration of them.

At the moment, certified mail has been declared to be intended for the sending 
of transactional mail, not marketing mail.  That is, mail that both the 
originator and the recipient engage in prior consent and consider to be 
business-critical, for getting delivered.

Forgive me, but I happen to think that a mechanism that will improve 
deliverability of transactional mail is a sufficiently Excellent Thing so as to 
be entirely uncontroversial.

(I have an entirely different line of comments about using a proprietary 
mechanism and only one vetting agency -- nevermind the use of per-message 
charting -- but for that, we would have to get into *my* rant.)

So if folks want to have a serious discussion about the balancing act involving 
policies and controls amongst originators, recipients and intermediaries, fine.

But let's simply ignore efforts that are clearly intended merely to inflame.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: [email-masked] (Justin Mason)
Date: Mon, 13 Feb 2006 11:53:30 -0800

Dave Crocker writes:
> At the moment, certified mail has been declared to be intended for the
> sending of transactional mail, not marketing mail.  That is, mail that
> both the originator and the recipient engage in prior consent and
> consider to be business-critical, for getting delivered.

Dave --

I'm not sure where you're getting this idea that CertifiedMail is for
transactional mail only.

As I noted at my comment on your CircleID posting at
http://www.circleid.com/posts/challenges_in_anti_spam_efforts/ , AOL's
statements to date regarding their plans for CertifiedMail have *NOT*
specified that this is for transactional mail only; instead, all stories
seem to indicate that they have talked about its use for "bulk mail" in
general.

Since then, AOL have issued clarifications on other aspects of the plan,
but haven't mentioned transactional-only.

Perhaps some *other* ISP is planning to use CertifiedMail only for
transactional mail, but it seems unlikely that that's what AOL is
thinking.

On the other end, http://www.goodmailsystems.com/senders/ discusses
CertifiedMail's use for "marketing impact" and "campaign returns" -- not
terms typically used for transactional messages.  So it seems clear
they intend it to be used for non-transactional marketing mail.

- --j.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Feb 2006 08:37:16 -0800

>    AOL's
> specified that this is for transactional mail only; 

> but haven't mentioned transactional-only.

in their recent statements, AOL has said that their use of CM is for 
transactional mail only. Yesterday's DKIM Authentication Summit presentation by 
them is an example.

> terms typically used for transactional messages.  

I do not recall anyone claiming that GoodMail has said that their product is 
only useful for transactional mail.

My point was that the AOL and Yahoo use of GoodMail has that constraint.

d/
-- 

Dave Crocker