On Wed, 8 Sep 2004, Andrew Newton wrote:
It is the opinion of the co-chairs at this time (before the end of last
call) that the MARID working group has no consensus regarding the
deployment of Sender ID. This lack of consensus centers around the IPR
associated with the PRA algorithm.
I'm not surprised you draw this conclusion, considering posts on the list
for last couple weeks.... (in fact I would have been very surprised if
it was not the conclusion).
Since predicting deployment is a subjective matter and not strictly a
technical concern, we would like to offer the working group a proposal
for modifying Sender ID that would take the issue of deployment out of
the hands of the IETF
IETF had real problem is that it did not wish to deal with how their
protocols would be deployed. This is the main reason of failures of number
of protocols that have been created and why others are less used then
they could be. Certain conclusion must (and have) been drawn out of this
and it would be unfortunete if we choose to go the same road again.
and place it in the hands of the ultimate decision-makers, the systems and
network administrators of the Internet. We feel that this is where
decisions of deployment should really be made.
The same people are also looking for IETF for guidence. There is a reasson
why we have a BCP series and why exactly is it that we have entire section
of IETF is listed as "Operations and Management Area"?
While I think that if the drafts are to be published as EXPERIMENTAL
your statements that it would be up to the administrative to try it out,
(as an experiment to see if it works and later come to IETF and tell how
it is going and if more work is needed to make it standard), my understanding
is that this WG is expecting to publish documents in STANDARD track. But
it would not be a "Standard" if we don't expect entire worldwide community
to be able to implement it.
It is also the opinion of the co-chairs that many in the working group
are willing to deploy MAIL FROM checking as specified in
draft-mengwong-spf.
This is not unexpected conclusion either. However, I note that MAIL FROM
is different identity which is used entirely inside SMTP stream and not
usually seen by end-users. The problem here is not as much "phishing" as
it is a DoS that happens when your domain is used without your permission
and you get all the bounces.
This group should to solve both problems, but we should not say that you
are going to be able to solve either one problem or the other depending
on if you're part of the open-source community or commercial product
developer willing to get a supposedely "free" license.
Therefore, we ask for consideration of the following proposal:
The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne)
version = "spf2." ver-minor "/" ver-scope *( "," ver-scope )
ver-minor = 1*DIGIT
ver-scope = "pra" / "mailfrom" / name
name = alpha *( alpha / digit / "-" / "_" / "." )
And the following stipulations:
1) "mailfrom" checking will be defined in a new draft
2) multiple records are allowed
3) a scope (e.g. "pra") can only appear in one record of one type for
validity purposes
I'm going to comment in separate post on the scoping since issue now
officially came up.
The question before the working group: assuming no technical errors
with the above, is there anybody who vehemently objects with this
proposal?
Yes, I do.
Not on technical reasons that doing scoping is bad - I would have expected
scoping to be worked out by the group sooner or later anyway.
But as I indicated above, I'm concerned that the IPR issue with SenderID/PRA
are still unresolved and if we standartize PRA as chair is suggesting, only
some be able to do this type of verification and on the other hand only
some would do mail-from checking, etc. This separatism is a dangerous road
to take for IETF work, we want to have one unified internet-wide standard
not a standard for you and standard for me!
I think we should decide on SenderID/PRA all by itself. Either we find
an acceptable solution that will allow everybody to implement it or
we find a replacement for it or we drop the entire concept all together
and work on different identities and scopes, including envelope mail-from
as is done with classic SPF.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/