Subject: Re: domain ABNF
From: Tony Finch <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Date: Sun, 23 Aug 2009 01:14:16 +0100
List-Id: <ietf-smtp.imc.org>

On Wed, 19 Aug 2009, Hector Santos wrote:
>
> Just a confirmation, is a domain allowed to have single and double quotes?

Not in SMTP.

   Domain         = sub-domain *("." sub-domain)
   sub-domain     = Let-dig [Ldh-str]
   Let-dig        = ALPHA / DIGIT
   Ldh-str        = *( ALPHA / DIGIT / "-" ) Let-dig

The 822/2822/5322 syntax is more liberal. However double quotes are still
not permitted except in domain literals.

In email the ' character is used as an apostrophe not as a quotation mark
(except by Microsoft).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Date: Wed, 19 Aug 2009 04:21:04 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
Subject: domain ABNF
Sender: [email-masked]

Just a confirmation, is a domain allowed to have single and double quotes?

It appears the ABNF indicate it does allow these characters.

Working on a parser/filter to address (java)script tag injection 
potentials.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Fri, 14 Aug 2009 10:27:28 -0400
From: Rich Kulawiec <[email-masked]>
To: [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

I've just read this again, looking for something that may have eluded
me on the first pass, and I still haven't found it.  So either it's not
there, or I'm just not seeing it.  (If the latter, I apologize for being
dense.)

To wit: how does the site initiating email traffic know that the email
address it's been given belongs to the putative requestor?

---Rsk

Date: Fri, 14 Aug 2009 10:21:22 -0400
From: Rich Kulawiec <[email-masked]>
To: [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

On Thu, Aug 13, 2009 at 08:11:54AM +0400, Cheney, Edward A SSG RES USAR USARC wrote:
> 
> > In my limited understand, SMTP is a store-and-forward protocol.  Will
> > this affect your proposal?  I imagine it would not be pleasing to
> > click on something you expect to be interactive and have it respond 4
> > hours later.  Maybe I should go read your draft more thoroughly --
> > you probably already thought of this.
> 
> It is certainly possible an interactive reply from a distant mail server
> could take 4 hours so liberal a time to live were allowed.  I don't see
> that as being common, however. 

But it *is* common.  One of the myriad anti-spam techniques in common
use today is "greylisting", which can be implemented all kinds of
different ways, but basically consists of giving a "try again later"
response to first attempts to deliver mail messages.  This works quite
well against some spam delivery attempts (which are being performed
by malware agents that can't/don't retry) and it works sometimes against
some other spam delivery attempts (performed by mail servers that *do*
retry) because, for instance, it buys time for DNSBLs to notice the
spam source and list it.  There all kinds of nuances to this, which I
won't go into here because they're not relevant, but the bottom line is
that lots of sites do this, including some large ones (e.g. Yahoo).
The delays imposed vary, of course, but 1-4 hours seems to be ballpark.

---Rsk

Date: Fri, 14 Aug 2009 09:17:45 -0400
From: Rich Kulawiec <[email-masked]>
To: [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

On Sat, Aug 08, 2009 at 08:33:45AM +0400, Cheney, Edward A SSG RES USAR USARC wrote:
> I do wish to be clear that when I say most significant I mean that
> purely in a quantitative and not a qualitative manner.  Vulernabilities
> associated with client-side scripting are certainly not the most harmful
> forms of security intrusion.

I'm not sure what you mean by "most significant in a quantitative manner",
if I might try to correctly put the pieces together.  Do you mean (a) most
numerous in type, or (b) most numerous in scope, or (c) most numerous in
effect, or (d) something else?   I'll certainly agree, for example, that
there are a lot of scripting exploits out there, and that they show up
on a lot of web sites, and that they seem to affect a lot of systems; but
I'm not sure which (if any) of those "lots" you're referring to.

As to whether they're most harmful or not, well, the best response I can
give to that is "it depends".  Those that lead to full-system compromise
are certainly very harmful; those that only annoy the browser user much
less so.

But for the purpose of this discussion, it's probably not necessary
to get into these fine details.  I'll grant that the scripting attacks
exists, and that there are enough of them that are sufficiently clever
to constitute a problem worth solving.  My quarrel with the wording
is that it seemed awfully definitive about something that we're still
fumbling our way around: I don't think anybody's got statistics on these
that are any better than "educated guess".  (More succinctly, we're
all wrong.)

> > These are (a) web browser and (b) operating system vulnerabilities,
> > and are quite readily mitigated by making sensible choices about both.
> 
> I draw a solid distinction between mitigation and solution.  A
> mitigation is a proactive action to ensure systems or data in your area
> of responsibility are protected against security breaches from both
> internal and external users.  That is an attempt to avoid the problem,
> and it is not a solution to the problem.  A solution is a recommendation
> that intends to eliminate the problem, which thereby reduces the scope
> of mitigation in a given security assessment.  In other words, if
> actions to a system were really a solution to client-side security
> vulnerabilities then those security flaws must never again occur upon
> that system, correct?

For the sake of discussion, I'll accept this terminology, and amend my
comment to:

	These are (a) web browser and (b) operating system vulnerabilities,
	and are mostly solved by making sensible choices about both.

I say "mostly" because neither (a) nor (b) is a panacea.  They remove
many of the vulnerabilities that client-side scripting tries to exploit,
but of course they don't remove them all.  The other measures I suggested
(let's label them (c) browser extensions, e.g., NoScript and (d) filtering
or blocking HTTP proxies) would then, I suppose, still be mitigation,
not solutions, because they don't actual remove the vulnerability --
they just try to keep the attack from reaching it.

But whether we call them solutions or mitigation, the point is that all
of these exist today (in profusion), they can be used singly or in
combination for a defense-in-depth approach, and none of them require
us to do network engineering.  And because of that last point, none of
them require web site, mail server, DNS, or other operators to make
significant efforts to accomodate them.  (To put it another way, I could
compel all local users to migrate to Safari on MacOS X and push all
their HTTP requests through Privoxy; but if I did so, the scope of
that effort would be local-only, alleviating the need for the entire
rest of the 'net to accomodate my approach.)

My sense (and I won't claim that this is rigorous) of things is that
this general approach has barely been used.  Enormous numbers of 
people are still running Windows; most of them are still running IE.
Of the people who have migrated off Windows or IE, most of those are
not using extensions.  And not many folks are running HTTP proxies
for their users' benefit.  Yet doing all of these things, alone or
in combination, represents a lower level-of-effort with a higher
probability-of-success than starting a whole new engineering project.
More bluntly, if we can't get people to do the relatively simple,
relatively easy, relatively cheap things that we already know work
(for various values of "work") how will we possibly convince them to
do something much more complex, hard and expensive that may or may
not work?

> > If, on the other hand, poor choices of web browser and/or operating
> > system (or mail client, for that matter) are made, then it really
> > doesn't matter whether traffic moves via HTTP or SMTP or anything
> > else: those systems WILL be compromised.
> 
> Users can only be protected from themselves through adherance to
> policies, procedures, and relevant training.

Well, on this we agree.  But while this works (again, for some values
of "work") in some very limited and controlled settings, it doesn't
work at all at the scale of the Internet.  Users will ignore policies,
forget procedures, and refuse training -- because they can.  We can't
fix this with engineering because we can't fix this *at all*.  What we
can do -- and we can do it today -- is furnish them with software
tools that make it less likely they'll inflict damage (and reduce
the scope of the damage that does happen), and we can do it without
major network/protocol engineering effort.  We should really try these
simpler/available approaches before attempting anything more complicated.

---Rsk

Date: Thu, 13 Aug 2009 09:11:54 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: IETF SMTP list <[email-masked]>
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Cheney, Edward A SSG RES USAR USARC wrote:
> This has become an absolutely horrific experience that has long since
> left the field of argument. 

Actually, you've been given consistently constructive responses, and with vastly 
more diligence and persistence than I'd have recommended.  You are consuming 
quite a lot of experienced and expensive talent on this list.

The core problem is that you've systematically rejected any that you didn't want 
to hear; you seem to think that by pressing harder you will be able to steamroll 
past folks with concerns or disagreements.  The difference between a response 
mode that attempts only to sell one's point of view, versus one that seeks 
mutual understanding and agreement, is fundamental.  There is nothing subtle 
about evaluating which you've chosen.  Persuasion versus collaboration are 
fundamentally different goals.  You've chosen to attempt the former, in a venue 
that calls for the latter.

Take a look over the lengthy thread.  Unless I've misread the exchange, you 
haven't recruited any support.  None.  Yet garnering support is at the core of 
how the IETF works.  It is the key filter for making progress in the IETF.

Again:  You have been given an extensive set of constructive responses.  You 
need to accept them and adapt your work and your working style accordingly.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 13 Aug 2009 11:58:41 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: John C Klensin <[email-masked]>, IETF SMTP list <[email-masked]>
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Cheney, Edward A SSG RES USAR USARC wrote:

> John,
> 
> This has become an absolutely horrific experience that has long since
> left the field of argument.  I believe I am certainly coming away with
> less than I have originally began with and simultaneously nothing has
> benefited the IETF.  Some of the persons here have been quite helpful
> asking questions about the relevance of the idea or criticizing the
> langauge in the draft.  At the same others seem more interested in some
> unspoken self-interest that has nothing to do with the technical merits
> of my idea, this process, or the IETF.

You know that isn't true. And its really an unfair statement. I 
honestly held back my true feelings for which I am glad John stated 
very adequately.

Namely, the only obvious self interest here was your own proposal and 
statements to the effect that the industry will fail if they don't 
adopt your specific implementation for a web based SMTP client which 
by your own claims has patent pending ideas.  Your approach was there 
is NO ARGUMENT AGAINST IT because  the technology is sound, therefore 
it must be a standard and it must be adopted.   You said that quite a 
few times.

I provided my side that:

  - DOM EVENT is important

You indicated they are not allowed,  YET, if one reviews your 
document, it is entirely based on DOM and AJAX methods. I don't think 
you can have it both ways.  Your proposal REQUIRES AJAX.  So here is 
an highly subjective position that suggest don't use an HTTP based 
call, use a SMTP-based call instead for AJAX.

  - There are major strategies for WEB 2.0

You chose to ignore the business interest and suggested it doesn't 
play a role in deciding what technologies to adopt.  Instead, you went 
to to suggest, they are doom to fail if they don't adopt your methods.

You made claims that not adopting SAFE will cost businesses livelihood 
and may go out of business.

You made claims that XML formatted mail does not exist. Not true.

It was quite obvious that you were focused on a specific product model 
which you though was better. I'm glad John highlighted this errant 
approach of yours.

> The respect for the process I once held on such high esteem is waning as
> I have been handed a rather bitter experience.  I do understand this
> experience is likely not representative of the norm or the majority of
> individuals who commonly contribute.  Even though, if a proposed idea is
> so unpopular that if demands the technology be ignored in favor of
> future postulations and personal criticisms then something has gone very
> badly and something in the process has broken.

You choose to insist that there would be no compromise to your 
proposal. No DOM events - period!  You choose to ignore that this 
would be a major show stopper for me and that major javascript API 
developers would be affected by your proposal.

That is now how the group works. You need to compromise.  You had 
three strikes - no dom events, patent pending features and a complex 
solution to a problem that has less costly solutions.  If you can't 
accept these criticism, I am not the blame for any of this.  If it 
wasn't me, someone else would of eventually highlighted.

-- 
Sincerely

Hector Santos
http://www.santronics.com

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: IETF SMTP list <[email-masked]>
Date: Thu, 13 Aug 2009 18:59:59 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

John,

This has become an absolutely horrific experience that has long since
left the field of argument.  I believe I am certainly coming away with
less than I have originally began with and simultaneously nothing has
benefited the IETF.  Some of the persons here have been quite helpful
asking questions about the relevance of the idea or criticizing the
langauge in the draft.  At the same others seem more interested in some
unspoken self-interest that has nothing to do with the technical merits
of my idea, this process, or the IETF.

I have already come to the conclusion earlier today to retract from a
general submission.  I have already emailed the area directors of the
security area to see if this idea may fall into their scope of drafts.
If they believe my draft does not fall into the scope of their area I
will complete retract from the IETF.

While I began with hopes of refining an idea that may or may not be
accepted through refinement of the process I have instead found
arguments that have been far closer to criticisms of myself than of the
technology.  I attempted to steer the conversation back towards the
draft, but instead faced more of the same.  I cannot explain the
motivation for what appears to be a rather focused and determined
attempt to disuade this draft on behalf of a rather few individuals.

The respect for the process I once held on such high esteem is waning as
I have been handed a rather bitter experience.  I do understand this
experience is likely not representative of the norm or the majority of
individuals who commonly contribute.  Even though, if a proposed idea is
so unpopular that if demands the technology be ignored in favor of
future postulations and personal criticisms then something has gone very
badly and something in the process has broken.

Thank you,
Austin

Date: Thu, 13 Aug 2009 07:51:42 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC:  [email-masked]
Subject: Re: [AKO Warning - Message fails DKIM verification] Re: [AKO Warning - Message fails DKIM verification] Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Edward,

Sounds to me you have three technologies:

   - XML structure for Web EMAIL representation (EXML)

      - CLAIM: covers all client/server I/O requirements

        (I saw where this is not the case, but thats
         besides the point just to say I wouldn't go
         to far to say it does)

   - A DOM XHR SMTP-client component (XHR-SMTP)

      - CLAIM: Allows replacement of existing web mail
        interfaces.

   - A SMTP server extension to handle XHR-SMTP transactions
     and/or payloads with EXML content.

When augmented or integrated, you have the SAFE proposal.

If this is the understanding, I still don't see what problem it 
resolves other than allowing for the design of pure SMTP browser based 
clients.

The technology advancement here is XHR-SMTP to allow browser agents to 
act as smtp clients.  If so, this can be done today with a browser plugin.

Overall, your concern is that non-SMTP based web mail applications are 
insecure.  If so, I don't agree with that. Any system offering a web 
mail interface is not design prohibited in interfacing with their 
backend. These tend to be locked in and proprietary for good reason. 
In fact, a XHR-SMTP would open the door to potential abuse. No 
different than attempting to hack into proprietary system, but with 
XHR-SMTP in place, the target market is wider to single source an attack.

That said, I think that if your broke up the proposal, it might be 
worth considering.  But I also think that you need to get away from 
claims it will save any real problem. I don't see that.

XHR-SMTP can be generalized and not depend on EXML or the SMTP 
extension. That would be a plus I think. EXML can be a plus too as it 
be applied in existing interfaces with AJAX or JSON/P approach.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Cheney, Edward A SSG RES USAR USARC wrote:

> Hector,
> 
>> For people who have been in the mail business for a very long time,
>> that is a pretty broad claim.
> 
> It is a broad claim.  I have seen several different attempts at creating
> a markup language for email, but none that fully function and support
> the complexity of SMTP protocol compared to the simplicity of the HTTP
> protocol.  Such support would require conventions in an document capable
> of supporting multiple various authors uniquely such as an email thread
> without data cross-contamination from multiple contributions upon that
> document.  SGML/XML do not provide this capability.
> 
> When I was searching for prior art I found attempts at creating markup
> languages that made some progress towards defining content, but rarely
> did they make any attempt to absorb RFC 5322 definitions into structures
> represented by their language.  I never saw any of these prior arts
> solve the problem of the prior paragraph.  Most of the concepts
> represented of my language are not original, even the name of the
> language is not original, but still I had never seen anything that
> provided the benfits of markup to represent all currently practiced
> user-agent conventions of email.
> 
> So while there have been attempts at creating markup language for email
> in the past none were either functional or solved the complexity of
> challenges represented by email that do not exist for the web.  That
> does not mean my language is the best for the job, and I have never
> claimed that it is.  Until something else comes along with its own
> unique solutions to common practices the language I wrote is the only
> thing I would refer to as a full markup language for email where all the
> prior attempts I have seen do not do the full job of the task.
> 
> The only one thing I am absolutely certain about is that there is no
> standard for describing content in email.  The closest such thing is a
> suggestive statement from RFC 822, which suggests that content be 7bit
> ANSI characters like the rest of the document.  There is certainly no
> standard for use of whitespace definitions for visually preformatting
> content in emails for processing to user-agents, no standard for shoving
> HTML into an email, no markup language standard, or anything else.  I do
> feel fairly confident that if there were a fully functional markup
> language that it would have some appeal commerically and so its
> existance would be commonly evident even if not in use.
> 
>>From these conclusions and the hundreds of hours I spent doing research
> over the more than 18 months I took to actually write the language I
> feel pretty confident when I say my language is the first markup
> language for email.  I may honestly be wrong this statement, but I don't
> think so.  My language may not be the best choice for its job, but at
> the moment its the only choice.  I would say if my language is of poor
> quality or fails at its job then pick another, but nobody else has
> volunteered their own personal time away from work or family to write
> such a thing.  I don't believe my language should rest as the only one
> of its kind and I hope that I may see some alternatives.  It is only
> from competing alternatives that I may truly know how flawed my attempt
> is.
> 
> 
>> A JSON format could be considered more optimized for wire-data, and
>> this does exist and done after a XML version was tested and pushed
>> aside.
> 
> JSON is not a markup language or peer to XML, although a famed
> client-side evangelist I know of commonly claims otherwise.  JSON is a
> serialized data storage mechanism and nothing more.  XML is a
> meta-language, which is a language for creating languages.  XML is
> commonly misused to act as a human readable data storage mechanism, but
> in my opinion that is a gross abuse of the technology in complete
> defiance of its purpose.  JSON is not competition for XML and people who
> evangelize such likely do not understand what XML is.  JSON is in
> competition with comma separated value format, but not XML.  As a result
> it is a poorly informed response to a bad practice that allows for this
> reasoning of interchangability of JSON for XML.
> 
> 
>> In short, there is nothing new here.
> 
> You may be entirely correct.  The language I created does contain some
> patent pending features, so perhaps in three to five years after the
> US Patent and Trademark office concludes an investigation we will know
> for sure.
> 
> Thank you,
> Austin
> 
> 
> 

Date: Thu, 13 Aug 2009 07:31:53 -0400
From: John C Klensin <[email-masked]>
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
cc: IETF SMTP list <[email-masked]>
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Austin,

With the understanding that this is just my personal opinion,
and perhaps more to others than to you, I think this
conversation has outlived its usefulness for several reasons.
In no particular order:

(1) The real history of email (and modifications/ extensions to
most other Internet applications) is that an innovation has to
be either (i) extremely easy to deploy and obviously readily
compatible with the installed base or (ii) a _huge_ and obvious
improvement to deploy quickly, or even at all.   Instead, we
have seen a very large number of proposed improvements to and
replacements for the basic 822 model come and go.  Even those
that were clearly superior along one or more dimensions have
disappeared because it hasn't met one of those criteria.   Your
language and method do not appear to meet the first criterion;
you are wildly more optimistic about the second than the vast
majority of the more experienced folks here.  

(2) Your questions and comments have shifted from "please review
this technical proposal" to what seems like a passionate
marketing campaign for a particular idea.  It makes no
difference whether that has occurred as a direct consequence of
your actions or as part of people's attempts to explain that
deployment situation --as part of the whole system in which an
innovation within an existing application must exist-- to you.
Beyond some point, it isn't useful.  And we are past that point,
IMO.

(3) Your draft doesn't contain even a hint of a transition/
deployment/ interworking-with-installed-base analysis.   The
closest you come is with such statements as "Data transmitted by
this object using RFC 5322 conformant headers SHOULD NOT expect
successful or accurate interaction with the intended document"
which, to me, suggests that the transition model is "either use
the existing plan or use the new one, but they don't really
co-exist except maybe at the transport level".   That doesn't
predict to easy and seamless deployment.   While such an
analysis is not procedurally required, I suggest to you that it
needs to be present for the work to be taken seriously... and
that many of the comments you have received are indicative of
the fact that it is not.

In that regard, you might find it helpful to study the archives
of the "EAI" WG and its struggles to design and deploy an
extended email address syntax --in principle, a far narrower
change than the one you are proposing and for a purpose that is
far more obvious to a large fraction of the Internet user base--
to get a sense of how seriously those issues need to be taken.

(4) Although your abstract suggests that security is a lot of
what this proposal is about, your actual "Security" section is
woefully inadequate.  It does not discuss attack scenarios, the
difficulties imposed by a processing model in which the remote
user has to just trust that the sending user has not tampered
with the local client (I'm not an expert in these things, but
statements like "The user MUST NOT be allowed to interfere with
the processing of such instructions" appear to me to be fairly
vacuous in the absence of a multilevel-secure, ring- or
domain-isolating, operating system), the well-known problems
with key management by end users in a PKI environment, and so
one and so forth.

(5) One very good symptom of uptake of a new idea in the IETF is
that people come forward and offer to help work through details
and construct text to refine the rough edges of the proposal.  I
haven't seen that happening here even though you have gotten
several constructive comments.  Perhaps you should take that as
a symptom of, e.g., what would happen if you proposed a working
group to standardize this work.   On the other hand, if your
intention is just to get comments rather than to move toward
treating the proposal as an IETF work item, the use of an IETF
list and I-D postings to solicit comments rapidly becomes
abusive.  You are, IMO, close to, if not well past, that line.

(6) One of your recent notes includes the comment:

> The language I created does contain some patent pending
> features, so perhaps in three to five years after the US
> Patent and Trademark office concludes an investigation we will
> know for sure.

Your Internet Draft contains a statement of "full conformance
with the provisions of BCP 78 and BCP 79".  The above indicates
that you are somewhere in the process of filing for patents.
There is no disclosure on file as required.  Your "mail markup
language" draft, while apparently never posted as an I-D (and
containing statements that indicate that it is one), contains
the equivalent statements and your discussions and the
references in "draft-cheney-safe" certainly constitute
introducing it into the IETF.  That document contains some
rather specific and possibly restrictive IPR claims, further
increasing your obligation to make disclosures as required by
BCP 78.   I am not a lawyer, I would certainly not be
representing you if I were, this is not legal advice, and you
need to consult your own patent counsel on the subject, but
there is some history that introducing something into a
standards body without meeting its IPR disclosure requirements
can render the patent unenforceable. 

I also observe that the "Note Well" to which you agreed when you
joined this list digs you deeper into that problem with regard
to both documents with every posting to the list.  My
recollection is that your use of an "army.mil" address for these
discussions creates some further complications in that regard,
but those are issues that are best discussed with your attorney
and/or commanding officer.
 
I think that it is past the appropriate time for you to make the
relevant BCP 79 disclosures about this material and that you are
now seriously overdue, that you need to be much more clear about
your intentions along the dimension that stretches from
"proprietary protocol or product" to "intended standard", that
you either get the "Mail Markup Language" draft properly posted
as an I-D or stop pulling it into these discussions, and/or that
you take the discussion elsewhere.

     john

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Date: Thu, 13 Aug 2009 12:42:08 +0400
Subject: Re: [AKO Warning - Message fails DKIM verification] Re: [AKO Warning - Message fails DKIM verification] Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Hector,

> For people who have been in the mail business for a very long time,
> that is a pretty broad claim.

It is a broad claim.  I have seen several different attempts at creating
a markup language for email, but none that fully function and support
the complexity of SMTP protocol compared to the simplicity of the HTTP
protocol.  Such support would require conventions in an document capable
of supporting multiple various authors uniquely such as an email thread
without data cross-contamination from multiple contributions upon that
document.  SGML/XML do not provide this capability.

When I was searching for prior art I found attempts at creating markup
languages that made some progress towards defining content, but rarely
did they make any attempt to absorb RFC 5322 definitions into structures
represented by their language.  I never saw any of these prior arts
solve the problem of the prior paragraph.  Most of the concepts
represented of my language are not original, even the name of the
language is not original, but still I had never seen anything that
provided the benfits of markup to represent all currently practiced
user-agent conventions of email.

So while there have been attempts at creating markup language for email
in the past none were either functional or solved the complexity of
challenges represented by email that do not exist for the web.  That
does not mean my language is the best for the job, and I have never
claimed that it is.  Until something else comes along with its own
unique solutions to common practices the language I wrote is the only
thing I would refer to as a full markup language for email where all the
prior attempts I have seen do not do the full job of the task.

The only one thing I am absolutely certain about is that there is no
standard for describing content in email.  The closest such thing is a
suggestive statement from RFC 822, which suggests that content be 7bit
ANSI characters like the rest of the document.  There is certainly no
standard for use of whitespace definitions for visually preformatting
content in emails for processing to user-agents, no standard for shoving
HTML into an email, no markup language standard, or anything else.  I do
feel fairly confident that if there were a fully functional markup
language that it would have some appeal commerically and so its
existance would be commonly evident even if not in use.

>From these conclusions and the hundreds of hours I spent doing research
over the more than 18 months I took to actually write the language I
feel pretty confident when I say my language is the first markup
language for email.  I may honestly be wrong this statement, but I don't
think so.  My language may not be the best choice for its job, but at
the moment its the only choice.  I would say if my language is of poor
quality or fails at its job then pick another, but nobody else has
volunteered their own personal time away from work or family to write
such a thing.  I don't believe my language should rest as the only one
of its kind and I hope that I may see some alternatives.  It is only
from competing alternatives that I may truly know how flawed my attempt
is.

> A JSON format could be considered more optimized for wire-data, and
> this does exist and done after a XML version was tested and pushed
> aside.

JSON is not a markup language or peer to XML, although a famed
client-side evangelist I know of commonly claims otherwise.  JSON is a
serialized data storage mechanism and nothing more.  XML is a
meta-language, which is a language for creating languages.  XML is
commonly misused to act as a human readable data storage mechanism, but
in my opinion that is a gross abuse of the technology in complete
defiance of its purpose.  JSON is not competition for XML and people who
evangelize such likely do not understand what XML is.  JSON is in
competition with comma separated value format, but not XML.  As a result
it is a poorly informed response to a bad practice that allows for this
reasoning of interchangability of JSON for XML.

> In short, there is nothing new here.

You may be entirely correct.  The language I created does contain some
patent pending features, so perhaps in three to five years after the
US Patent and Trademark office concludes an investigation we will know
for sure.

Thank you,
Austin

Date: Thu, 13 Aug 2009 02:50:50 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC:  [email-masked]
Subject: Re: [AKO Warning - Message fails DKIM verification] Re: [AKO Warning - Message fails DKIM verification] Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Cheney, Edward A SSG RES USAR USARC wrote:

 > John,
 >
 > I have already written the only  known markup language for email
 > and defined a programmatic object in this specification.

For people who have been in the mail business for a very long time, 
that is a pretty broad claim.  At best, you have a specific mail 
markup language probably based on XML, but certainly there is existing 
prior art (like our system). Markus Analysis guidelines applies so 
there could not be any new claims against existing practices (prior 
art).

There are a variety of mail representations. Including XML based, 
there are other forms as well.  A JSON format could be considered more 
optimized for wire-data, and this does exist and done after a XML 
version was tested and pushed aside.

In short, there is nothing new here.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 13 Aug 2009 01:21:12 -0400 (EDT)
From: John R Levine <[email-masked]>
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
cc: IETF SMTP list <[email-masked]>
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Cleverness: None detected
Sender: [email-masked]

> Would you be so kind as to let me know what sort of specific prototype
> you would like?

Enough to show that it actually works, so you can get some user experience 
and see how well it works in real life, particularly exchanging mail with 
other people.

> All prior similar specifications began as definitions on paper before a 
> single piece of code was ever compiled, except for the transmission of 
> the first email.

I don't think you'll win many friends here with counterfactual claims 
about the history of the Internet.  Do read RFC 4677, which should be 
mandatory for anyone interested in the IETF.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: John Levine <[email-masked]>
Cc: [email-masked]
Date: Thu, 13 Aug 2009 08:21:36 +0400
Subject: Re: [AKO Warning - Message fails DKIM verification] Re: [AKO Warning - Message fails DKIM verification] Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

John,

Would you be so kind as to let me know what sort of specific prototype
you would like?  I have already written the only known markup language
for email and defined a programmatic object in this specification.
Would you like me to build that programmatic object into a piece of
language specific function?  Or would you like me to rebuild how modern
commerical email servers interpret requests?  The only new code required
by this specification has already been created.  The point of this
proposition is a model of transport and response.  All prior similar
specifications began as definitions on paper before a single piece of
code was ever compiled, except for the transmission of the first email.

This is so extremely reliant upon RFC 5321 and RFC 5598 there is nothing
new to demo that I have not already defined.

Thanks,
Austin

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: Willie Gillespie <[email-masked]>
Cc: [email-masked]
Date: Thu, 13 Aug 2009 08:11:54 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Willie,

> In my limited understand, SMTP is a store-and-forward protocol.  Will
> this affect your proposal?  I imagine it would not be pleasing to
> click on something you expect to be interactive and have it respond 4
> hours later.  Maybe I should go read your draft more thoroughly --
> you probably already thought of this.

It is certainly possible an interactive reply from a distant mail server
could take 4 hours so liberal a time to live were allowed.  I don't see
that as being common, however.  I want to say that 10 - 15 years ago
something like this would have been more than the norm than the
exception.  Today, however, many servers on the application layer of the
transmission stack, whether they be web, email, or other, typically sit
on high bandwidth networks connected to other high bandwidth network.

In my case specifically I am currently in Afghanistan, which is perhaps
an isolated communication point for communications that live mostly in
the United States.  Dispite the probably delays associated with my
isolation and distance my response to and from other email servers
appears instantaneous.  If I misstype the user name portion of an email
address and send the email I will have a reply from the distant server
about no such address almost instantly.  This is dispite being limited
to a 128kbit connection.  If in my extreme condition bandwidth is not an
issue then I fail to see how such an issue could be common enough to
provide any real service problems.

Further to the point the dynamic responses detailed in the specification
would represent fragments of a document and not a full communication, so
large amounts of bandwidth would only be consumed at the initiation and
not in the interaction.  This should be equivocal to the bandwidth
demands of a XMLHttpResponse on the web.

Does this answer your question?

Thanks,
Austin

Date: Wed, 12 Aug 2009 20:43:59 -0600
From: Willie Gillespie <[email-masked]>
Organization: Engineering System Solutions
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

In my limited understand, SMTP is a store-and-forward protocol.  Will 
this affect your proposal?  I imagine it would not be pleasing to click 
on something you expect to be interactive and have it respond 4 hours 
later.  Maybe I should go read your draft more thoroughly -- you 
probably already thought of this.

Willie

Cheney, Edward A SSG RES USAR USARC wrote:
> I am requesting comments on the following this internet draft.  Any questions, confusion, feedback, or changes would be helpful.
> 
> http://tools.ietf.org/id/draft-cheney-safe-02.txt
> 
> Thank you,
> Austin Cheney
> 

Date: 13 Aug 2009 00:40:17 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: [AKO Warning - Message fails DKIM verification] Re: Requesting comments on draft-cheney-safe-02.txt
Organization: 
Cc: [email-masked]
Sender: [email-masked]

>> What they're saying (and I agree) is that the solution you've come up
>> with is unlikely to gain much attention -- or implementation.

>Specifically, why?  How is that a technology concern for a standards
>body?

Standards development is very labor intensive, and most of the people
who do IETF standards are volunteers working in our spare time.  We
don't have enough volunteer time to update the standards already in
global use, much less to invent new ones, and it just isn't a sensible
use of limited resources to work on stuff that's not likely to be
used.

You will also find that proposals that have working implementations,
at least as prototypes, get a lot more respect than purely paper
designs.  (We have an unlimited supply of those, see for example the
endless e-postage proposals in the ASRG and elsewhere.)  If you think
your plan is workable, get some people to implement it and see how
it works.

R's,
John

PS: If this seems to give an unfair advantage to people with software
development skills, I think that's deliberate.

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Cc: [email-masked]
Date: Thu, 13 Aug 2009 03:06:59 +0400
Subject: Re: [AKO Warning - Message fails DKIM verification] Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Mr. Falk,

> What they're saying (and I agree) is that the solution you've come up
> with is unlikely to gain much attention -- or implementation.

Specifically, why?  How is that a technology concern for a standards
body?  The potential business failures of my proposal are entirely
separate from the relevance, accuracy, and functionality of the
technology.  If from only a technology perspective this feature is as
sound as I claim it is and as beyond argument as it so far appears what
is the justification in not adopting it as an RFC?

> The economics of this suggested solution aren't at issue.

If that were the case this discussion would not have so completely
devolved from technology considerations to business opinions.  If we can
all contend the current state of technology security failure on the web
an alternative method is qualified.  If that means the economics are not
at issue then there is no further discussion for business consideration
of the proposal at this time.

If this proposal survives all technology and related protocol criticism
I will assume all business failure for its lack of implementation.  At
that point the IETF has every reason to make it an RFC and every reason
not to make it an internet standard.  That is not a problem of this
moment.  It is a brige I will cross when I come to it.  All I need now
is criticism against the technology merits of the proposal.  Each of
your business opinions completely fall outside the field of discussion.

These are the only topics that must be considered.  All others should
be ignored.

Does this thing do all that it says?  Does this thing accomplish its
intended objective to the full extent that it claims? Is the language of
the proposal ambiguous or invite differences of interpretation?  Is the
language diffecult to understand or unclear to read?  Does this thing
make flawed assumptions about other technologies, specifications, or
features external to it?  Does this proposal invite unexpected
collisions from other specifications or protocols?  What are the
technology challenges to this thing?

When a failure of the technology or language is identified I will
correct it until no problems exist or until the technology is
demonstrated to be in uncorrectable conflict, failure, or disarray.

Thanks,
Austin

Date: Wed, 12 Aug 2009 14:18:06 -0600
From: "J.D. Falk" <[email-masked]>
To: [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Cheney, Edward A SSG RES USAR USARC wrote:

> Just out of curiousity how much is event oriented execution worth to
> you?

The economics of this suggested solution aren't at issue.

I don't think anyone is saying that the security issues you've mentioned are 
not issues, or that your idea wouldn't work if the internet adopted it 
overnight.  What they're saying (and I agree) is that the solution you've 
come up with is unlikely to gain much attention -- or implementation.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: Rich Kulawiec <[email-masked]>, [email-masked]
Date: Wed, 12 Aug 2009 09:47:45 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Hector,

> Honestly I have been confused with your usage of the term "email."

When I use the term email I am describing SMTP protocol reliant data
intended for consumption by humans that has an end point at a
destination specified by an email address.

Since this proposition is inherently SMTP focused I do not see how it
could be applied to a radically different protocol, such as HTTP.

> You honestly think the javascript 'prototype" API authors are going to
> get an act of conscious and ponder "You know, what I am doing is bad?"
> or the implementators are going to forgot using these methods?

No, I don't, which is all the more motivation to adopt this proposition.
>From a security perspective the web is a failure.  That should be more
reason, and not less reason, to support this attempt at providing a
secure alternative.  Please read these white papers to see how much of a
failure it is and why an alternative to client-side scripting is the
only acceptable solution:

Symantec Internet Security Threat Report - Trends 2008
http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_internet_security_threat_report_xiv_04-2009.en-us.pdf

Symantec - Web Based Attacks
http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_web_based_attacks_03-2009.en-us.pdf

In considertaion for how Symantec describes the method and deployment of
malware infections unto user's computers from legitimate websites it is
evident there is no secure form of client-side scripting if the
legitimate website cannot be trusted.

> We are a CCR contractor (and the feds use we what we have, its
> flexible) and in the past, was a military (sub) contractor and yuo kow
> what is done for the feds can be much different (requirements) than
> what was done for commercialization. Apples and Oranges really.

The disparity here is in the cost of alteration versus the quantity of
deployment.  Costs to provide disparite systems to the government vary
significantly with regards to total quantity of the products produced by
the vender in ratio to the total commerical products.  For something as
minor as an enhanced security footprint in Microsoft Windows' registry
versus the number of licenses sold to the military it might be cheaper
for Microsoft to make the change universal than to provide an alternate
form of product licensing for such a significant number of licenses.
For a subcontract that produces cutting edge materials in the assembly
of a Navy submarine's nuclear reactor the model of business would vary
drastically, because of the uniquness of the product and the scarce
quantity of total products produced.

> I'm just giving my opinion - prohibiting DOM events is a major show
> stopper.

The current state of security failure on the web is a bigger show
stopper.  After reading the mentioned whitepapers about how easy it is
to steal bank account information from the user, not the bank, accessing
a legitamite bank website I cannot possibly see how executive of events
bears a greater commercial value to either business of the end user.  In
2008 the average cost per breach incident in the US was $6.7 million
with an additional $4.6 million in lost revenue.  So a single breach
incident on a legitimate commerical website that intends to active code
on a user machine costs the business $11.3 million.  How much more than
that can event execution possibly be worth to a business?

> People won't bother to read past the abstract or the first
> few pages (Why Bother?).

Because the web is a security failure and security is expensive.  The
internet is not free and there is a cost to doing business.  How
expesive must that cost become before failure results?

> But the trend is more WEB 2.0+ and you are seeing sites that won't a)
> function and display a notice or b) don't care to explain why its not
> working.

That is only partially true.  It is true that many websites, including
my primary employer Travelocity, is entirely reliance upon client-side
scripting.  To email however client-side scripting has never been
considered and does not exist.  People will not miss what they never
had.  By implementing this proposal a foundation exists by which online
applications exist in an entirely different model than previously
conceived.  Since this is a new face to online applications there will
be new and completely different expectations of what an application
should be and should not be.  This difference will influence the
characteristics of development in a fashion that does not miss
client-side scripting if it is never a capability in the first place.
That will provide a point of transition for business migrate from
existing methods towards something like interactive email.

> Using parato's principle, 80% of the user market, today, won't have a
> clue about any of this.

At this moment I am not concerned about the understandability of the
current market.  I am only concerned with the understandability of
persons reading the ietf-smtp mailing list.  If this can become an RFC
it will bear the credibility that will encourage people to understand
this proposition.

> I said that because you are seeing very popular  sites not function at
> all without javascript.

I am also seeing a rising problem that limits or prevents business.  A
problem that has no other solution.  It is more important to a business
that they continue to sell products online than requiring those sells
come from a website that is easily open to compromise.

> I doubt they are going to alter their strategy for SAFE "Prohibitive
> NO-DOM Policy Mandates."

They will be economically motivated if they cannot otherwise not afford
to continue doing business on the web.

> So nothing else matters.

The cost of doing business and the cost providing the internet as a
service are all that matter in this case.  If the web fails then
internet standards fail, because this is a technology problem and not a
problem of carelessness.

> But considering SMTP, I think overall, what you are asking would be
> including a "major revamp"

In hardware and bandwidth, yes.  In protocol support no.  This
proposition is an entirely unobtrusive plugin to the SMTP protocol.  It
requires the use of a markup language, which is only a user-agent and
not a protocol concern.  If a markup language for email is not present
then SAFE is completely ignored.  As far a SMTP server the new software
enhancements would operate much like how PHP operates with Apache.
Apache does not care that PHP is installed.  Likewise SMTP services
direct and respond to traffic completely without care that something
else on the same box is modifing that traffic.  As a result SAFE would
not impact SMTP server services.  A bigger impact to those SMTP services
would result in adapting the requirements of a markup language header
that would very likely compete with or obsolete RFC 5322 header
definitions.

> In short, SMTP is not an optimal prootocol for this need.

SMTP is the ideal protocol for this need.  It is robust, bidirectional,
universally supported, and perhaps the most adopted communications
medium in all history.  SMTP has sufficient capabilities to exceed the
requests of this proposal.

> Maybe I say that because I can not AVOID the idea the DOM is
> prohibitive.

This proposal actively supports manipulation of the DOM at the
user-agent and even provides new capabilities to accomplish such.  It
only prevents execution of programmatic decisions from within a
communication or referenced by a communication.

Just out of curiousity how much is event oriented execution worth to
you?  Is it worth $11.3 million US per breach indicident?  Perhaps that
is an acceptable cost of doing business, but if so how would you account
for those loses?  Would you raise prices on the end user, liquify the
value of your product, or simply take a smaller pay check?  Each of
those sound horribly more distateful than considering a newer and
fresher way of doing business.

Thanks,
Austin

Date: Sat, 08 Aug 2009 22:43:42 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: Rich Kulawiec <[email-masked]>, [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Cheney, Edward A SSG RES USAR USARC wrote:

>> But what about market forces?
> 
> You must be more specific.  Are you suggesting negative impacts to a
> commercial market will drive users to take more efforts to protect
> themselves from vulnerabilities associated with technology?  

No, the opposite, the vendors are hiding the options (to disable) and 
are managing it themselves.  Only the savy is capable of understanding 
what is possible.

>> Do you realize we have a 15 year old that is among the decision
>> makers in how FireFox and Javascript is evolving?
> 
> By the way, JQuery founder and developer lead, John Resig, is 25.
> JQuery is a framework of JavaScript, and so it must be considered no
> less flawed than JavaScript from a security and deployment
> consideration.

My keyboad is flawed (not use to my new keyboard). :-)

> 
>> What I have trouble seeing is how SMTP will help.
> 
> The objective is to remove client-side scripting from a client-side
> user-agent regardless of that user-agent being associated with email or
> the web.  

Honestly I have been confused with your usage of the term "email."

Are you concern with WEB-based EMAIL applications?  Or in general web 
activity?

> In my opinion people, generally, do not take security seriously.  

Today's generation don't even know they are suppose to.

>> You are not going to stop DOM events, or even get people to consider
>> not using it. So if that is a major part of SAFE, you already have a
>> major road block in getting people interested in SAFE.
> 
> I disagree.  

You honestly think the javascript 'prototype" API authors are going to 
get an act of conscious and ponder "You know, what I am doing is bad?" 
or the implementators are going to forgot using these methods? 
Microsoft just officially recently announced jQuery as a supported 
product for their .NET framework for client side "aura" enhancements.

> From solely a business perspective security mitigation is
> expensive.  I believe if an alternative to such problems does exist that
> there would be support for adoption from large organizations to curtail
> security associated expenditures.  Large volume organizations direct the
> strategic course of software development more any other single markup
> force.  One of my employers is the United States military, which is one
> of the largest employers on the planet.  I have seen how all sizes of
> software vendors have completely revised altered their product
> strategies to prevent loss of contracts from this single client. 

We are a CCR contractor (and the feds use we what we have, its 
flexible) and in the past, was a military (sub) contractor and yuo kow 
what is done for the feds can be much different (requirements) than 
what was done for commercialization. Apples and Oranges really.

I'm just giving my opinion - prohibiting DOM events is a major show 
stopper. People won't bother to read past the abstract or the first 
few pages (Why Bother?).  Now that doesn't mean that some vendors are 
still considerate of WEB 1.0 and will offer product that work outside 
of javascript.  But the trend is more WEB 2.0+ and you are seeing 
sites that won't a) function and display a notice or b) don't care to 
explain why its not working.

Using parato's principle, 80% of the user market, today, won't have a 
clue about any of this. I said that because you are seeing very 
popular  sites not function at all without javascript. I doubt they 
are going to alter their strategy for SAFE "Prohibitive NO-DOM Policy 
Mandates."

>> Never mind the technical issues related to a SMTP callback system
>> especially one that will be based on HTTP huge redundancy in HTTP
>> requests.
> 
> I did not understand this final statement.  Could you please clarify
> this for me?  The SAFE model is based solely upon SMTP and references no
> features of HTTP.

Like I said, prohibiting DOM events is a show stopper for your SAFE 
proposal -  for me, and I 100% believe others who's survival and/or 
product offering is based on DOM, will agreed.  So nothing else matters.

But considering SMTP, I think overall, what you are asking would be 
including a "major revamp" - lots of software changes, so therefore 
whenever there is big changes it opens the door to evaluating a better 
solution - like a optimized client/server handshaking protocol 
specifically for this purpose.  In short, SMTP is not an optimal 
prootocol for this need.  Maybe I say that because I can not AVOID the 
idea the DOM is prohibitive.  This all sort of reminds me of the 
differences between (batch) job thinkers versus dynamic asynchrous UI 
thinkers - the latter is prevailing and can not be avoided.

-- 
Sincerely

Hector Santos
http://www.santronics.com

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: Rich Kulawiec <[email-masked]>, [email-masked]
Date: Sun, 09 Aug 2009 00:59:14 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Hector,

Before I begin I want to say any remarks or opinions towards or about
commercial media plugin software is entirely personal and hypothetical.
Issues associated with such software, even issues of a security nature,
are issues respective of a markup language, or other containing feature.
The impacts and concerns of such software is not related to or relevant
to the SAFE method until communication from such software perform in a
manner that violates the privacy inherently presumed of email.  At such
a point such concerns become a matter of civil liability associated with
unsatisfactory disclosure of private communications.

> But what about market forces?

You must be more specific.  Are you suggesting negative impacts to a
commercial market will drive users to take more efforts to protect
themselves from vulnerabilities associated with technology?  If so, I am
not aware of any such research, and generally security vulnerabilities
tend to dramatically increase during down economies.

> All of these players (including Apple, Google, AT&T, ComCast and so
> on) have a major strategy to add MORE background communications in
> their designs to "network" users and also build their BI for added
> value services (direct marketing, social networking).

We must remember media plugins of the type you list are created entirely
for the web.  The web is inherently public as a medium of communication
while email is inherently private.  This alone would present some minor
alterations to product strategy and deployment for such software in
order negate civil suits regarding breaches of privacy in email, where
such privacy concerns are significantly diminished on the web.

The extremely positive thing about proprietary media plugins is that
they are managed commercial software.  This means the owner of such
software is responsible for owning maintenance upon the software, which
includes security patches.  While this does nothing to protect a user
from zero-day exploits, it does however provide a means by which a
security resolution to a specific application flaw that is rapidly
produced and distributed.  Because the owner of the proprietary software
is potentially liable for harms inflicted by their software, where those
harms not an expectation of user interaction or execution, dire
commercial motive exists to ensure the software vendors resolve
publicized vulnerabilities as rapidly as possible.

> I know of only of WMP and Flash having domain whitelist for cross
> domains xtalk.

Since email is inherently private the content of a media plugin MUST
never communicate to a third party, even if that third party is the
software vendor owning the plugin.  Since email is inherently private
both parties must consent to the release of communications to the public
realm before such release deemed appropriate for automated
consideration.  It is potentially possible there could be some legal
remedies to prematurely escape the requirement of dual publication
authorization, but I will presume from a standards perspective that such
remedies do not and may not ever exist.

I, however, do not have a problem with media plugin software beaconing
out to its owner when that communication is entirely content independent
and does not report any information that can be regarded as private or
publicly identifiable information.  If a plugin software wishes to
report anonymous usage statistics to its owner such communication MUST
be communicated to the end user and agreed upon by that end user prior
to installation.  The plugin software MUST communicate, to the user, all
domains it will communicate to prior to installation.

> Do you realize we have a 15 year old that is among the decision
> makers in how FireFox and Javascript is evolving?

Since Firefox is a proprietary software.  By proprietary software I mean
that it is owned by even if it is licensed as open source.  Owners are
free to make what ever strategy decisions they wish upon their software
products.  Owners of software, even if that software is open source, are
still liable for harms and exploitations that occur as a result of that
software.  In other words there is nothing to prevent Mozilla from being
named in a law suit than Microsoft for product violations or
irresponsible executive decisions.

By the way, JQuery founder and developer lead, John Resig, is 25.
JQuery is a framework of JavaScript, and so it must be considered no
less flawed than JavaScript from a security and deployment
consideration.

> What I have trouble seeing is how SMTP will help.

The objective is to remove client-side scripting from a client-side
user-agent regardless of that user-agent being associated with email or
the web.  The simple answer is to simply turn off all JavaScript,
ActiveX, and so forth from all versions of all browsers permanently.
That is an impossible decision for the web completely reliate upon
client-side scripting.  An alternative must exist before reliance upon
client-side scripting from the web can be scaled back or eliminated.
The SAFE Scripting Method is an attempt to provide a degree of
interaction and processing to communications before that communication
is received by its intended destination and without that interaction
executing at a user-agent.

In my opinion people, generally, do not take security seriously.  Asking
people to turn off client-side scripting on their own accord is not
acceptable since the end user cannot be expected to be aware of the
impacts of technology decisions.  The software vendors are not willing
to reduce or exclude client-side scripting in any manner significant
enough to even reduce the accelerating growth rate of associated
vulnerabilities, because the value of market share is limited to a few
software vendors even if the negative impacts associated with that
software are a cost burden to us all.

As far as I am aware nobody else has presented an interactive solution
to the harms of client-side scripting and nobody else has presented a
non-proprietary alternative.  That does not mean my attempt at such an
alternative is without points of disagreement or limitation, but it is
substantially more secure than anything else so far proposed.  Since
this is the only suggestion to cure, opposed to mitigate, the problem it
is worthy of consideration unless its proposed technology is flawed or
ineffective to its intended objective.

>   - Some authorization protocol using SMTP (i think), that
>     is coupled with,
>
>   - Prohibition of existing Interactive methods, i.e. DOM
>     events.
>
> I don't see how the two is related or why DOM events can no longer be
> used.

The second point that you mentioned is the solution to the problem.  The
first point is an alternative to the elimination of concept represented
by the second point.  A standard is only retains value if it is adhered
to by its concerned parties.  My fear in allowing execution of events at
the user-agent is that you are only the smallest step away from allowing
all forms of execution.  I believe that if a hard and fast limitation is
not set that first users and then software vendors will make every
possible attempt to allow as much interactivity as possible locally with
exception to constraints upon transmission.  At that point the standard
has absolutely no value and Email because just as vulnerable, if not
more, than the web.  At this moment email is pristine and pure from many
of the problems associated with the web, and I don't want to be the one
violate that sanctity.

> You are not going to stop DOM events, or even get people to consider
> not using it. So if that is a major part of SAFE, you already have a
> major road block in getting people interested in SAFE.

I disagree.  From solely a business perspective security mitigation is
expensive.  I believe if an alternative to such problems does exist that
there would be support for adoption from large organizations to curtail
security associated expenditures.  Large volume organizations direct the
strategic course of software development more any other single markup
force.  One of my employers is the United States military, which is one
of the largest employers on the planet.  I have seen how all sizes of
software vendors have completely revised altered their product
strategies to prevent loss of contracts from this single client.  There
are other single clients that carry almost as much market clout as well.
If only a very small few of such parties can be convinced to adopt this
methodology the path for adoption is set with a potential for adoption
growth.

> Never mind the technical issues related to a SMTP callback system
> especially one that will be based on HTTP huge redundancy in HTTP
> requests.

I did not understand this final statement.  Could you please clarify
this for me?  The SAFE model is based solely upon SMTP and references no
features of HTTP.

Thank you,
Austin

Date: Sat, 08 Aug 2009 11:48:24 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: Rich Kulawiec <[email-masked]>, [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Cheney, Edward A SSG RES USAR USARC wrote:

> Rich,
> 
> Users can only be protected from themselves through adherance to
> policies, procedures, and relevant training.  That is leadership
> solution and not a technology solution.  Protecting user from themselves
> does not solve exploitable weaknesses in technology.  In these cases you
> have to simply fix the technology to disallow exploitation.  If this
> were not so software companies would not spend millions of dollars to
> continually patch their products if administrators and management could
> so easily retrain their users.

But what about market forces?

One of your concerns is embedded software backend communications, i.e. 
cross domain xtalk unbeknowst to the users with embedded plugins like 
the following:

     - Flash
     - Quicktime
     - Real Player
     - Silverlight
     - Windows Media Player (WMP)

All of these players (including Apple, Google, AT&T, ComCast and so 
on) have a major strategy to add MORE background communications in 
their designs to "network" users and also build their BI for added 
value services (direct marketing, social networking).

AJAX is been relaxed for cross domain requests as well as IE already 
allows with user authorization.

I know of only of WMP and Flash having domain whitelist for cross 
domains xtalk.  That is one of the big features in Flash 9.

I understand what you mean.  Do you realize we have a 15 year old that 
is among the decision makers in how FireFox and Javascript is 
evolving?  He is also the author of jQuery. Its scary to see this guy 
in action exhibiting lack of social ethical engineering understanding 
at times. I tried to provide some insight about all this - beware of 
what you wanting to do.

But its really too late.

What I have trouble seeing is how SMTP will help.  But you have two parts:

    - Some authorization protocol using SMTP (i think), that
      is coupled with,

    - Prohibition of existing Interactive methods, i.e. DOM
      events.

I don't see how the two is related or why DOM events can no longer be 
used.

You are not going to stop DOM events, or even get people to consider 
not using it. So if that is a major part of SAFE, you already have a 
major road block in getting people interested in SAFE. Never mind the 
technical issues related to a SMTP callback system especially one that 
will be based on HTTP huge redundancy in HTTP requests.

-- 
Sincerely

Hector Santos
http://www.santronics.com

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: Rich Kulawiec <[email-masked]>, [email-masked]
Date: Sat, 08 Aug 2009 09:16:49 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

John,

In addition to my reply to Rich I want to address the cost of doing
business with regard to security mitigation.

For a moment I would like to jump to another more email centric example:
SPAM.  SPAM can be easily mitigated using the latest email server
software and performing the best current procedures to minimize the
impact of SPAM upon an organizations systems and users.  Even after all
possible efforts are considered SPAM can still get through.  If SPAM
does not get through it still consumes bandwidth across networking
devices and bandwidth on the email server.  SPAM mitigation costs CPU
cycles on email servers that could be used for other more productive
tasks.  Those wasted CPU cycles increase load, which is a management
concern for server load balancing and power distribution costs in a
server farm.

No matter what we do and even if no SPAM gets through to the end user
the administrator has still spent time, money, and resources to defend
their network.  From the perspective of a project manager or a business
owner that is funding that could be invested to grow the business if not
wasted on mitigation.  That is additional personnel and equipment that
could be retasked to perform other operations to make the organization
more productive and competitive.  At the end of the day the final
business result is additional costs.

Security vulnerabilities, much like SPAM, are a high cost and a drain on
any organization.  Even if mitigation completely eliminated 100% of the
problem 100% of the time it still comes at a cost, a cost that is
unnecessary if those vulernabilities were eliminated.

If I were a key decision maker in the investment of business assets
across a large organization I would want to eliminate costs to the
business as much as possible.  If there are positive benefits associated
with, but not directly related to, those cost savings that is simply an
unintended business benefit even if the technology benefits are
intentional.

In summary, after all technology decisions and impacts are considered at
the end of the process will this result in a savings to business.  I
believe it will result in an astounding cost savings if a significant
majority of reported vulnerabilities could be either eliminated or
substantially reduced.

Thank you,
Austin

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: Rich Kulawiec <[email-masked]>
Cc: [email-masked]
Date: Sat, 08 Aug 2009 08:33:45 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Rich,

I do wish to be clear that when I say most significant I mean that
purely in a quantitative and not a qualitative manner.  Vulernabilities
associated with client-side scripting are certainly not the most harmful
forms of security intrusion.

> These are (a) web browser and (b) operating system vulnerabilities,
> and are quite readily mitigated by making sensible choices about both.

I draw a solid distinction between mitigation and solution.  A
mitigation is a proactive action to ensure systems or data in your area
of responsibility are protected against security breaches from both
internal and external users.  That is an attempt to avoid the problem,
and it is not a solution to the problem.  A solution is a recommendation
that intends to eliminate the problem, which thereby reduces the scope
of mitigation in a given security assessment.  In other words, if
actions to a system were really a solution to client-side security
vulnerabilities then those security flaws must never again occur upon
that system, correct?

> If, on the other hand, poor choices of web browser and/or operating
> system (or mail client, for that matter) are made, then it really
> doesn't matter whether traffic moves via HTTP or SMTP or anything
> else: those systems WILL be compromised.

Users can only be protected from themselves through adherance to
policies, procedures, and relevant training.  That is leadership
solution and not a technology solution.  Protecting user from themselves
does not solve exploitable weaknesses in technology.  In these cases you
have to simply fix the technology to disallow exploitation.  If this
were not so software companies would not spend millions of dollars to
continually patch their products if administrators and management could
so easily retrain their users.

Thank you,
Austin

Date: Fri, 07 Aug 2009 18:10:27 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Rich Kulawiec <[email-masked]>
CC:  [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

+1

Rich Kulawiec wrote:

> On Fri, Jul 31, 2009 at 02:36:31AM +0400, Cheney, Edward A SSG RES USAR USARC wrote:
>> The idea is that security vulnerabilities on the internet occur
>> most significantly as a result of client-side scripting from documents
>> transmitted across HTTP.
> 
> Even we grant for the purpose of argument that these are the "most
> significant", and I see no evidence that they are, these are not
> Internet security vulnerabilities.
> 
> These are (a) web browser and (b) operating system vulnerabilities,
> and are quite readily mitigated by making sensible choices about both.
> Further mitigation is possible by using in-band filtering/blocking
> (such as HTTP proxies which filter or block traffic) or by using
> browser extensions (e.g., NoScript).  These are much simpler and directed
> solutions that are available immediately, without any need for protocol
> engineering.
> 
> If, on the other hand, poor choices of web browser and/or operating system
> (or mail client, for that matter) are made, then it really doesn't matter
> whether traffic moves via HTTP or SMTP or anything else: those systems
> WILL be compromised.
> 
> ---Rsk
> 
> 
> 

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Fri, 07 Aug 2009 06:56:04 -0400
From: John C Klensin <[email-masked]>
To: Rich Kulawiec <[email-masked]>, [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

--On Friday, August 07, 2009 06:01 -0400 Rich Kulawiec
<[email-masked]> wrote:

> 
> On Fri, Jul 31, 2009 at 02:36:31AM +0400, Cheney, Edward A SSG
> RES USAR USARC wrote:
>> The idea is that security vulnerabilities on the internet
>> occur most significantly as a result of client-side scripting
>> from documents transmitted across HTTP.
> 
> Even we grant for the purpose of argument that these are the
> "most significant", and I see no evidence that they are, these
> are not Internet security vulnerabilities.
> 
> These are (a) web browser and (b) operating system
> vulnerabilities, and are quite readily mitigated by making
> sensible choices about both. Further mitigation is possible by
> using in-band filtering/blocking (such as HTTP proxies which
> filter or block traffic) or by using browser extensions (e.g.,
> NoScript).  These are much simpler and directed solutions that
> are available immediately, without any need for protocol
> engineering.
> 
> If, on the other hand, poor choices of web browser and/or
> operating system (or mail client, for that matter) are made,
> then it really doesn't matter whether traffic moves via HTTP
> or SMTP or anything else: those systems WILL be compromised.
>...
 
Reinforcing this point, I note that there are several MUAs that
interpret HTML in a very limited environment, preventing
execution of scripts, web bugs, etc., rather than
indiscriminately invoking full browsers each time an HTML
message comes in.  And, as Rich points out, those precautions do
not require protocol engineering, much less convincing those who
develop and send messages to adopt different tools and
procedures.

   john

Date: Fri, 7 Aug 2009 06:01:47 -0400
From: Rich Kulawiec <[email-masked]>
To: [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

On Fri, Jul 31, 2009 at 02:36:31AM +0400, Cheney, Edward A SSG RES USAR USARC wrote:
> The idea is that security vulnerabilities on the internet occur
> most significantly as a result of client-side scripting from documents
> transmitted across HTTP.

Even we grant for the purpose of argument that these are the "most
significant", and I see no evidence that they are, these are not
Internet security vulnerabilities.

These are (a) web browser and (b) operating system vulnerabilities,
and are quite readily mitigated by making sensible choices about both.
Further mitigation is possible by using in-band filtering/blocking
(such as HTTP proxies which filter or block traffic) or by using
browser extensions (e.g., NoScript).  These are much simpler and directed
solutions that are available immediately, without any need for protocol
engineering.

If, on the other hand, poor choices of web browser and/or operating system
(or mail client, for that matter) are made, then it really doesn't matter
whether traffic moves via HTTP or SMTP or anything else: those systems
WILL be compromised.

---Rsk

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: Steve Atkins <[email-masked]>
Cc: SMTP Interest Group <[email-masked]>
Date: Wed, 05 Aug 2009 06:45:27 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Steve,

There are two features of Mail Markup Language that are patent pending,
where that protection is owned by Travelocity.  The SAFE specification
includes a hypothetical example that references Mail Markup Language,
but does not reference any of the protected features in that example.
SAFE is language independent.  Since SAFE features nothing protected and
references nothing protected there is no complication that I am aware
of.  If a liberal enough licensing scheme is decieded upon for Mail
Markup Language I will submit it as a draft standard, otherwise it will
continue to be far removed from association with a standards body per
request of the property owner.

Thanks,
Austin

From: Steve Atkins <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Date: Tue, 4 Aug 2009 18:20:05 -0700
Sender: [email-masked]

On Aug 4, 2009, at 5:48 PM, Cheney, Edward A SSG RES USAR USARC wrote:

>
> The draft has been updated from version 2 to version 4 based upon  
> your suggestions.
> http://tools.ietf.org/html/draft-cheney-safe-04

Can you clarify the patent status? Your website says that Travelocity  
have
applied for patents on either this or something very closely connected  
to
it.

>
> Here are the diffs:
> Version 3: http://tools.ietf.org/rfcdiff?url2=draft-cheney-safe-03.txt
> Version 4: http://tools.ietf.org/rfcdiff?url2=draft-cheney-safe-04.txt
>
> Thank you so very much,
> Austin Cheney
>
> ----- Original Message -----
> From: <[email-masked]>
> Date: Thursday, July 30, 2009 22:50
> Subject: Requesting comments on draft-cheney-safe-02.txt
> To: [email-masked]
>
>
>> I am requesting comments on the following this internet draft.  Any
>> questions, confusion, feedback, or changes would be helpful.
>>
>> http://tools.ietf.org/id/draft-cheney-safe-02.txt
>>
>> Thank you,
>> Austin Cheney
>

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: [email-masked]
Date: Wed, 05 Aug 2009 04:48:24 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

The draft has been updated from version 2 to version 4 based upon your suggestions. 
http://tools.ietf.org/html/draft-cheney-safe-04

Here are the diffs:
Version 3: http://tools.ietf.org/rfcdiff?url2=draft-cheney-safe-03.txt
Version 4: http://tools.ietf.org/rfcdiff?url2=draft-cheney-safe-04.txt

Thank you so very much,
Austin Cheney

----- Original Message -----
From: <[email-masked]>
Date: Thursday, July 30, 2009 22:50
Subject: Requesting comments on draft-cheney-safe-02.txt
To: [email-masked]

> I am requesting comments on the following this internet draft.  Any 
> questions, confusion, feedback, or changes would be helpful.
> 
> http://tools.ietf.org/id/draft-cheney-safe-02.txt
> 
> Thank you,
> Austin Cheney

Date: Sun, 2 Aug 2009 23:10:06 -0400
To:  [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

At 13:03 -0600 on 08/02/2009, Willie Gillespie wrote about Re: 
Requesting comments on draft-cheney-safe-02.txt:

>I know of some large cable internet providers that block access to
>"external" SMTP servers by default -- but allow unauthenticated access
>to their SMTP server.  Will this be a problem?

I think that if you check again, they do not "block access to
'external' SMTP servers by default" but only block access to
'external' SMTP servers ON PORT25. IOW: If/When I access that 
external SMTP Server on Port587 (the RFC designated 
MSA/Mail-Submission-Agent Port that replaced use of Port25 a few 
years ago) or Port465 (the SMTP-over-SSL Port) they allow it. They 
only block/hijack Port25 Connections.

IOW: Have SAFE use a Non-Port25 Port and it will get through. The 
only problem with Ports 465 and 587 is that you either need to start 
a SSL session or do a Logon to access the server (if you follow the 
rules for those ports although you can have separate SAFE Server 
Farms which do not need to observe these rules so long as they do not 
act as MSA Servers).

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: Willie Gillespie <[email-masked]>
Cc: [email-masked]
Date: Mon, 03 Aug 2009 01:45:32 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Willie,

If external email servers are blocked there is no expectation that email
can be sent to addresses on different domains.  As far as addresses on
the same domain as the originating address the SAFE model should still
function correctly.

Thanks,
Austin

Date: Sun, 02 Aug 2009 13:03:51 -0600
From: Willie Gillespie <[email-masked]>
Organization: Engineering System Solutions
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

I know of some large cable internet providers that block access to 
"external" SMTP servers by default -- but allow unauthenticated access 
to their SMTP server.  Will this be a problem?

Willie

Cheney, Edward A SSG RES USAR USARC wrote:
> The idea is that security vulnerabilities on the internet occur most significantly as a result of client-side scripting from documents transmitted across HTTP.  By most significant I mean as measured by quantity and not severity.  In addition to frequent immediate vulernabilities client-side scripting can also operate as an execution point for other additional vulernabilities not directly associated with client-side scripting.  It is my opinion that the only way to solve this security problem is to either break HTTP or eliminate client-side scripting.  I find there is no reason to break HTTP since it is working perfectly well and is not to blame for this problem.  Client-side scripting cannot be removed unless an alternative convention is proposed.
> 
> It is absolutely imparitive that a solution exist as the quantity of these security problems are continually increasing and there is no possible solution available from HTTP.  If a solution is not proposed the security flaws of the system will become so significant that the commerical value of financial transactions and PII leaks will eventually result in abandoning the internet as an open platform in favor of more secure proprietary technologies.
> 
> As an alerternative method of allowing interactivity from client-side scripting I wrote this document to migrate the concept of client-side scripting to the email architecture.  The idea is that interactivity from client-side scripting can be replaced by transaction interactivity.  Since mail servers are intermediate agents in the transmission, opposed to an end point like an HTTP server, they can make processing or scripting decisions upon data without that scripting having to exist on a client system.  In other words, it is basically an inverted form of AJAX that does not execute on the client-side.  The idea is easily possible using SMTP, but is not possible over HTTP since HTTP does not have intermediate agents between the client and server.
> 
> Thanks,
> Austin
> 
> ----- Original Message -----
> From: "J.D. Falk" <[email-masked]>
> Date: Friday, July 31, 2009 1:44
> Subject: Re: Requesting comments on draft-cheney-safe-02.txt
> To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
> Cc: [email-masked]
> 
> 
>> Cheney, Edward A SSG RES USAR USARC wrote:
>>
>>> I am requesting comments on the following this internet draft.  Any
>>> questions, confusion, feedback, or changes would be helpful.
>>>
>>> http://tools.ietf.org/id/draft-cheney-safe-02.txt
>> Interesting idea.  What's the use case you have in mind?  In other 
>> words: 
>> who will use it, and why?
>>
>> -- 
>> J.D. Falk
>> Return Path Inc
>> http://www.returnpath.net/
> 

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: "J.D. Falk" <[email-masked]>, [email-masked]
Date: Sun, 02 Aug 2009 21:29:16 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Hector,

> Since this in the SMTP forum, FaceBook, for example, is one of the
> entities that believes all MAIL is own by them and can be used to
> extracting information about both parties. So does Google and yahoo,
> but FaceBook has raised and highlighted the issue of recent by
> questioning any the idea of user email privacy.

In my understanding the privacy of email is simultaneously and equally
owned by all named parties in the transaction.  This means Facebook and
Google can do with the email whatever they want so long as that data is
never transfered to a third party without the express consent of all
named users.  This is basically a subscription oriented business model
where a user voluntarily becomes party to a service and the vendor of
that collects data upon the user in an attempt to make the service more
fulfilling.  Netflix is an example of this exact model outside of email.

> Even then, IMV, even if it is considered that an alternative should be
> considered, it would be a major revamp and thus SHOULD open the door
> to a newer more efficient protocol. One where the state machine would
> be much simpler.   Maybe something like SIP or XMPP or SOAP.

Is this to say that SMTP is outdated and should be replaced by something
more open for scalability and performance?  If so, are you suggesting a
more modern protocol replace SMTP or provide assistance to SMTP?

> Both Microsoft and Adobe have newer client-side plug-ins that now
> offer  signed certificate authentication/authorization methods with
> their client-side "far calls."   So I don't think your draft will
> replace this part since it duplicates this resolution.

I do not claim to have produced anything new with regard to certificates
or digital signatures.  If a more efficient model for independent
identity validation does exist I will definately incorporate that in.

> For AJAX, the SAFE consideration would produce scalability and
> performance issues.  I envision many timeout design issues.

SAFE will introduce scalability problems for email, because it would
open email to considerably higher bandwidth consumption.  That
consumption would likely come at a cost from equal or greater reduction
in bandwidth from the web.  On a slow connection may web pages timeout,
because many sites take broadband connections for granted.  This is not
the fault of any technology, but poor development.  This is not a
technology problem for the web and I don't see such poor development
decisions equivocating to technology failure of extending email.

> SAFE restricting DOM events would be a major show stopper. Probably
> the single thing that would stop people from further consideration.

I completely agree, but still will not budge.  Allowing event execution
is a slippery slope that will only bring the security failures of the
web to email.  This is a security solution at a usability cost.  There
are only three possible choices to consider:

1) Concede the usability limitations of SAFE are acceptable to procede.
2) Propose a separate competing solution that is equally limited.
3) Do nothing and watch the result, which is technology failure.

What is more important to you: executing events or securing your data?

> The direction is MORE client side plug-ins, NOT LESS. Flash,
> SilverLight, APEX, Google Apps, Firefox Plug-ins are prime examples.

I agree with that as well.  The security flaws associated with code
executed by those plugins is owned by the author of those proprietary
plugins.  That typically results in fast and reliable patching at the
cost of the plugin's owner.

> There are quite a few client/server communication wirings. I don't see
> how we can use SMTP in the wiring here.

The document you provided looks like an elaborate dynamic AJAX
environment where a server-side application is independently accessing
the data store that the AJAX framework is either writing to or reading
from.  The SAFE model is perfectly capable of replicating this
functionality.  SAFE is essentially an inverted form of AJAX itself,
while traditional AJAX may occur on the server.  By traditional AJAX at
the mail server I mean that data can be dynamically written by an
application to a data store for use at a later time or use by a
different machine in the same domain.  There is no reason that the
XMLHttpRequest object cannot be used at the email server, except that it
cannot be used in accordance with SMTP.

I have already thought of this, but chose not to include it in the SAFE
concept.  First of all this is a processing elaboration not necessary
for transmission description.  Secondly, there are likely many different
ways to do this correctly that are dependent upon various unique
conditions.

> Introduce SAFE as a new PROXY or protocol that would be more of a plug
> and play solution.

I see SAFE as operating as an extension to prior existing SMTP service
implementations and not really a replacement.  The only additional
requirements of the mail server directly are support of the XMLSmtpPush
object and to respond only to the specific client.  The mail server
could even pass script processing to another machine as the scripting
sandbox so long as it is the server that sends the responces.

Thanks,
Austin

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: "Peter J. Holzer" <[email-masked]>
Cc: [email-masked]
Date: Sun, 02 Aug 2009 20:30:02 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Peter,

>> The problem only exists in the realm of HTTP due to where code
>> actually executes for interaction.  HTTP is certainly not part of the
>> problem, but it also cannot be a part of the solution due to the
>> simplicity of its design.
>
> What aspect of SMTP makes is superior to HTTP in this regard?

On the HTTP side interactive code MUST execute at the user-agent in
order to be interactive.  This is so because in HTTP resources are sent
to a user-agent for execution.  In SMTP the server is not a terminal
point in a transmission.  In SMTP processing upon a communication can
occur prior to that communication reaching its intended destintation and
that processing may include a response.  This feature is not possible in
HTTP since the server is always the destination.

>> The user-agent cannot even control if the code executes automatically
>> upon rendering of the page except to completely disable execution of
>> all client-side code.
>
> The last sentence is wrong (some browsers do implement ways to
> restrict client-side codes by different criteria), and in any case
> that doesn't seem to have anything to do with the protocol used to
> fetch the (executable) contents: Neither HTTP nor SMTP care about the
> contents, they just transport a header and a blob of data.

The only standard for limiting client-side execution is in preventing
execution or data access to a domain different than the resource that
requested it.  Such a limitation does not prevent client-side code from
execution, but merely limits the result of that execution where the
limitation is of concern.  So that in mind, my statement is still
technically accurate.  All client-side code will execute upon load of a
page or in accorance with an event unless execution of all client-side
code is disabled from the user-agent.

>>> What is gained by adding intermediate systems?
>> Intermediate systems offer a point of execution for code
>
> You are contradicting yourself:
>
>> 2) The server that owns the code is the exact point of execution for
>> that code.
>
> So the code is not executed on one of the intermediate systems but on
> the server which hosts the code. The intermediate systems just pass
> through messages.

If the server that hosts the code is an intermediate system then I have
not contradicted myself.  This is suggestion made in the internet draft.
SMTP servers are intermediate systems between the originating user-agent
and the destination address.

>> Technically speaking HTTP is also unidirectional.  HTTP typically
>> operates with a GET request
>
> The POST request is also well-known and frequently used.

Yes, but that is not the point.  Even with a GET request data can be
supplied back to the server by appending data to the query string of the
URI.  In that case and with POST instructions are being sent to the
server in expectation that a resource request is designated so that the
server may respond.  The actual protocol is behaving in a unidirectional
manner even if additional software supplied on the server can process
this additional data to add a perception of bidirectionality.  The
protocol itself does not care what data is supplied through such a
glorified GET or POST.  The protocol only cares about what resource to
send in response to a request.  The additional help supplied to the
protocol from server-side software certainly adds the perception of
bidirectional data processing but that is not a feature of the protocol.

As a result HTTP is definately unidirection and SMTP is bidirectional.
SMTP has an expectation of bidirectional data transfer in that error
messages generated from the server may be sent to the originating
address and destination address simultaneously.  SMTP can be
multidirectional provided this same simulation occurs where multiple
domains are immediately involved, such as a server sending the error
message to the originating address, destination address, and maintenance
address on a different domain.  Such multidirectional transmission is
not inherent to the proper function of the protocol, and the SAFE model
only requires bidirectional transmission.

> If you don't allow user-triggered events to be processed, what is the
> advantage compared to traditional server-side scripting?

on the web the server is the destination of the transmission.  Once data
is sent to the server its use is terminated unless it is resent to the
client.  In the SAFE model data can be interpreted prior to reaching the
destination more similar to client-side form validation using the
onsubmit event.

> As somebody else already asked: What would be a typical use case for
> your protocol?

The biggest difference between email and the web is that email is
inherently private and the web is inherently public.  The laws in The
United States reflect that observation.

The first example that comes to mind is ecommerce with a shopping cart,
form validation, suggested upselling, and personalized content and
preferences.  Since email is inherently private the user has a higher
expectation of confidentiality and the vender has greater freedom to
use data supplied by that user so long as the data is not transfered to
a third-party without express consent of both the user and the vendor.
Shopping is not a public venture, and so it has no reason to exist on
the web except that conventions do not yet exist for allowing shopping
on a private medium, such as email.

A second example is in consideration for adverting as a business on WWW.
Web sites that are entirely dependent upon traffic in order to generate
advertising revenue are operating under a failing business model.
Advertising costs have been steadily increasing while revenue returned
from those ads has been decreasing almost proportionally.  Web sites
that offer a targeted product or that feature a targeted audience are
not experiencing these declines.  For several years it has been believed
the only solution to this decline is targeted advertising.  Directly
targeting users' interests and surfing habits in an attempt to supply
relevant advertising has been ruled a privacy violation on the web in US
federal court.  In email, however, such targeting is perfectly legal so
long as the data collected is not transfered to a third party.  That is
an important consideration for adaptive business models even before
consideration for advertising.

If business solutions can be leveraged to use privately supplied data to
increase revenue such solutions would displace reliance upon advertising
as a primary consideration for revenue generation.

Thanks,
Austin

Date: Sun, 02 Aug 2009 11:13:20 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: "J.D. Falk" <[email-masked]>, [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Cheney, Edward A SSG RES USAR USARC wrote:

>> At the end of the day, either you allow the site to run as it was
>> designed if you want to be part of it, or just ignore it if you are
>> concern about its cross domain behavior.
> 
> Demeaning the user is not a technology solution.
> 

Unfortunately, ethical engineering considerations are no longer taught 
  to these "kids,"  too expensive, it hurts the brain! and is 
prohibitive these days.  The modus operandi is to DO IT first, and see 
where the chips fall. Any corrections would be an after thought.  Of 
course, by then it may be too late.  Triage and Pareto's Principles apply.

Since this in the SMTP forum, FaceBook, for example, is one of the 
entities that believes all MAIL is own by them and can be used to 
extracting information about both parties. So does Google and yahoo, 
but FaceBook has raised and highlighted the issue of recent by 
questioning any the idea of user email privacy. This is an issue that 
was a TABOO for nearly three decades by many who understand why it is 
an ethical issue.  Regardless of what you and I think, its being leverage.

Anyway, my engineering assessment regarding SAFE:

I think your intent is good, but I don't see how SMTP will help. You 
are extracting one good part of it (AUTH/TLS) but the rest of it is bad.

Even then, IMV, even if it is considered that an alternative should be 
considered, it would be a major revamp and thus SHOULD open the door 
to a newer more efficient protocol. One where the state machine would 
be much simpler.   Maybe something like SIP or XMPP or SOAP.

Both Microsoft and Adobe have newer client-side plug-ins that now 
offer  signed certificate authentication/authorization methods with 
their client-side "far calls."   So I don't think your draft will 
replace this part since it duplicates this resolution.

For AJAX, the SAFE consideration would produce scalability and 
performance issues.  I envision many timeout design issues.

DOM interactions is already an expensive operation.  SAFE would had a 
significant overhead to it.

SAFE restricting DOM events would be a major show stopper. Probably 
the single thing that would stop people from further consideration 
(include me, and I'm sure others).

The direction is MORE client side plug-ins, NOT LESS. Flash, 
SilverLight, APEX, Google Apps, Firefox Plug-ins are prime examples.

Here is our strategy which is a overview of the popular methods and 
how we intend to integrate it with our existing client side 
communications framework:

    http://www.winserver.com/public/vimg.wct?src=wcrpcnet7.png

There are quite a few client/server communication wirings. I don't see 
how we can use SMTP in the wiring here.  The REST method seems to be 
winning. Not the most optimal, less secured, but the easiest and it 
offers WEB 1.0 compatibility aspects, for example, it allows older web 
sites to offer "web services" per se.

Here is how I think you may get some interest:

Introduce SAFE as a new PROXY or protocol that would be more of a plug 
and play solution.  Make it a black box so that the interface (I/O 
prototype) points are the same.  The SAFE-BASE protocol only describes 
the I/O interface and leave the actual blackbox to SAFE plug-in 
developers.

If you can work that out, then the internal mechanism (SAFE plug-ins) 
would be left open for wide development.  One implementator can use a 
SAFE SMTP plug-in and another can invent another SAFE plug-in.

This would allow for example, a SAFE FireFox Plug-in for DOM to be 
written.

-- 
Hector Santos, CTO
http://www.santronics.com

Date: Sun, 02 Aug 2009 08:57:09 -0400
From: John C Klensin <[email-masked]>
To: Alessandro Vesely <[email-masked]>, SM <[email-masked]>
cc: [email-masked], SMTP Interest Group <[email-masked]>
Subject: Re: [yam] RFC 5321 (was: [Editorial Errata Reported] RFC5321 (1820)
Sender: [email-masked]

--On Saturday, 01 August, 2009 12:46 +0200 Alessandro Vesely
<[email-masked]> wrote:

>...
> Frank Ellermann noted the added phrase, and commented about it
> on April 26, 2007
> 
>   That's a point where you could mention that this used to be
> no
>   key difference under RFC 821, because "in any case, the SMTP"
>   added "its own identifier to the reverse path".  There might
> be
>   better places to explain that RFC 1123 broke the original
> SMTP
>   design in its quest to get rid of the source routes.
> 
> That was the concern of the discussion, rather about concepts
> than wording. In facts, Frank used to note discrepant usages
> of terms (e.g. "return path" vs "reverse path", in the same
> message) but missed also this spurious "backward-pointing
> address". (Currently, there are exactly three occurrences of
> the word "backward" in RFC 5321.) I found no other thread
> mentioning that phrase. John replied
> 
>   Send text, but my inclination is to not change this further,
>   especially to reflect the long-dead "copy own address into
>   reverse-path stuff".
> 
> That's it, almost. Frank had dropped that point in his further
> reply. I jumped on that list months later, after Frank's
> suggestion. I independently noted that phrase and had tried to
> leverage on its inconsistency for introducing a conceptual
> change which had been rejected.

Alessandro,

It is precisely the interconnection between this tiny change and
"the 1123 decision was a mistake" (something that DRUMS declined
to open and that no one has gotten traction for opening since)
and the terminology about rerouting email at various levels that
makes me unwilling to treat changes in this area as anything but
substantive and needing WG review.  That would be the case even
if I had reviewed the text in question (which I have not) and
agreed with you.

For those who haven't been following this closely, the 1123
issues was the change that turned Return-path in RCPT from
   <@relay3,@relay2,@relay1:local-part@domain>
to
   <local-part@domain>
regardless of the path taken.  My guess is that some of us would
argue that the change was absolutely correct, others would argue
that it is much too late to reconsider whether it was the right
decision at the time or not, and still others would argue that,
in this world of hostile or unwanted messages with faked
headers, the decision should be revisited and changed.  I've
fairly sure that split would make it very hard to get enough
consensus to make a change but I, at least, would not oppose
revisiting it if we could do so in a highly-focused way.

But I'm simply not going to make _any_ change in this area
unless the WG has discussed it and the Chairs have told me what
to do.

One of my tasks for the last several days is to assemble a
template for the revision of 5321.  That template is basically
the starting point for the notification/request to IESG (for
convenience, I just posted the most recent version into the WG
Wiki (http://trac.tools.ietf.org/wg/yam/trac/wiki)

I will include, in some form, a statement to the effect that we
will review terminology changes made between RFCs 821 and 2821
and between 2821 and 5321 where appropriate to determine whether
the WG is still happy with them and that some small changes are
possible on that basis.  Assuming the WG and IESG agree with
that characterization, that should eliminate the procedural
issue, permit us to concentrate on the substance and, as SM
suggests, hold a discussion in the context of the forthcoming
draft.

   john

Date: Sun, 2 Aug 2009 00:39:42 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2009-08-01 09:56:55 +0400, Cheney, Edward A SSG RES USAR USARC wrote:
> > I think you mix up HTTP and client-side scripting. HTTP is only a
> > protocol to send and request data.
>=20
> > Therefore I don't think you gain anything by using SMTP instead of
> > HTTP as the transport protocol.
>=20
> The problem only exists in the realm of HTTP due to where code actually
> executes for interaction.  HTTP is certainly not part of the problem,
> but it also cannot be a part of the solution due to the simplicity of
> its design.

What aspect of SMTP makes is superior to HTTP in this regard?

> In the WWW all interactive code executes at the user-agent
> software.  This software is written by a stranger to the local user who
> has absolutely no ability to verify the integrity of the code until
> after it has executed.  The user-agent cannot even control if the code
> executes automatically upon rendering of the page except to completely
> disable execution of all client-side code.

The last sentence is wrong (some browsers do implement ways to restrict
client-side codes by different criteria), and in any case that doesn't
seem to have anything to do with the protocol used to fetch the
(executable) contents: Neither HTTP nor SMTP care about the contents,
they just transport a header and a blob of data.

> > What is gained by adding intermediate systems?
> Intermediate systems offer a point of execution for code

You are contradicting yourself:

> 2) The server that owns the code is the exact point of execution for
> that code.

So the code is not executed on one of the intermediate systems but on
the server which hosts the code. The intermediate systems just pass
through messages.

> Technically speaking HTTP is also unidirectional.  HTTP typically
> operates with a GET request

The POST request is also well-known and frequently used.

> for a resource on a server and the server responds with that resource.
> Since logic is not capable of being passed into that GET request HTTP
> is unidirectional as a result.

No, because the POST request exists. It is both possible for the client
to send complex data to the server and for the server to send complex
data to the client. The only thing that is missing is a way for the
server to pass data to the client asynchronously (well, HTTP push
exists, but it was never used much) so the client needs to poll. But
that's only a minor problem which can easily be worked around.

> The solution to HTTP unidirectionality is the XMLHttpRequest object.
> SMTP is also unidirectional.  My solution for SMTP is the XMLSmtpPush
> object.
>=20
> > With your model, how would this be handled?
>=20
> In your example the code would execute using HTML's onkeyup event.  The
> limitation of this model is that event oriented execution is not
> allowed.

If you don't allow user-triggered events to be processed, what is the
advantage compared to traditional server-side scripting?=20

As somebody else already asked: What would be a typical use case for
your protocol?

	hp

--=20
   _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
| |   | [email-masked]         | Named "If you want it -- write it"
__/   | http://www.hjp.at/ |  -- Ilja O. on [email-masked]

--YiEDa0DAkWCtVeE4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--YiEDa0DAkWCtVeE4--

From: Steve Atkins <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Date: Sat, 1 Aug 2009 11:27:50 -0700
Sender: [email-masked]

On Aug 1, 2009, at 11:13 AM, Cheney, Edward A SSG RES USAR USARC wrote:

>
> SM,
>
>> I cannot tell what "SAFE" is.  That is not explained in the
>> Introduction or in the following paragraphs.
>
> In the title is expand the acronym as follows:
> SAFE (Server-side Asynchronous Framework Execution) Scripting Method
>
> The introduction states that SAFE Scripting Method is a model.  The
> model is expanded later in the document.  I could be more clear about
> the definition in the introduction section.

Is the context provided by http://mailmarkup.org/ still valid?

Cheers,
   Steve

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Date: Sat, 01 Aug 2009 22:13:18 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

SM,

> I cannot tell what "SAFE" is.  That is not explained in the
> Introduction or in the following paragraphs.

In the title is expand the acronym as follows:
SAFE (Server-side Asynchronous Framework Execution) Scripting Method

The introduction states that SAFE Scripting Method is a model.  The
model is expanded later in the document.  I could be more clear about
the definition in the introduction section.

> The third requirement in the draft is for a certificate
> authority.  That can be a hurdle in terms of adoption.

The CA requirement is necessary to verify the distant server is not on a
spoofed domain.  I have not found an alternative method of credential
verification.

> Script execution in email has proven to be problematic.  Although it
> is done on the server side, that does not reduce the risks as you
> still face the upgrade issue as the servers do not get updated that
> often.

I don't see this as a problem.  If the server that owns a script is the
same point as the execution of that script then the author of the code
owns its problems.  That requires the owner of code to take
responsibility for the results of script code they maintain, which is
not a requirement on the web.

> Could you please explain what this proposal has to do with SMTP?

This proposal is inherently reliant upon intermediary agents to execute
script code in accordance with model defintions in RFC 5598.

> A security centered document generally has some security
> considerations.

The document is itself a security consideration, but I think I will take
your advise and actually specify the problems of the WWW that this is an
alertnative for.

> Digital certificates by themselves do not have any credibility for
> some types of users.

The digital certificate should not carry any credibility by itself, but
should instead serve as a vessel for a digital signature.

Thanks,
Austin

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: "J.D. Falk" <[email-masked]>, [email-masked]
Date: Sat, 01 Aug 2009 20:40:41 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Hector,

> Lets start with the basic definition here:

>    Web 1.0  - HTML only, No Javascripting.
>    Web 2.0  - HTML only, Javascripting, Ajax
>    Web 3.0  - Web 2.0 + Rich Graphics

I know this is likely trivial to the current subject, but I have always
viewed the Web 3.0 as the fabled "semantic Web" where markup exists in
a serialization, presumably XML, and with a descriptive structural
grammar and not merely a descriptive grammar.  Such a markup convention
would allow rapid integration of RDF for ontological parsing through a
language like OWL or KAON.  The intention of such an elaborate
processing scheme is to require a more simplified manner of organizing
human consumable content, where simple refers to the immediate
understandability of humans and the efficiency of parsing grammar
definitions into syntax for computer evaluation of logic.

> The overall problem is that the industry is no longer concern with Web
> 1.0 compatibility.  In fact, Javascript is being enforce at many web
> sites. They don't bother with allowing web 1.0 users (those who choose
> to turn off javascript in their browser).

The greatest limitation to the creation of solutions for technology
problems, at least with the internet end-user, is the perceived value of
usability from those who most develope upon those technologies.
Usability testing has historically shown and continues to show that
users find beautification and interaction to be factors of extremely low
priority with regard to consumption and access to data.  Companies who
make beautification and usability their top priorities typically score
significantly lower on usability tests compared to competition whose
focus is on other factors such as perceived speed of delivery, clarity
of content, fewer pages/documents/emails necessary to complete a
transaction.  This paradox of usability is obvious to end users
unfamiliar or uncaring of the technologies and features required to make
these technologies available.  Developers, on the other hand, tend to
view the qualities of beautification and usability in the absolute
highest regards completely displacing any competing qualities of design
or development because beautification and usability do more to
illustrate the skills and technology competency of the developer.  I
find this to be a marketing problem of fallacy of proportions.

In other words those who should be most responsible for knowing better
are often the very people most at fault for the conditions of failure to
solve end-user technology problems.  The result of this failure is
technology stagnation, loss of trust, uncurable corner-cases, and loss
of value.  This is quite obvious with JavaScript specifically where the
only solution to its problems is to completely disable it to the point
of ensuring it cannot be allowed to exist.  Even as a new version of
JavaScript is being drafted these problems remain unresolved, and this
lack of solvency for the most important failings of the technology is
aware to those drafting the new version.

> The 2nd problem is that newer browsers are not even making it an user
> option to turn off javascript. For example, Google Chrome. This
> browser is a prime example of the problems you are concern about.
> Microsoft and others is following this lead.

This is in an important step in the failure of the web.  It is mandatory
execution of that which is commonly known to fail, from a security
perspective, without regard for the complete inability to solve the
problems faced by execution of the technology.  If this path continues
security vulnerabilities will continue to increase to such an extent
that trust and value will be lost to the end user so that this platform
of technology will be abandoned in favor any solution less faulty based
purely on a cost/savings decision without regard from the proprietary
nature of that technology.  Realistically, any given user will only
tolerate failure to such an extent, even if that failure is not
immediately perceivable.  This is a threshold nobody has bothered to
measure dispite the incredible investment in this technology platform.
That is simply bad business, and technology concerns of open standards
must not rest on the perceived value of such faulty business logic.

In other words never trust the software to make the correct decision
without independant consideration of the costs of that decision to the
technology as a platform.  Vendors of software are self-serving even if
the technology they develope is open source.

> The 3rd problem and alternative to the 2nd issue with users's turning
> ff javascript and/or the browser doesn't support cross domain
> requests, are the client-installed pluggins are bypassing these
> restrictions, i.e., Flash and SilverLight.

I completely agree that forcing a flawed technology down a user's throat
where the only solution is to bury the technology is simply a bad idea.
Mandating the execution of that technology in the face of that bad idea
is a worse idea.  That logic is a completely failure, and yet is the
position of interaction on the web.  This is why I wrote this draft
standard.

> I guess I am trying to see how your draft proposal using SMTP will
> help here and to solve what part of the above issue?

The idea is that interaction on the web is becoming a failure due to
security.  The only solution to this problem is to abandon that
interaction.  My draft aims to help that solution become less bitter by
proposing an alternate method of interaction.

> Peter's point is that the draft proposal would conflict with the
> dynamics here.

I agree.  Event oriented execution is not allowed by the draft.  This
harsh limitation is necessary to prevent abuse.  History of the
development of internet technologies suggest that if you give a develper
the opportunity to abuse a technology to expand usability the technology
will be so abused completely without regard for the harm caused by that
abuse.

> Well, all bets are off.  That is why I think you may be blowing
> against the wind here.

Perhaps the clarity and costs of failure of the web as a technology
platform are not yet evident.  At some point this will become painfully
evident.  Nobody else has proposed a solution to this problem.  If my
solution is too bitter in its usability limitations then the only
options are to propose a competing solution or watch the web as a
platform fail.  Honestly, I believe this is all smoke.  Documents worked
perfectly fine on the web before there was JavaScript and JavaScript
worked perfectly fine before was the DOM.  This is even true for
ecommerce and the exchange of data in a server-side application
environment.

> Anyway, it sounds to me that this is more about having a secured,
> certificate based "SAFE" proxy that people can use AJAX or
> FLASH/SilverLight with.

This is entirely about security.  Flash/Silverlight are not a solution
to JavaScript.

> At the end of the day, either you allow the site to run as it was
> designed if you want to be part of it, or just ignore it if you are
> concern about its cross domain behavior.

Demeaning the user is not a technology solution.

Thanks,
Austin

Date: Sat, 01 Aug 2009 11:02:19 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: "J.D. Falk" <[email-masked]>, [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Hector Santos wrote:

> Well, all bets are off.  That is why I think you may be blowing against 
> the wind here.  WEB 2.0+ direction is too strong. The market is 
> certainly caring less for Web 1.0 only support and would rather (because 
> it is less costly) just spit out a message:
> 
>     Sorry, Javascript is enabled to use this site.

I meant that to say:

     Sorry, Javascript is REQUIRED to use this site.

> Today, if a user is concern about reaching a site with hidden cross 
> domain operations, they can use the browser's No Scripting options like 
> newer IE and FireFoxes with the most excellent NoScript plugin.
> 
> At the end of the day, either you allow the site to run as it was 
> designed if you want to be part of it, or just ignore it if you are 
> concern about its cross domain behavior.   i.e, FACEBOOK - either you 
> want to be part of it or you don't because it relies are strong 
> interactive behavior and TONS of cross domain communications.

Let me illustrate how BAD it has gotten.

I have all the browsers installed on my machine for testing purposes 
against our hosting products.

For personal usage, I use Firefox with NoScript. With NoScript, if I 
trust the web site I am hopping to I will click the bottom right 
status bar NoScript ICON and it will list the main site and other 
cross domains it is trying to reach. It offers me to permanently or 
temporarily white list the main and/or the others.  In general I just 
white list the main site, not the cross domain sites.

For all these years that worked great. The sites I most visited still 
were 95% WEB 1.0 compatibility - I could web hop with javascript off 
by default and only enabled the ones I want to get the job done.

Within the last year, more and more sites are saying the above:

       "Javascript is required."

Now, if I care or needed to continue, I will enable it. Otherwise, 
forget them.

Today, more and more of the newer sites are completely Web 2.0+ and 
unless I completely white list them, I mean everything, even the cross 
site AD request and tracking domains, they will not work.  Even with 
me telling NoScript to opening it up.

Its gotten so bad, I have to use Google Chrome when I want complete 
unrestricted access to a particular site.

The point?

Google Chrome is the first browser to make it 100% known they do not 
want users to control their tracking and usage of Javascript to do 
background communications in a cloud or with their main HQ.  Typing 
at the address bar is now DYNAMIC. It records everything you do. Its 
part of their model of the future.  So I use it when I want full web 
2.0 experience and I don't worry about what it is doing (even though I 
showed how to stop its tracking here):

http://santronics.blogspot.com/2008/09/removing-chrome-spying-activity.html

Other browsers are watching and following suite and overall, its no 
longer what the user wants but rather trying to convince them there is 
no harm, "TRUST ME - THE BROWSER" and to change the mindset by having 
them ignore the idea that they is tons of communications going on. 
Most user don't even know it is going on and certainly not the new 
generation - the vendors are betting on it.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Sat, 01 Aug 2009 10:31:57 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: "J.D. Falk" <[email-masked]>, [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Edward,

With your follow up here and with Peter, and reading more of your 
draft, I am not sure if you are, using the proverbial, "blowing 
against the wind."

If I understand the problem statement and your concerns, which is for 
the most part XHR (AJAX) and cross-domain WWW based communications, 
then I agree with you that there is a major problem here - a serious 
major problem over security and privacy concerns of users.

Lets start with the basic definition here:

   Web 1.0  - HTML only, No Javascripting.
   Web 2.0  - HTML only, Javascripting, Ajax
   Web 3.0  - Web 2.0 + Rich Graphics

The overall problem is that the industry is no longer concern with Web 
  1.0 compatibility.  In fact, Javascript is being enforce at many web 
sites. They don't bother with allowing web 1.0 users (those who choose 
to turn off javascript in their browser).

The 2nd problem is that newer browsers are not even making it an user 
option to turn off javascript. For example, Google Chrome. This 
browser is a prime example of the problems you are concern about. 
Microsoft and others is following this lead.

The 3rd problem and alternative to the 2nd issue with users's turning 
off javascript and/or the browser doesn't support cross domain 
requests, are the client-installed pluggins are bypassing these 
restrictions, i.e., Flash and SilverLight.  However, more recent 
versions are providing certificate secured solutions here for cross 
domain requests.

Overall, we are coming to a full circle in the UI - the user frontend 
is more client side driven with the browser and plug-ins.  We have 
more persistent connections with these UIs.

I guess I am trying to see how your draft proposal using SMTP will 
help here and to solve what part of the above issue?

Take for example Peter's comment for an AJAX based suggestion box.  I 
have an example here as a jQuery Plugin example:

   http://beta.winserver.com/public/test/MultiSuggestTest.wct

This does a server side call per keystroke (although my plugin is a
lot smarter using a cache and knowing not to call the server again
when the user hits backspace).

Peter's point is that the draft proposal would conflict with the
dynamics here.  The SMTP model would be too inefficient for the
high-throughput requirements of WEB 2.0+.

Now I saw your follow-up saying in principle the DOM events would be 
prohibited in your proposal.

Well, all bets are off.  That is why I think you may be blowing 
against the wind here.  WEB 2.0+ direction is too strong. The market 
is certainly caring less for Web 1.0 only support and would rather 
(because it is less costly) just spit out a message:

     Sorry, Javascript is enabled to use this site.

than spend the resources in making sure the web site works in HTML 
only mode.

Anyway, it sounds to me that this is more about having a secured,
certificate based "SAFE" proxy that people can use AJAX or
FLASH/SilverLight with.  Flash and SilverLight already offer a new 
model based on signed certificates and encryption.

Today, if a user is concern about reaching a site with hidden cross 
domain operations, they can use the browser's No Scripting options 
like newer IE and FireFoxes with the most excellent NoScript plugin.

At the end of the day, either you allow the site to run as it was 
designed if you want to be part of it, or just ignore it if you are 
concern about its cross domain behavior.   i.e, FACEBOOK - either you 
want to be part of it or you don't because it relies are strong 
interactive behavior and TONS of cross domain communications.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Cheney, Edward A SSG RES USAR USARC wrote:

> Hector,
> 
> I must have not communicated the problem and objective clearly.  The security problem only exists in the realm of the WWW.  The solution to this problem, as I propose it, only exists over SMTP.  The idea is to eventually abandon use of all client-side scripting on WWW in favor of an alternate secure solution that is only capable of existing over SMTP.
> 
> I am not actually proposing to mix or merge HTTP and SMTP transaction states.  I have not thought of such an idea, and so such might be possible but I have given no thought to how that might work.  The closet to mixing protocols that I have ever thought of is to supply a URI in a markup language over email that may be either HTTP or SMTP as defined by that URI.
> 
> Thanks,
> Austin
> 
> ----- Original Message -----
> From: Hector Santos <[email-masked]>
> Date: Friday, July 31, 2009 8:30
> Subject: Re: Requesting comments on draft-cheney-safe-02.txt
> To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
> Cc: "J.D. Falk" <[email-masked]>, [email-masked]
> 
> 
>> Do you have examples of these HTTP-based SMTP Client Side Script?
>>
>> I presume its a HTTP POST request on port 25 (or some other known 
>> SMTP 
>> server port) with the posted request body content containing  
>> batched 
>> SMTP commands?
>>
>> Off hand, I am not sure if the security concerns are SMTP related.
>>
>> -- 
>> Hector Santos
>> http://www.santronics.com
>>
>>
>>
>> Cheney, Edward A SSG RES USAR USARC wrote:
>>
>>> The idea is that security vulnerabilities on the internet occur 
>> most significantly as a result of client-side scripting from 
>> documents transmitted across HTTP.  By most significant I mean as 
>> measured by quantity and not severity.  In addition to frequent 
>> immediate vulernabilities client-side scripting can also operate as 
>> an execution point for other additional vulernabilities not 
>> directly associated with client-side scripting.  It is my opinion 
>> that the only way to solve this security problem is to either break 
>> HTTP or eliminate client-side scripting.  I find there is no reason 
>> to break HTTP since it is working perfectly well and is not to 
>> blame for this problem.  Client-side scripting cannot be removed 
>> unless an alternative convention is proposed.
>>> It is absolutely imparitive that a solution exist as the quantity 
>> of these security problems are continually increasing and there is 
>> no possible solution available from HTTP.  If a solution is not 
>> proposed the security flaws of the system will become so 
>> significant that the commerical value of financial transactions and 
>> PII leaks will eventually result in abandoning the internet as an 
>> open platform in favor of more secure proprietary technologies.
>>> As an alerternative method of allowing interactivity from client-
>> side scripting I wrote this document to migrate the concept of 
>> client-side scripting to the email architecture.  The idea is that 
>> interactivity from client-side scripting can be replaced by 
>> transaction interactivity.  Since mail servers are intermediate 
>> agents in the transmission, opposed to an end point like an HTTP 
>> server, they can make processing or scripting decisions upon data 
>> without that scripting having to exist on a client system.  In 
>> other words, it is basically an inverted form of AJAX that does not 
>> execute on the client-side.  The idea is easily possible using 
>> SMTP, but is not possible over HTTP since HTTP does not have 
>> intermediate agents between the client and server.
>>> Thanks,
>>> Austin
>>>
>>> ----- Original Message -----
>>> From: "J.D. Falk" <
>>> Date: Friday, July 31, 2009 1:44
>>> Subject: Re: Requesting comments on draft-cheney-safe-02.txt
>>> To: "Cheney, Edward A SSG RES USAR USARC" <
>>> Cc: [email-masked]
>>>
>>>
>>>> Cheney, Edward A SSG RES USAR USARC wrote:
>>>>
>>>>> I am requesting comments on the following this internet draft.  Any
>>>>> questions, confusion, feedback, or changes would be helpful.
>>>>>
>>>>> http://tools.ietf.org/id/draft-cheney-safe-02.txt
>>>> Interesting idea.  What's the use case you have in mind?  In other 
>>>> words: 
>>>> who will use it, and why?
>>>>
>>>> -- 
>>>> J.D. Falk
>>>> Return Path Inc
>>>> http://www.returnpath.net/
>>>
>>>
>>
>>
>>
>>
> 
> 
> 

Date: Sat, 01 Aug 2009 12:46:37 +0200
From: Alessandro Vesely <[email-masked]>
To: SM <[email-masked]>
CC: [email-masked], SMTP Interest Group <[email-masked]>, John C Klensin <[email-masked]>
Subject: Re: [yam] RFC 5321 (was: [Editorial Errata Reported] RFC5321 (1820)
Sender: [email-masked]

SM wrote:
> Hi Alessandro,
> At 01:56 31-07-2009, Alessandro Vesely wrote:
>> searching for "3.9.2" on mail-archive brings only up previous 
>> discussions between you and me on the same subject. You rejected all 
>> of them on various reason, e.g. because the last call had already been 
>> issued, or because of the nature of the forwarding model as expressed 
>> in http://www.mail-archive.com/[email-masked]/msg00468.html. I 
>> never found the discussion where that paragraph has been introduced, I 
>> guess it was not public.

I hadn't searched well enough...

> There were some comments (most likely off-list) on that section prior to 
> the message at the above URL.

The above URL is dated Sat, 16 Feb 2008 07:17:43 -0800. Much later 
than the phrase containing the typo, which I quote again:

                                                    Note that
  the key difference between handling aliases (Section 3.9.1) and
  forwarding (this subsection) is the change to the backward-pointing
  address in this case.

NOTE: This phrase appears _twice_ in RFC 5321. Its second instance is 
much further down in section 4.4, around lines 3282-3284 of the 
numbered draft. Please concede that at least this second occurrence 
has to be removed completely...

That phrase can be found in the differences from -02 to -03, in 
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-klensin-rfc2821bis-03.txt#diff0057 
Version -02 is of April 17, 2007, -03 is of April 25, 2007, hence any 
message discussing that issue should be archived in 
http://www.imc.org/ietf-smtp/mail-archive/mail5.html. In facts, there 
is a message entitled "RFC2821bis-02 Issue 26: Source routes, 
especially reverse-paths" by John C Klensin, 04/22/2007. That was 
actually concerned with "Appendix C. Source Routes". The text quoted 
above presumably belongs to other "editorial and related changes to 
improve clarity and consistency", in that version's changes.

Frank Ellermann noted the added phrase, and commented about it on 
April 26, 2007

  That's a point where you could mention that this used to be no
  key difference under RFC 821, because "in any case, the SMTP"
  added "its own identifier to the reverse path".  There might be
  better places to explain that RFC 1123 broke the original SMTP
  design in its quest to get rid of the source routes.

That was the concern of the discussion, rather about concepts than 
wording. In facts, Frank used to note discrepant usages of terms (e.g. 
"return path" vs "reverse path", in the same message) but missed also 
this spurious "backward-pointing address". (Currently, there are 
exactly three occurrences of the word "backward" in RFC 5321.) I found 
no other thread mentioning that phrase. John replied

  Send text, but my inclination is to not change this further,
  especially to reflect the long-dead "copy own address into
  reverse-path stuff".

That's it, almost. Frank had dropped that point in his further reply. 
I jumped on that list months later, after Frank's suggestion. I 
independently noted that phrase and had tried to leverage on its 
inconsistency for introducing a conceptual change which had been rejected.

P.S.: This is the first time I spell Frank's name on a public list 
message since September last year. So I also add the ietf-smtp list in 
CC; please change the subject appropriately if replying about this 
last paragraph. I haven't been able to gather any news about Frank, 
and I'm afraid to understand that the common saying "no news is good 
news" doesn't apply in this case.

Date: Sat, 01 Aug 2009 03:43:18 -0700
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Cc: [email-masked]
Sender: [email-masked]

At 11:20 30-07-2009, Cheney, Edward A SSG RES USAR USARC wrote:
>I am requesting comments on the following this internet draft.  Any 
>questions, confusion, feedback, or changes would be helpful.

In the Introduction section:

   "SAFE Scripting Method has only two intended objectives:"

I cannot tell what "SAFE" is.  That is not explained in the 
Introduction or in the following paragraphs.

The third requirement in the draft is for a certificate 
authority.  That can be a hurdle in terms of adoption.

   "Allowing script execution in email is absolutely necessary to provide
    a minimal expectation of user experience and interaction, as well as
    promoting the advancement of data and commerce exchange."

Script execution in email has proven to be problematic.  Although it 
is done on the server side, that does not reduce the risks as you 
still face the upgrade issue as the servers do not get updated that 
often.  The proposal also assumes an "always-on" connectivity for the client.

Could you please explain what this proposal has to do with SMTP?  The 
draft mentions "mail server".  That term general encompasses several 
email-related protocols.

   "This is inherently a security centered document."

A security centered document generally has some security 
considerations.  You could discuss the problem areas and how the 
security issues may be mitigated.  BTW, don't think of security 
issues only in terms of where the code is running.  Some of the 
plights of email is due to content.

Remove encryption and digital certificates from the model and 
determine what the threats are.  Then think about how you would 
address them.  You can use encryption and digital certificates then 
but you should spell out what they are being used for.  Digital 
certificates by themselves do not have any credibility for some types of users.

Regards,
-sm