Hallam-Baker, Phillip wrote:
I do not think it makes any sense to be publishing a policy
> that says alsdkfjasdf.example.com is signed when no mail is
> going to ever be sent from there.
Of course not. the Policy would say NO MAIL is expected from this domain.
We already have mechanisms to say alsdkfjasdf.example.com
> sends no mail, and they block the attack without any need
> for complexity in the search scheme.
Where? How?
Defining a mechanism for nomail is out of scope, stating that we might
> rely on existing nomail schemes is not. One of the reasons the group
> agreed that we did not need to do nomail is that it is already done by
> SenderID/SPF.
No, No, no, no! I did not AGREED to that because of LMAP ideas.
You can't design a PROTOCOL base on the dependency and existence of
another PROTOCOL. This DKIM/SSP must stand on its OWN.
If we want to begin designing the protocol based on other protocols,
then we wasted alot of time here.
> I am saying that it makes no sense to kill ourselves creating a
> means of specifying mail sending policy for domains that never
> send mail.
See what I mean - CONFUSION!
I think half the problem here is that we have APPLICATION developers
trying to define PROTOCOLS and we need to be very careful of the "total
integration" syndrome.
If we want to be the systems person, then darn it, lets do it right.
Lets include LMAP ideas, in fact, lets include CSA/DNA, as well as CBV,
and GREYLISTING, etc. In fact, lets get a HEAD SMTP extension to dump
the headers first so we can do all this at the SMTP level.
I doubt we want to do this - let others BUILD the total systems or lets
operators put that parts together.
But SSP can and must stand on its own and it must allow for a NO MAIL
policy.
I thought that your XPTR or whatever it was, was a means of GENERAL
DOMAIN POLICY DISCOVERY, to support DKIM and possible other ideas, not
to begin dictating what POLICIES are BEST and for WHOM.
Lets get the MECHANISM worked out first. Thats the problem we need to
solve here. What is the LOOKUP methods for SSP! Lets not make this any
more complicated. This should be the least of the issue to have.
--
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