ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] RE: I think we can punt the hard stuff as out of scope.

2007-06-05 11:38:20
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

<Prev in Thread] Current Thread [Next in Thread>