Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope

From: AccuSpam <[email-masked]>
Date: Thu, 09 Sep 2004 08:32:46 +0800

I vehemently object to standardizing fragmentation of e-mail via scope, especially when one scope is proprietary one from an entity who in the past has used monopoly leverage to "embrace and extend" as a means to convert de facto standards into proprietary standards.

We will end up with a fragmented internet e-mail system separated into proprietary (pra) and free software (mailfrom).  I will never vote to give ammunition to any attempt to fragment the fundamental protocols of the internet into proprietary and free software camps.  That is entirely against the spirit of what has made the internet successful worldwide.  Do we really need another "browser wars" in e-mail?

Instead I support a single DNS record which can be used by either proprietary (pra) or free software (mailfrom).

If Microsoft wants to use their leverage to popularize a DNS record which can they can use in their proprietary software, which can also be used by free software, then I would fully support that.  This is quite different from giving a vote of approval for Microsoft to use their leverage to "embrace and extend" the core internet.  Microsoft can freely use their leverage to create a separate DNS scope without the endorsement of the community concensus, but we must not encourage that by endorsing fragmentation as a standard.

Also there is no compelling technical advantage to a fragmented scope.  The fact is that per-domain anti-forgery will not stop all forms of phishing or e-mail forgery, nor will it stop spam.  For example, in pra, the Resent-Sender could be not forged, but the From: header could be forged.  In mailfrom, the MAIL FROM: envelope could be not forged, but the From: header could be forged.  These proposals can help anti-spam as an added input data regarding the source of an e-mail to feed into probability anti-spam analysis, as well perhaps others will explore different UI approaches to presenting the datum.  It will require experimentation and new innovations in using this new data, so the larger risk is on fragmenting who can use which data.  IMO either proposal might be quite effective at stopping phishing in some scenarios.  But in no case does this potential success justify fragmenting the core internet i the process of trying to achieve some marginal improvement in e-mail so!
 urce authentication.

Additionally there are technical advantages to not polluting the DNS with proliferation of "extend and embrace" wars on e-mail.

I completely agree that getting Microsoft and other corporate players on board is very helpful, but not at the cost of the other future billions of internet users who will probably use free software (third world countries for example, such as the UN's recent efforts to increase penetration in Africa using free software).

-Shelby Moore
http://AccuSpam.com

---

From: Andrew Newton <[email-masked]>
Date: Wed, 8 Sep 2004 21:16:23 -0400

On Sep 8, 2004, at 8:32 PM, AccuSpam wrote:
> Instead I support a single DNS record which can be used by either 
> proprietary (pra) or free software (mailfrom).

By this, I assume you mean a record that does not describe a scope 
(since what I proposed did allow one record to describe both scopes).  
And if so, do you actually think it is better for the receiver to have 
to guess the intended scope of the sender?

-andy

---

From: AccuSpam <[email-masked]>
Date: Thu, 09 Sep 2004 13:55:42 +0800

>(since what I proposed did allow one record to describe both scopes).  

Minimally yes.

IMO, the scope should be implicit from the specification.

I will elaborate below.

BTW, I appreciated your proposal to try to build concensus, and I hope you will consider my reasoning below.

>to guess the intended scope of the sender?

Yes because inherent in the design of the specification should be acknowledged the *REALITY* that the sender can not control the receiver (verifier).

Even today without this standard, senders have no control over how their e-mail is filtered by receivers.  IMO, that will never change, because the market will always decide that receiver has control over his/her Inbox and never give that control to the sender.  Would you give control of your Inbox to your senders?

A robust specification that will stand the test of time (e.g. SMTP)  will acknowledge that it only specifies what the syntax data means, it can not reasonably specify all the ways that companies will try to "embrace and extend" to their competitive advantage.

There is fundamental disconnect between what we think/want to happen and what we can actually insure will happen.  I urge people here to think about all the ways a specification can be "misused" (...for example if only the original writers of SMTP could have predicted "misuse"...).  I do not think we correct "misuse" by throwing everything we can think of into the specification. Instead, a wiser approach is to analyze priorities of what is sufficiently general and germane to the cause so as to both easily accepted into concensus and also robust to stand the test of time.

For example, since we know that pra and mailfrom can still suffer from forged From: (as explained in my previous post), i.e. we do not provide a final "end all" solution, then verifiers are going to be adding value by interpreting the data provided by the specification (e.g. incorporating when the From and PRA or MAIL FROM: are different as another data in probability analysis).

I think it would be folly and brittle for us to attempt to specify *ALL* the ways that the data in the DNS record can be used and interpreted, as the result set will be numerous and continually changing (improving).  We might never reach concensus (even if get all tthe people here to agree but as you deploy other needs will be discovered and specification will continually be under revisement).

Using this same logic, I am against a brittle and complex specification that attempts to cover too much.  If we could start with something simple and core, such as specifying the approved mail servers for sending from a domain, and then we can later build new specifications on top of that basic core specification.

I could ramble on about technical reasons.  We need to keep this simple for the millions of owners of domains, as most senders are not forged and thus have very little incentive to deploy.  Why complicate when we are not even sure what benefits we will get from the additional complexity?  Is it cost effective to prioritize the needs of a few and pass the cost on to the many?

Instead I support letting others build experimental complexity on top of a core unencumbered centralized standard, and then let them petition for their extensions to become part of the standard, but always only if those extensions can be used by free software also.  For example, if Microsoft proposes some extension to the syntax, then they should justify how that extension can be used by all software, not just their licensees, else it should not be incorporated into an endorsed standard.  It would be different if Microsoft had some proven technology that had no other alternative, but that is far from the case today.  In fact, I am arguing that choosing the winning technology from unproven and incomplete set, is not the role of the standards body.  And I argue that instead standardizing fragmentation is worse (or same as) no standard at all.

What is wrong with reaching concensus on a DNS record that specifies the approved mail servers for sending email for a domain, then allow SPF and SenderID (and others) to go forward as experimental uses of that specification?  Then we have more time to hash out real experience in the market.

Since issues such as SUBMITTER for forwarding are (minimally and I would argue preferably) not part of the DNS record, then we can proceed with that resolution as an experiment and debate such orthogonal issues forward.

Also we should try to form orthogonal approach to specification, so that we can accomplish highest priority goals most efficiently and so that esoteric and/or experimental features do not encumber the entire internet useage nor encumber future improvements and experience we will learn.

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 09 Sep 2004 09:15:53 -0400

> IMO, the scope should be implicit from the specification.

  "Implicit" instructions in specifications have historically meant
inter-operability problems, and security flaws.

  The specifications exist to make scope/intent explicit.  Adding a
few more sentences to clarify the scope would be a good idea for any
specification.

> Yes because inherent in the design of the specification should be
> acknowledged the *REALITY* that the sender can not control the
> receiver (verifier).

  Control is different from intent.  MX records in DNS are intended to
be used as destination IP's for SMTP traffic to a domain, and that
intent is explicit in the specifications.  Yet nothing stops anyone
from doing:

$ ping `host -t mx example.com`

  For MARID issues, the intent of the publisher of the records should
be made explicit in the specifications, if not the protocol.  For the
vast majority of recipients who use the records as expected, having
that intent explicit makes their jobs easier.  For the recipients who
don't follow the publishers intent, it makes no difference to have
that intent explicit, because they won't follow it.

> I think it would be folly and brittle for us to attempt to specify
> *ALL* the ways that the data in the DNS record can be used and
> interpreted, ...

  Similarly, it would be follow to specify *no* standard way for the
data to be used and interpreted.

  There is a happy medium.  We should find it, and use it.

  Alan DeKok.

---

From: AccuSpam <[email-masked]>
Date: Fri, 10 Sep 2004 08:20:16 +0800

>few more sentences to clarify the scope would be a good idea for any

Of course and I my suggestion is completely consistent.  Read on below to the end...

The point I am making is not against specifying the scope of the data being exposed, but against specifying multiple scopes in multiple records, because this will lead to confusion, fragmentation, etc..  Some examples of possible confusion:

1. "Why are there two different ways to specify the approved mail servers for my domain?"

2. "Which is better?"

3. "Which is required?"

etc..

You create a proliferation of issues, proliferation of debate, proliferation of DNS records, proliferation of competitive issues, ... in short, you do not create a useful standard.

If there is a compelling technical reason to need multiple scopes on the DNS record, then you can consider the tradeoffs.  There is no compelling technical reason.

>$ ping `host -t mx example.com`

Your analogy is comparing apples to oranges.  In the case of MX records, the scope specified is a 100% solution to the need that it is for.

In the case of per-domain anti-forgery authentication, all the current algorithms for processing the approved mail servers DNS record do not give a 100% result.  Thus it is impossible to declare the *FINAL* scope.  No one knows today what the *FINAL* scope will be.

Instead the best we can do is declare what the data that is being exposed means and what it is intended to be used for.

In short, with MX there is no compelling need to use the data in any other way than the exact scope specified.  Whereas in our case, the data is going to be used in creative ways to accomplish the goals of the receiver.

And I assert that by fragmenting the scope into multiple DNS records, you will actually have the reverse of the intended effect.  Instead of limiting scope, you will cause all sorts of adhoc algorithms to try to give the anti-forgery results desired by recipient based on multiple records.

It seems your logic above assumes that recipient will only deal with one DNS record orthogonally.  So what does recipient do with multiple scopes?  What does recipient do when the result from scope(s) is neutral or error or inconclusive?

>that intent explicit, because they won't follow it.

Make explicit how I can deal with the case with PRA where the Resent-Sender: is not forged but the From: header is forged?  Ditto for MAILFROM: and From: in SPF?

Make explicit how I can use the the results from either scope algorithm to help fight spam?

Make explicit how I can combine multiple results from multiple scopes?

>data to be used and interpreted.

We should specify what we can specify.  But adding uncompelling scopes when it is the same underlying data is not useful.

>  There is a happy medium.  We should find it, and use it.

Agreed.  I think that happy consensus medium would be to specify the approved mail servers for a domain, and then specify some of the possible algorithms that might be applied by receivers.