Subject: [Asrg] CertifiedEmail -- Transaction messages vs. other types

From: "Daniel T. Dreymann" <[email-masked]>
Date: Thu, 16 Feb 2006 23:44:18 -0800

Seems to be some confusion about what messages are eligible to be certified
as CertifiedEmail. Let me clarify that:

Our AUP (http://www.goodmailsystems.com/aup.pdf) makes it clear that
prospecting messages are not allowed. To use CertifiedEmail you must have
permission or an established relationship with the recipient.

Goodmail receiving partners can define further restrictions for messages
addressed to their mailboxes. Yahoo!'s initial testing is indeed limited to
transactions only. See for example our press release of October 2005:
http://www.goodmailsystems.com/news/pressrelease102605.php
or statements by Yahoo! in various fora, e.g.:
http://lawprofessors.typepad.com/tech_law_prof/2006/02/the_problem_wit.html.

As long as this is the case, a non-transactional CertifiedEmail message sent
to a Yahoo! mailbox will be rejected. How do we know it's not transactional?
The cryptographic token includes a field for the message type. It is
self-asserted by the sender and it would be a violation of the AUP to have
an incorrect value. Remember that the system is identity-based and that
senders are held accountable.

NB: There are no additional restrictions beyond Goodmail's AUP when
addressing AOL mailboxes.

>From a sender's perspective, using CertifiedEmail for transactions makes a
lot of sense. Obviously as an anti-phishing tool but also as a tool to
reduce customer care costs (e.g.: a large online travel company was quoted
in the NYT saying that 20% of all online purchases end up with a phone call
because the recipient did not get his itinerary or her e-ticket
confirmation).

Again from a sender's perspective, there's a strong ROI case for marketing
messages too. An article in Primedia online listed the following parties
among CertifiedEmail winners: ISPs ("they save processing power, they make a
few million bucks in stamp sales, they have happier users"), users ("Less
hassle getting through their inbox") and "marketers with real permission who
get more than a quarter of a cent of value out of bothering you (and again,
if it's not worth a quarter of a cent to you, it's hardly worth three
seconds of my time)". Among the losers in that article: "marketers who
measure tonnage".

Hope this made it all clearer now.

Daniel T. Dreymann
Co-Founder & SVP Product, Engineering & Operations
Goodmail Systems, Inc.

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

---

From: John Levine <[email-masked]>
Date: 17 Feb 2006 22:56:04 -0000

I'm planning on having an ASRG session at the Dallas IETF in March.

Before I invent an agenda, anyone else likely to be there?  Got some
drafts you can get to me for discussion?

Topics that have come up in the recentish past:

* The DNSBL BCP (the editor of which knows who he is)

* Interfaces to reputation systems.  I still think this is important;
  we should sketch a few out from lightweight DNS up through heavier
  XML over HTTP.  (If you think those are the wrong way to do it, feel
  free to propose the right way.)

* Investigating the effects of DKIM and similar technology.  Not just
  "stopping forgery" but how will it affect the way people think about
  mail.

R's,
John

---

From: "David Nicol" <[email-masked]>
Date: Wed, 22 Feb 2006 13:51:39 -0600

> I'm planning on having an ASRG session at the Dallas IETF in March.

Dallas, you say? That's on my coast :)

> drafts you can get to me for discussion?

How would one register?

>   free to propose the right way.)

the Tagging standard could be used to define a standard way to include
reputation data in e-mail headers, and the issue of how a reputation
system provides the judgement to put into the tag can be considered an
implementation detail

>   "stopping forgery" but how will it affect the way people think about

Do we even have a solid baseline for the way people think about e-mail now?

---

From: John Levine <[email-masked]>
Date: 23 Feb 2006 03:52:01 -0000

>How would one register?

One would visit the top-secret web site at www.ietf.org and look for
the word "Dallas" on the home page.  Then one might be somewhat
dismayed when one saw how much the registration fee is these days.

>> * Interfaces to reputation systems

>reputation data in e-mail headers

Maybe I'm dense, but why would anyone care about alleged reputation
data that a sender included in his own headers?  It only makes sense
for recipients to check reputations of incoming mail.

>Do we even have a solid baseline for the way people think about e-mail now?

Interesting question.  Some of the Pew studies would be a good place
to start.

R's,
John

---

From: "David Nicol" <[email-masked]>
Date: Thu, 23 Feb 2006 14:48:35 -0600

> for recipients to check reputations of incoming mail.

The tagging paradigm is, an intermediate stop along the way adds the tags.

That is why forgery prevention is so important to the tagging discussions.

Spamassassin, a working tagging engine, throws out spamassassin tags
that are on the messages it processes.  Throwing out existing tags that
you are an authority for is one possible approach when you (as a tagging
engine) encounter your tag in the input.  Another is to mark that tag as
pre-existing.

I hope that takes care of the misunderstandings I perceive in your question:
tagging is not about unverified claims made at origination time, but is about:

(1) centralization of authoritative declarations
(2) verification of authenticity of (1)

The other possible misunderstanding is that senders aren't the only ones
who can add headers.  Headers can be and are added at any intermediate steps.

(1) can be and is done today by anything -- such as SA -- that adds some
information in an e-mail header.
(2) is tricky, and requires a consensus or at least a near-consensus on a
variety of issues, including:

     2a:   What do verifiable tags look like?

     2b:   Which authentication models and methods are supported?

     2c:   How does a tagging authority identify itself?

There is a lot of overlap between reputation and tagging; reputation could
be considered part of the tagging problem: given standard tags that may
be set upstream, the reputation of the tagging authority must be considered
when weighting the particular tag.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Feb 2006 14:58:10 -0800

On Feb 22, 2006, at 7:52 PM, John Levine wrote:
>
>> the Tagging standard could be used to define a standard way to  
>> include reputation data in e-mail headers
>
> data that a sender included in his own headers?  It only makes  
> sense for recipients to check reputations of incoming mail.

The tag would not be the sender indicating that they have a good  
reputation. Rather the tag would indicate whether the source of the  
message from within their domain is trustworthy.  A DKIM based  
reputation will be expensive and perilous.  As the DKIM signature  
does not encompass the envelope, evaluation must first discard the  
envelope when considering the reputation of the signing-domain.  DKIM  
related bad acts are therefore limited to message content, such as  
malware, forged headers, or dangerously misleading links and  
information.

Use of DKIM will evolve into marking messages from trusted domains.   
Cisco already does this internally, and there are several companies  
following suit.  Users are not expected to recognize email- 
addresses.  The problem many domains have is not all users with  
access are trustworthy.  Perhaps this domain would like messages from  
their administrator marked as trustworthy, but would never wish this  
mark added to just any of their signed messages.  Tagging the DKIM  
key would be one method to impose selective message trust-marks.   
Perhaps financial institutions improve security and not have temp  
workers messages receive a trust-mark, while still signing all their  
messages to ease filtering efforts.

The vast amount of email will be from users that normally would not  
be considered trustworthy.  Only seeing a smaller percentage of  
message marked as trustworthy by the sender reduces the overhead  
needed to evaluate violations of trust (based solely upon the message  
content).  IP block-lists will still handle the majority of abuse,  
but DKIM can be used to produce a vetted list of trustworthy domain  
names.  Messages not marked with a tag as trustworthy by the signing- 
domain can be ignored by the DKIM trust vetting process.  The major  
effort remaining would be to ensure bad actors can not corrupt the  
trusted list data-base, and that it can be defended.

A secondary concern would be message replay abuse, which is why the  
envelope is discarded.

Guarding against message replay abuse may require a secondary  
qualification of the message.  Sender-ID or HELO verification could  
qualify the message as not replay abuse.  In some cases, the return- 
path with SPF could also provide this secondary qualification.  None  
of these schemes work beyond a mediator however.  One method that  
could be used to deal with messages without a secondary qualification  
would be to delay acceptance.

While Sender-ID and SPF require the listing of all the IP addresses  
used by their domain, the HELO only needs to return the IP addresses  
for the immediate MTA.  HELO verification can be assured in one DNS  
lookup, whereas SPF/Sender-ID may require more than one hundred.  The  
delayed acceptance practice can be avoided in most cases by ensuring  
the HELO can be verified and can be associated with the signing- 
domain.  Forward reference PTR records that return an RRset of  
associated HELO domains would allow more domains and machines to be  
associated than possible with SPF/Sender-ID, while introducing only  
one additional lookup.  This HELO list strategy could qualify any  
message related domain such as the DKIM signing-domain, the return- 
path, or any other email-address domain.

-Doug

---

From: John Levine <[email-masked]>
Date: 24 Feb 2006 02:44:42 -0000

>The tagging paradigm is, an intermediate stop along the way adds the tags.

Oh, OK, that makes sense.  There are certainly plenty of tagging
systems around, and DKIM will probably concoct another one.  It's
not hard to imagine usage scenarios.

>     2c:   How does a tagging authority identify itself?

Can you write up a strawman draft for us to argue about in in Dallas?

R's,
John