This is a slightly different topic, but note the problems of Vincent's
"TRUSTe Certified Trusted Sender" seal. It's an interesting idea (and run
by his ePrivacy Group) but the implementation is flawed.
First, his attractive graphic iamge (replaced by "see bottom" text) doesn't
forward. Second, I almost snipped off his verification URL at the bottom
along with all the reply text, probably a common error. Third, many mailers
will not properly forward a URL that's hundreds of characters long (why not
a short URL with an MD5 hash?).
Fifth, and maybe this is a minor point, but the website is terribly
designed. Following his URL and clicking on the only link on the page takes
you to a page that has moved. There are typos in the first paragraph of the
about page once you get there ("comapny"). Some pages tell you to "click
here" but provide no links for you to click on:
http://www.postiva.com/article/articlestatic/24/1/5/?POSTIVAID=78fe23dc98c10eee785b15b47de4b112
The "Terms of Use" dated 7/11/2002 are still "coming soon," and so on:
http://www.postiva.com/article/view/18/1/5?POSTIVAID=78fe23dc98c10eee785b15b47de4b11
2
Sixth, if you click on the link and claim you're the recipient of the mail,
it says "verified," but if you click on the link and claim you're NOT the
recipient of the mail and received it via a forward, then TRUSTe says "the
message cannot be verified." Now that's just silly, because (perhaps this
is my lack of understanding) the Trusted Sender program never guarantees
the body of the message has not been modified even when you are a recipient.
Or maybe I'm missing something. I'll naturally offer Vincent the right of
reply again. The message to which he's responding is here:
http://www.politechbot.com/p-04939.html
-Declan
---
From: "Vincent Schiavone" <vsat_private>
To: "'Declan McCullagh'" <declanat_private>
Subject: RE: Critiques of ePrivacy Group's ideas for trusted email senders
Date: Tue, 08 Jul 2003 23:09:21 -0400
Message-Id: <002801c345c7$7eee22d0$6401a8c0@PRIORATUS1>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
|TRUSTe Certified Trusted Sender|
| See bottom to verify |
Declan,
With the assistance of my colleagues, David Brussin, Ray Everett-Church and
Stephen Cobb we have reviewed and organized the critiques from your readers
into several general categories and provide the responses below.
1. There's no need for a new crypto approach, because PGP & SSL/TLS & SMTP
AUTH & X.509v3 already exist.
Answer: Many of those technologies authenticate TCP connections only, and do
not convey any information about the identity of the sender or the contents
and permission-basis of the message itself. TEOS is a proposal for a
framework for end-to-end authentication for the message itself, which can be
read, checked, and acted upon at *any* part of the email delivery chain. And
while there are other crypto technologies that can accomplish this same
task, our specific implementation (which is based on a highly streamlined
and stripped down version of X.509) is very lightweight and highly scalable
and can be integrated into an MTA. We discuss this in greater detail in the
White Paper.
2. The only way this works is to mandate it by law, which is a bad way to
run the Internet.
Answer: We don't believe a law is required to make it work. A law can
certainly encourage adoption by creating safe harbors for those who adopt
authentication technologies or legally bind themselves to following
privacy-enhancing practices. We agree that mandating technologies or
standards in law isn't a good idea, but you can create incentives that
encourage the development and adoption of new technologies that improve the
situation. What it does take, however, is simple and universally accepted
standards, cheap implementation, and widespread acceptance. TEOS is a
proposal for open standards, ePrivacy Group offers it's particular
implementation royalty-free. All that remains is for ISPs and businesses to
show the courage of their convictions and step up.
3. Anything that adds authentication or content assertions is bad for
anonymity and civil liberties.
Answer: Please reread the proposal because you fundamentally misunderstand
the basis of the concept. TEOS is not intended to create any threat to
anonymity, and there's nothing about it that's incompatible with anonymity.
In a world where TEOS has been developed and adopted, there's still a place
for anonymous mail, and mail that bears no content assertions. Indeed, it's
entirely possible for an anonymous remailer to actually authenticate mail as
truly being from that remailer. It's all up to the receiving system whether
they wish to accept mail from that authenticated source -- much as it is
today. Likewise, we do not intend to require content-labeling as a baseline
element. It is only a feature of that part of the proposal suggesting the
creation of bulk sender and "Trusted Sender(tm)"-type self-regulatory
programs for commercial email. We do not seek to break email; we only seek
to add additional data upon which recipients can make decisions. As such,
there's nothing inherent in the TEOS proposal that makes anonymity
impossible.
4. It puts ISPs in too much control over end-user's email.
Answer: The only way to take ISPs out of the email-delivery equation is to
be your own ISP. That's not practical for the vast majority of the world.
The fact remains, ISPs are already in the middle of the picture and they
constantly wrestle with their customers' demands that they deal with the
spam. Currently the only way to do so is to supplant the ISP's judgment
about what's "legitimate" or give control over to blacklist operators'
judgment of what's "legitimate". An ISP can provide the mechanism for
allowing verification of authenticity and in doing so can actually have a
logical basis for making some decisions on their customer's behalf (e.g.:
"the sender of this message is a bald-faced liar; the message doesn't
authenticate as being from the place claimed").
Those who choose to send unauthenticated or anonymous mail wouldn't have to
use it, although they would have no guarantee of getting their mail
delivered if a receiving system decided to only accept authenticated mail.
But then again there's no guarantee of delivery today, so there's no
difference there. But at least authenticated messages could be separated out
of the queue and dealt with differently. This is about adding "positive"
attributes to legitimate mail in order to get it differentiated from the
junk.
5. An oversight board sounds too much like ICANN.
Answer: This issue has been discussed on SPAM-L
(http://peach.ease.lsoft.com/archives/spam-l.html) some length. We certainly
understand the knee-jerk reaction that many have to any mention of any kind
of centralized process for doing *anything* Internet related. The
incompetence and arrogance of ICANN has definitely poisoned the atmosphere.
But don't simply dismiss TEOS without understanding the role we suggest for
an oversight body. Our proposal is to have a truly representative body that
does little more than establish the standards upon which the framework is
based. They would not be in the position of doing anything more than
determining whether participants met the technical and procedural standards
to be certifiers, or oversight bodies of self-regulatory programs, etc.
Since we're proposing system based on an unlimited number of "trust
authorities" there is no central resources over which a board would exercise
monopolistic control (c.f., ICANN and DNS). We suggest that the oversight
board's role is much more comparable to the IETF than ICANN.
I would like to thank Politech readers for their interest, comments, and
support we have received directly. At ePrivacy Group we believe that only
an engaged community, working cooperatively, can hope to forge a solution
that can be effective against the parasite of spam.
Vincent Schiavone, CEO
ePrivacy Group Inc
d 610-407-7083
m 484-432-4532
__________________________________________________________________________
> -----Original Message-----
> From: Declan McCullagh [mailto:declanat_private]
> Sent: Tuesday, July 08, 2003 9:46 AM
> To: politechat_private
> Cc: vsat_private
> Subject: Critiques of ePrivacy Group's ideas for trusted email senders
>
>
> Previous Politech message: http://www.politechbot.com/p-04937.html
>
> ---
>
> Date: Tue, 8 Jul 2003 07:34:44 -0400
> From: Rich Kulawiec <rskat_private>
> To: Declan McCullagh <declanat_private>
> Subject: Re: FC: ePrivacy Group's idea: "Trusted Email Open Standard"
> Message-ID: <20030708113443.GA21311at_private>
>
> > For the better part of two years I have been working with
> my colleagues at > ePrivacy Group to draft a roadmap towards
> a spam-free future (some of them > have been working on the
> problem for even longer than that).
>
> This is yet another completely misguided proposal that
> indicates a near-complete lack of understanding of the spam
> problem. It seeks to re-engineer mail, which MAY be a
> worthwhile goal, but (a) will not stop spam and (b) therefore
> should not, as a process, be primarily driven by the spam problem.
>
> Spammers have already demonstrated great ingenuity in evading
> anti-spam measures and in switching to different propagation
> vectors: direct-to-screen pop-up window spam is increasing,
> and I've now seen several reports of direct-to-log spam.
> TEOS will not solve this, nor will challenge-response, nor
> will so-called "trusted sender" measures, nor will spam
> filters, nor will anything else EXCEPT *removing the spammers
> from the Internet*.
>
> Most spam comes from a relatively small group (c.f. ROKSO,
> which has extensive documentation on this) of individuals.
> Simply removing this group of ~200 people from the Internet,
> *permanently*, would do more to cut down on spam than all
> other measures combined. It continues to fascinate me how
> this rather simple and obvious realization eludes some (and
> is deliberately ignored by others -- including those who have
> a chance to profit from the 'net's collective misery).
>
> It's worth noting that there was a time when spamming did in
> fact mean removal from the 'net -- and it's also worth noting
> that the slang term "spam" did not exist at that time,
> because it didn't need to: one doesn't need a word to
> describe a problem that doesn't exist. It was only when
> spam-friendly ISPs ceased removing spammers
> instantly/permanently that spam began to become a serious
> problem (and thus required a handy name).
>
> It is well past time to return to this practice: which leaves
> us with only the question "When will
> Verio/AT&T/XO/Rackspace/QWest/Microsoft
> remove the career spammers that they KNOW are on their
> networks?", or, to put it another way, "Why should hundreds
> of millions of Internet users have to put up with spam for
> years when the permanent disconnection of a few hundred
> individuals would solve the majority of the problem in a single day?"
>
> ---Rsk
>
> ---
>
> Date: Tue, 8 Jul 2003 05:34:24 -0400
> Subject: Re: FC: ePrivacy Group's idea: "Trusted Email Open Standard"
> Content-Type: multipart/alternative; boundary=Apple-Mail-2--107230257
> Mime-Version: 1.0 (Apple Message framework v552)
> Cc: vsat_private
> To: declanat_private
> From: George Ellenburg <georgeat_private>
> In-Reply-To: <5.2.1.1.0.20030707235435.043dbdd8at_private>
>
> Hi Declan,
>
> I am not saying that this initiative is going to fail, but
> given the ten
> bullet-points below, it sounds as though this initiative will
> have a high
> probability of failure unless there is some industry (re:
> majority of ISPs)
> or Government mandate for the following reasons:
>
> [Several introductory paragraphs removed.]
>
> >1. Spam is possible because SMTP, the technology used to transmit
> >email,
> >does indeed stand for Simple Mail Transport Protocol, which does not
> >bother to verify the identity of email senders.
>
> SMTP is not unlike any other protocol which works on top of
> TCP/IP. A
> connection is opened, it's acknowledged, an acknowledgment is
> sent back to
> the originator, and the originator starts sending data. All of this
> happens at the protocol-level, before SMTP even comes into
> the picture.
>
> There already exists several methods for verifying the
> identity of Email
> senders, and Email servers. SMTP-AUTH is a widely used method for
> authenticating the SMTP data-stream, as well as TLS/ SSLv2
> which can be
> used, too, whereas PGP is the oldest and trusted method for
> authenticating
> Email senders.
>
> Neither of these are a viable option for a wide-scale
> implementation since
> their use is (a) not mandated and (b) not widely adopted.
>
> >2. Spam happens because people are human and prone to do
> sleazy things,
> >particularly when there is money to be made and the chances of being
> >caught are slim. SMTP allows these people to lie to the
> recipients of
> >their messages, and the Internet Service Providers (ISPs)
> that deliver
> >them, by "spoofing" the sender identity, making the message
> appear to be
> >from some other person, real or imagined.
>
> This sounds like more of a problem which could be handled
> through (dare I
> say it?) legislation than anything else. But unfortunately,
> legislation is
> only as powerful as much as it can be enforced, and until the
> free nations
> of the World ratify a treaty outlawing forged identities there can be
> little hope for enforcement.
>
> However, there does exist current laws on the books which
> make it a crime
> to knowingly connect-to, and mis-use the computing services
> of another
> network or computer system without authorization. It seems
> more likely
> that the existing laws can and should be leveraged in the use
> against UCE.
>
> >3. Any solution to the spam problem must address both technology and
> >human
> >behavior.
>
> Agreed, and absolutely.
>
> >4. Any solution to the spam problem must account for the legitimate
> >ways
> >in which people use email today. You can't say all bulk mail
> is banned,
> >because I have already given permission for numerous
> organizations to
> >include me in bulk mailings (such as last minute air fares
> that I don't
> >want to miss). And you can't say all unsolicited email is
> banned, because
> >if someone is offering a big discount on a product I am
> about to buy, I am
> >pleased to find out about it, even if I did not specifically
> ask that
> >person to tell me.
>
> What one can do is say that it shall be illegal for any person or
> organization to send an Email advertising a product without
> first obtaining
> written approval from the recipient. Written could just as easily be
> construed to be a double-opt-in type of scenario, but the
> advertiser should
> and must be able to provide proof that the recipient actually
> signed up for
> the product if and when such signups are questionned.
>
> Sounds like a perfect opportunity for PGP digital signatures,
> if you ask me.
>
> >5. Any immediate solution to the spam problem must work without
> >replacing
> >SMTP, which is just too big a task to happen any time soon.
> And it should
> >offer several levels of fix, because one size is unlikely to fit all.
>
> Agreed.
>
> >6. So TEOS takes three steps forward . The first is a simple
> >enhancement
> >to current email technology that enables senders to identify
> themselves
> >more securely and reliably. This allows ISPs and recipients to make
> >better decisions about what to do with messages (e.g. those
> that come from
> >senders who are prepared to identify themselves are more
> likely to be
> >legitimate than those that don't).
>
> The ISP shouldn't be in the picture at this stage. It is of
> no concern for
> the ISP what types and level of Email their subscribers are
> receiving, and
> to only involve the ISP will only further add to their costs,
> but will
> reduce the level of privacy for their subscribers at the same
> time. Judging which piece of mail is either UCE or not is,
> and should be,
> entirely left up to the recipient.
>
> >7. The next step is to enable senders of bulk email to says things
> >about
> >their messages that can be read by the computers that
> process them. We
> >call these "assertions" and they are made in the part of the
> header of the
> >message recipients don't see. A bank might assert that a
> message is a
> >customer statement to an existing customer . A charity might
> assert that a
> >message is a newsletter to which the recipient has opt-in
> subscribed. A
> >marketing company might assert that its messages meet
> certain standards
> >for permission-based offers. These assertions enable ISPs
> and recipient to
> >make even better decisions about which message to accept
> and, because the
> >sender's identity has been verified, there is a good chance
> the assertions
> >are true (it is a lot riskier to lie about messages when
> people know who
> >you are).
>
> This can easily be accomplished through legislation, and
> already is to a
> certain extent. Faxes are required to contain information
> which clearly
> states the sender on all faxes, and it is illegal to send an
> unsolicited
> commercial fax to someone. These laws can, and should be, leveraged
> against the fight against spam. Unfortunately, the
> regulatory (FTC & FCC)
> agencies don't have enough man-power to do the enforcement,
> so there should
> be ample options for civil redress available to the public so
> they should
> be able to enforce the laws themselves.
>
> >8. The last step goes beyond making assertions that are coded into
> >message
> >headers and gives those companies that want to display their
> commitment to
> >the highest email standards a seal or trust stamp that they
> can place into
> >their messages. These trust stamps are unique to each
> individual message
> >and cryptographically protected to make them almost
> impossible to "spoof."
> >They allow ISPs and recipients to immediately verify whether
> or not the
> >sender is a member in good standing of a program designed to promote
> >responsible email.
>
> Again, this sounds like PGP would be the perfect place-holder
> for such a
> technology. Spammer obtains my public-key, but they have to
> exchange with
> me their public-key in order for any encrypted messages sent
> by them to be
> decrypted by me. Hmmm, the fact that I've willfully added
> the spammers
> public-key to my key-ring sounds like a good prima-facie test
> that I've
> authorized the receipt of their messages.
>
> >9. Oversight of the standard, and programs that promote responsible
> >email
> >(of which we think there will be quite a few, each with its
> own unique
> >appeal) will be handled by an oversight board. The members
> of the board
> >will represent all relevant interests, from recipients
> (consumers), to
> >email providers (ISPs and web mail providers), to email senders
> >(companies, government agencies, non-profits, and so on).
> The board will
> >operate internationally, delegating authority to different
> regions, and
> >certifying organizations that verify identities and assertions.
>
> I think the author is dreaming with this one. Oversight
> boards? All one
> has to do is look to ICANN to see how terribly wrong any type
> of oversight
> board, charged with governing any aspect of the Internet, can
> go wrong.
>
> >10. A vast improvement in email will occur if TEOS is adopted. The
> >economic incentive to send spam will have been eroded because those
> >senders who are not honest about who they are and what they
> are sending
> >will find their email is not delivered. At the same time,
> TEOS preserves
> >the ability of individuals to send email to each other,
> anonymously if
> >they wish. TEOS embraces the best of email today and extends
> it, using
> >platform agnostic technology that is low in cost and proven to work.
> >ePrivacy Group will even donate some of its patent-pending
> technology to
> >the Internet community to make this happen if the key
> players can commit
> >to this roadmap.
>
> Then again, a vast improvement to Email will occur if there
> is continued
> education, legal enforcement of the laws which already exist, and
> technological adoption of technologies which already exist as well.
>
> Nothing to see here, please move on ...
>
> (Declan, feel free to repost if you want.)
> --
> George M. Ellenburg <georgeat_private>
> PGP Key ID: 0x459965D8
>
> ---
>
> Date: Tue, 08 Jul 2003 09:21:57 -0400
> From: "Eric S. Johansson" <esjat_private>
> To: declanat_private
> Subject: Re: FC: ePrivacy Group's idea: "Trusted Email Open Standard"
>
> Declan McCullagh wrote:
> >---
> >From: "Vincent Schiavone" <vsat_private>
> >Date: Mon, 07 Jul 2003 18:25:44 -0400
> >The Trusted Email Open Standard (In Ten Bullet Points)
>
>
> Identity based antispam systems are tools for control and
> censorship. Anytime you can disable a spammer's ability to
> send mail based
> on "identity", you can disable anyone's ability to send e-mail.
>
> additional flaws include
> Investment in infrastructure compensating for inevitable
> network outages,
> Infrastructure costs placed on e-mail users instead of spammers,
> Requiring trust in central authorities to do the right thing.
>
> My belief is that moving to a identity based e-mail
> environment will create
> a situation like we have with certificates and browsers today.
>
> Identity mechanisms have their place in various parts of the
> net but that
> does not include e-mail.
>
> As an alternative, I folks should look more closely at sender
> pays mechanisms. Some of the highlights of sender pay systems are:
>
> Does not interfere with freedom of speech
> Keeps control in the hands of the e-mail recipient
> Places burden on appropriate parties (bulk senders with
> whom you have
> no relationship)
> Low/no burden for those you have established a relationship
> Scales nicely from individuals to large ISPs
> No central infrastructure additional costs on innocent parties
> Reliable even when network is not
> Proven mechanisms to handle transition between now and future
>
> The camram project is building a framework for experimenting
> with various
> forms of sender pays systems and transitional issues from no
> postage to all
> postage.
> The camram project has released an early stage sender pays
> system that is
> working well in the field. The next revision will be
> released soon and
> will contain a variety improvements suggested by our users.
>
> I hope people will experiment with sender pays systems
> because they hold a
> great deal of promise as an antispam measure.
>
> ---eric
>
> esjat_private
> 978-392-3650
>
>
_____________________________________________________________________
From: vsat_private
To: declanat_private
8 Jul 2003
"ePrivacy Group" is a TRUSTe Certified Trusted Sender
Follow Link to Verify at verify.trustedsender.org
<vsat_private:UkU6IENyaXRpcXVlcyBvZiBlUHJpdmFjeSBHcm91cCdzIGlkZWFzIGZ">http://verify.trustedsender.org/start_verify.php?AAIxxuWAN17qb9SxGrresLdbfrjfhcsUxfQy/Lwc0YZhvGIIblWGquzt32FAU6glJtAsvpaEcB0znpVFGKYTVfuwPhx4V7QM6C7PwuHZAAAAAAAAAAAAAwell.com:vsat_private:UkU6IENyaXRpcXVlcyBvZiBlUHJpdmFjeSBHcm91cCdzIGlkZWFzIGZvciB0cnVzdGVkIGVtYWlsIHNlbmRlcnM>
_____________________________________________________________________
-------------------------------------------------------------------------
POLITECH -- Declan McCullagh's politics and technology mailing list
You may redistribute this message freely if you include this notice.
-------------------------------------------------------------------------
To subscribe to Politech: http://www.politechbot.com/info/subscribe.html
This message is archived at http://www.politechbot.com/
Declan McCullagh's photographs are at http://www.mccullagh.org/
Like Politech? Make a donation here: http://www.politechbot.com/donate/
-------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Thu Jul 10 2003 - 07:18:37 PDT