Hallam-Baker, Phillip wrote:
Stephen has almost captured my issues here.
>
> My point here is that since NOMAIL is not a MUST requirement we
> do not require the same level of design for deployment as for a
> feature that is a core requirement. In particular it is
> acceptable for us to specify a scheme which requires deployment
> of new DNS infrastructure for NOMAIL, this seems obvious to me
> as there are existing schemes which address this requirement.
>
> I do want to solve NOMAIL,
But it was already solved by definition independent on DNS servers.
> .... in fact I think that it is essential
> that we do so to close all possible avenues of attack, including
> the unsigned mail from nonexistent domain attack.
Huh? If it was essential, why was it made not part of the requirement?
Why NOMAIL? Why not exclude I NEVER SIGN or I SIGN EVERYTHING or I
MIGHT SIGN or I DON"T ALLOW 3RD PARTY? What does this XPTR "Lookup
Method" have anything to do with policies defined?
> However I am quite happy for expression of NOMAIL to require
> deployment of an XPTR capable DNS server.
Excuse me? Is this heading to some Proprietary Server concept? Are you
seeing that certain policies will only be possible based on the type of
DNS server one has installed?
I really hope this is not the case.
> I am proposing a scheme here which allows for a transition to a
> principled infrastructure in which NOMAIL like DKIM is supported
> as a first class entity.
I am totally lost.
> All I don't want to do is to discuss the details of NOMAIL
> implementation at this point. If we get the structure right they
> take about half an hour.
I'm sorry, I really wish I can understand from an engineering standpoint
the philosophy in all this, in particular why you insist that NO MAIL
has any bearings on the LOOKUP METHOD or type of DNS server one has as
oppose to any other policy.
In my view, this whole thing started with an incorrect statement back in:
http://mipassoc.org/pipermail/ietf-dkim/2007q1/007141.html
and in here:
http://mipassoc.org/pipermail/ietf-dkim/2007q1/007147.html
and for some strange reason you took over and began to make false out of
scope claims way back in February, when the in fact, it wasn't an issue
yet and no decision was made back then.
You decided to write a I-D and began to make claims "NO MAIL" was out of
scope based on your I-D. Maybe you assumed that there already existed
a method to determine a NO-MAIL concept and based on this you believed
it didn't apply to XPTR.
This is wrong.
What bugs me the most is that is that you raised it as an issue as being
redundant because SPF offered the idea and people believe you that it
shouldn't be included in the requirements.
I don't know why it even became an issue.
Stephen, this shouldn't even had come to become an raised issue and thus
"vote" because it was based on a false basis and false assumption about
existing technology and incorrect assumption that systems are going to
integrate SPF with DKIM and SSP.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html