Subject: Re: [ietf-dkim] SSP issues

From: Stephen Farrell <[email-masked]>
Date: Fri, 01 Jun 2007 13:54:13 +0100

Hi Jim,

Barry and I would like us to do the following:

Continue the discussion on the list for a few more days since
not all the usual suspects have reacted yet (please do!) and
the context is slightly different (with XPTR anyway) from the
(many;-) other times we've discussed these topics in the past.

Then, (say the week after next?) you get the co-authors of
draft-ietf-dkim-ssp-00 together and just pick your current
best answer for each relevant issue and submit the -00
around June 24. If you think some concalls/jabbering or
whatever will help there, just let Barry & I know.

Then, we'll look for offers of concrete alternative text
to be sent to the list before Chicago.

In Chicago we discuss. With one another and with the
DNS folks.

And then (back on the list) we resolve each of these well-worn
issues once and for all (using strawpolls or whatever's
necessary) over the following weeks and aim for a draft on
which we can have WGLC in September. (With the reality being
that it'll be October before we're ready.)

Regards
Stephen & Barry.

Jim Fenton wrote:
> What we had hoped to do in the next revision of the allman-ssp draft was to unify it as much as possible with Phill Hallam-Baker's draft.  I opened three new issues on April 16 that I think need to be resolved in order to do that.
> 
> (1) Use of XPTR records for SSP.  The idea here is to create a more general policy mechanism that can be used by WS-* and such.  There were about 20 messages discussing this from 5 people.  I'm not reading a clear consensus on this.
> 
> (2) SSP record type (TXT vs. something new). Only 4 messages in discussion, mostly saying "if you support TXT, don't bother with anything else."  Again, no clear consensus.
> 
> (3) Upward query vs. wildcard publication.  27 messages in discussion from 15 people.  Most of the discussion was a rehash of the idea of associating semantics with DNS zone-cuts, which we had already discussed and rejected.  I have also been trying to get an opinion from DNSOP on the idea of a one-level upward search (which I think solves 90% of the problem), but haven't gotten any response.
> 
> So I don't know what to write in a revision of the draft.  I could just write my opinions, but that's basically what's in the draft-allman-dkim-ssp-02 draft already and doesn't make any progress toward unifying the different proposals.  I want to get something done soon, well before the July 2 deadline.
> 
> -Jim
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Fri, 01 Jun 2007 12:02:25 -0700

Works for me.  Actually, due to vacation schedules, I need to accelerate
that a bit and get the draft submitted by June 15.

So, WG participants (especially the 'usual suspects'), let's hear from you.

-Jim

Stephen Farrell wrote:
>> What we had hoped to do in the next revision of the allman-ssp draft
>> was to unify it as much as possible with Phill Hallam-Baker's draft. 
>> I opened three new issues on April 16 that I think need to be
>> resolved in order to do that.
>>
>> (1) Use of XPTR records for SSP.  The idea here is to create a more
>> general policy mechanism that can be used by WS-* and such.  There
>> were about 20 messages discussing this from 5 people.  I'm not
>> reading a clear consensus on this.
>>
>> (2) SSP record type (TXT vs. something new). Only 4 messages in
>> discussion, mostly saying "if you support TXT, don't bother with
>> anything else."  Again, no clear consensus.
>>
>> (3) Upward query vs. wildcard publication.  27 messages in discussion
>> from 15 people.  Most of the discussion was a rehash of the idea of
>> associating semantics with DNS zone-cuts, which we had already
>> discussed and rejected.  I have also been trying to get an opinion
>> from DNSOP on the idea of a one-level upward search (which I think
>> solves 90% of the problem), but haven't gotten any response.
>>
>> So I don't know what to write in a revision of the draft.  I could
>> just write my opinions, but that's basically what's in the
>> draft-allman-dkim-ssp-02 draft already and doesn't make any progress
>> toward unifying the different proposals.  I want to get something
>> done soon, well before the July 2 deadline.
>>
>> -Jim

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 01 Jun 2007 21:30:04 -0500

> (2) SSP record type (TXT vs. something new). Only 4 
> messages in discussion, mostly saying "if you support 
> TXT, don't bother with anything else."  Again, no 
> clear consensus.

If a new RR can solve the wildcard issue and we feel that this is a significant issue worth solving (or at least addressing) then perhaps we should create a system that looks for a new RR first and failing that, falls back to TXT.

I don't think the "if you support TXT, don't bother with anything else" position is correct.  If we come out with a spec that states "SSP clients must query for new RR first, then TXT" senders would be right to expect compliance.  This frees senders to deploy the new RR when they need and are able to do so.  Until then, TXT.

Arvel

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Jun 2007 23:34:34 -0400

Arvel Hathcock wrote:
> If a new RR can solve the wildcard issue and we feel that this is a 
> significant issue worth solving (or at least addressing) then perhaps we 
> should create a system that looks for a new RR first and failing that, 
> falls back to TXT.
> 
> I don't think the "if you support TXT, don't bother with anything else" 
> position is correct.  If we come out with a spec that states "SSP 
> clients must query for new RR first, then TXT" senders would be right to 
> expect compliance.  This frees senders to deploy the new RR when they 
> need and are able to do so.  Until then, TXT.

+1

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Steve Atkins <[email-masked]>
Date: Fri, 1 Jun 2007 23:18:50 -0700

On Jun 1, 2007, at 7:30 PM, Arvel Hathcock wrote:

> significant issue worth solving (or at least addressing) then  
> perhaps we should create a system that looks for a new RR first and  
> failing that, falls back to TXT.
>
> I don't think the "if you support TXT, don't bother with anything  
> else" position is correct.  If we come out with a spec that states  
> "SSP clients must query for new RR first, then TXT" senders would  
> be right to expect compliance.

What would "compliance" entail prior to universal, or at least  
widespread, support for the new RR by all stub resolvers and  
recursive resolvers? Or would you wait for that widespread support  
before releasing the spec?

Cheers,
   Steve

---

From: Hector Santos <[email-masked]>
Date: Sat, 02 Jun 2007 04:04:16 -0400

Steve Atkins wrote:
>> significant issue worth solving (or at least addressing) then perhaps 
>> we should create a system that looks for a new RR first and failing 
>> that, falls back to TXT.
>>
>> "SSP clients must query for new RR first, then TXT" senders would be 
>> right to expect compliance.
> 
> widespread, support for the new RR by all stub resolvers and recursive 
> resolvers? Or would you wait for that widespread support before 
> releasing the spec?

Steve,

I am bit of a lost of what is so complex here.  It is the lack of 
understanding of the DNS technical compatibility issues that exist when 
it comes to handling of new RR records?

Until most, if not all, DNS servers, especially those with cached DNS 
servers, support RFC 3597, "Handling of Unknown DNS Resource Record (RR) 
Types", we will need a fallback on a TXT record concept.

see RFC 3597,  http://www.ietf.org/rfc/rfc3597.txt

It is really isn't all that difficult.

The bottom line is that there will be many systems with DNS servers and 
domains that simply will not be able to work with a NEW RR and seriously 
doubt DKIM is going to be the primary reason for most to begin changing 
their setup or network in order to support the "near" reliable 
propagation of NEW RR queries.

There is really no choice here.  To choose RR only, we are strategically 
saying that we don't want older systems and all must upgrade.   That 
isn't a good strategy, never mind unrealistic.  We are talking about a 
huge population of DNS systems that simply do not have the capability of 
handling a new RRs.

If we want to maximize adoption, a TXT record is required.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Sat, 02 Jun 2007 03:24:05 -0700

> If we want to maximize adoption, a TXT record is required.

Hector,

I agree, and I think Steve was expressing the same.

Use of TXT records means wildcards can not be used.  Most would likely
attempt to optimize a now more painful search by starting just below the
TLD, especially when dealing with many labels.

The DKIM WG might avoid resulting concerns by handling this downside.
Avoidance could be achieved by a simple list established by IANA. This
list could state "This domain supports a registry, and not other
services."

There should be plenty of motivation to enroll and use such a list.
This list should also be fairly stable.  Avoidance of these domains
could be accomplished by "this is a registry" RR published by the
registries.  "Compliance" with such a mechanism would likely take longer
than publishing a list.

With many machines pumping out spam at rates approaching 1 gbit, and
spam runs appearing to be millions wide, handling all this completely
wasteful and often malicious traffic is not a trivial matter.  At this
point, critical Internet infrastructure is at its mercy.

Whatever is done with DKIM must attempt to ensure this does not enable
additional mischief.  It seems ironic attempting to defend chronically
porous OSs from the Internet, when its the Internet that needs
defending.

SSP can also permit a safe method to associate domains.  In addition to
preventing replay abuse, this mechanism could also help deal with the
inevitable problem of bounce traffic containing broken DKIM signatures.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Sat, 02 Jun 2007 14:25:13 +0200

Greetings Arvel,
> we should create a system that looks for a new RR first and failing 

As a guy who recommended TXT records earlier I could just as easily live 
with a new record.  What I am more concerned about is the amount of 
complexity in the system.  Going through both TXT *and* SSP records 
seems like a recipe for synchronization problems and other nasties that 
we could best do without.  And I could easily be convinced by Peter Koch 
that a new record just isn't that hard to get out there.

Eliot

---

From: Hector Santos <[email-masked]>
Date: Sat, 02 Jun 2007 09:00:40 -0400

> that a new record just isn't that hard to get out there.

How will my Mr. Koch assure the world that new RR record queries will be 
reliable?  that all new RR queries will be expected to be passed thru 
recursive queries by heterogeneous DNS servers?

I don't think so Eliot.

-- 
Sincerely

Hector Santos, CTO

---

From: Eliot Lear <[email-masked]>
Date: Sat, 02 Jun 2007 15:50:46 +0200

Hi Hector,
> How will my Mr. Koch assure the world that new RR record queries will 
> be reliable?  that all new RR queries will be expected to be passed 
> thru recursive queries by heterogeneous DNS servers?

I don't know, but since he's made a forceful argument in the past on the 
subject I figure we would do well to not imagine his answer ;-)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Sat, 02 Jun 2007 10:35:23 -0400

Doug,

If I catch your drift,  I will be opposed to any IANA or 3rd party
"registry" concept for SSP. Not sure how that relates to RR vs TXT
records SSP question.

Anyway, wild card searches is something, IMO, most systems are simply 
not going to need.  And if required for a larger domain, they simply can 
create multiple TXT records.

This can be solved very simply with a SSP syntax that has multiple text 
records concept or one long, with tag or fields or attributes for each 
sub-domain, if necessary.  Right now, a TXT lookup will return all TXT 
records.  So all we need is a single organization domain lookup to 
obtain all its sub-domain policies.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Sat, 02 Jun 2007 09:07:07 -0700

Hector,

Random labels necessitate searching.  An MX record can already utilize a
wildcard.  Mandate that an MX record be available for any email-address
domain being signed. Why not?

Searching upward from the domain in question may generate a large number
queries not controlled by the domain questioned.  It is a bit late to
demand that DKIM signers MUST have such a record.

> obtain all its sub-domain policies.

In essences, you are now arguing to have records placed at some base
domain below a prefix.  When no record is found, recipients then search
for this record.  Starting from where the bad-actor suggests may involve
several transactions before concluding.  And when there is no record,
where does this stop and perhaps even start?  At the domain just below
the TLD.

If this domain is a SLD as with co.uk, then they will see a storm of
traffic serving no purpose.  Remember often >90% of email traffic
represents bad-actors willing to do whatever it takes.  What defense is
there from all their recipients doing massive searches?

What I am suggesting is a bit different.  As this label must have a
prefix, why not allow the prefix to associate with another domain via a
hash?  Check the existence of an MX record when no policy record is
found.  When policy record lookup fails and the MX record exists (we are
at two transactions), a third lookup could be for
_dkim-all.<email-address-domain> to determine whether a lack of an
association is acceptable.

This approach represents the same number of transactions as suggested by
Phillip, but also provides a means to curtail a replay-abuse and
broken-signature bounce problem.  Doing this now ensures at most one
additional transaction occurs.  This seems well worth it.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 2 Jun 2007 12:19:59 -0400

On Friday 01 June 2007 22:30, Arvel Hathcock wrote:
> position is correct.  If we come out with a spec that states "SSP clients
> must query for new RR first, then TXT" senders would be right to expect
> compliance.  This frees senders to deploy the new RR when they need and are
> able to do so.  Until then, TXT.
>
I think this is sensible.   "If you support TXT, don't bother with anything 
else" approach is appropriate if the new RR functions identically to TXT.  
There is no incentive to migrate.  In this case, where the new RR provides 
additional functionality, the incentive to migrate is built in.

Since initially there will be little to no support for the new RR, the RFC 
language should be something long the lines of SHOULD query new RR first, 
MUST query new RR or TXT so that DNS queries for the initially non-existant 
new RR types are not required for compliance.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Sat, 2 Jun 2007 09:27:26 -0700

On Jun 2, 2007, at 1:04 AM, Hector Santos wrote:

>>> If a new RR can solve the wildcard issue and we feel that this is  
>>> a significant issue worth solving (or at least addressing) then  
>>> perhaps we should create a system that looks for a new RR first  
>>> and failing that, falls back to TXT.
>>>
>>> else" position is correct.  If we come out with a spec that  
>>> states "SSP clients must query for new RR first, then TXT"  
>>> senders would be right to expect compliance.
> understanding of the DNS technical compatibility issues that exist  
> when it comes to handling of new RR records?

> Until most, if not all, DNS servers, especially those with cached  
> DNS servers, support RFC 3597, "Handling of Unknown DNS Resource  
> Record (RR) Types", we will need a fallback on a TXT record concept.
>
> The bottom line is that there will be many systems with DNS servers  
> and domains that simply will not be able to work with a NEW RR and  
> seriously doubt DKIM is going to be the primary reason for most to  
> begin changing their setup or network in order to support the  
> "near" reliable propagation of NEW RR queries.

So if the spec states "SSP clients must query for new RR first, then  
TXT" you wouldn't expect most receivers to comply with that?

> There is really no choice here.  To choose RR only, we are  
> strategically saying that we don't want older systems and all must  
> upgrade.   That isn't a good strategy, never mind unrealistic.  We  
> are talking about a huge population of DNS systems that simply do  
> not have the capability of handling a new RRs.
>

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 2 Jun 2007 12:40:34 -0400

> TXT" you wouldn't expect most receivers to comply with that?

Eventually, if the new RR type gets some deployment.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Sat, 02 Jun 2007 09:54:56 -0700

> Eventually, if the new RR type gets some deployment.

Scott,

Won't the ultimate impact be an increase in damage created by spam?  Why
double the amount of searches induced by this junk?  Why not depend upon
the existence of a specific MX records for those that care about either
their policy or MX record being found?  Those in trouble need to stop
using a wildcard MX.  Is that too painful?

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Sat, 2 Jun 2007 10:02:08 -0700

The original statement by Arvel (which Hector agreed with) was:

> If we come out with a spec that states "SSP clients must query for  
> new RR first, then TXT" senders would be right to expect compliance.

I do not see how this statement can be true for, at least, several  
years. Hence my question to Arvel and Hector - is this statement  
false, or are they assuming SSP deployment will wait until widespread  
adoption of a new RR.

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 2 Jun 2007 13:08:55 -0400

> using a wildcard MX.  Is that too painful?
It's not painful for me at all.  Others on the list have stipulated a 
requirement for it.  The TXT now and new RR type with wildcard support when 
ready approach let's deployers trade the complexity of DNS changes against 
dropping the wildcard.  We can let the market decide which is less painful.

It's a single DNS query, so DNS query + or - 1 doesn't seem like a major 
problem.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 2 Jun 2007 13:31:23 -0400

> false, or are they assuming SSP deployment will wait until widespread
I think the entire point of having TXT is to get deployment started soon.

I don't think that mandating checking the new RR type will do much to get it 
deployed.  If it's going to get deployed, it has to have an advantage.  If 
wildcards are an important use case, then it'll get deployed.  In the 
meantime, I don't see the value in mandating checking the new RR type first.  
This is particularly true since there are deployed resovlers that don't reply 
at all to unknown RR Types.  You'd have to wait for a timeout and then query 
TXT.  That would not help message delivery timelines.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Sat, 2 Jun 2007 10:47:21 -0700

> TXT.  That would not help message delivery timelines.

Exactly.

If there's widespread belief in the general value of a policy RR then
it can be developed properly, and deployed at a reasonable
rate. If, by the time the new RR is supported by most DNS  
infrastructure,
SSP is still considered useful it can be upgraded then to support
the new RR.

As an aside, I don't believe there's anything that prevents use
of TXT records, as currently specced, with wildcards, other than
lack of support in the more widely used nameservers. If a sender
wants wildcard support there are two things they can do.

They can wait until pretty much everyone they may ever want to
send email to has updated to support the new RR at every point
in their DNS resolution stack, all the way to the MTA.

Or they can ask the vendor of their authoritative DNS server
to support TXT wildcards. I suspect the latter would be a much
faster solution for those senders who need wildcard support,
and it's likely the only solution for those senders who need it
this decade.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Sat, 02 Jun 2007 14:35:24 -0500

Eliot Lear wrote:
>        What I am more concerned about is the amount of

+1

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John Levine <[email-masked]>
Date: 2 Jun 2007 21:37:06 -0000

>lack of support in the more widely used nameservers.

It depends on what your plan for using TXT records is.  If you're
planning to use a prefix like _ssp.example.com, internal wild cards
like _ssp.*.example.com aren't ever likely to work because it would be
a compatibility issue.  (Think of the fun when a secondary that
doesn't handle them AXFRs a zone.)  There's been some suggestions for
internal wild cards marked by ** but I gather that has unpleasant
interactions with DNSSEC.

The alternative is to do what SPF did, put the TXT record directly at
the name and use version strings at the beginning of each record to
tell them apart.  Beyond the gross ugliness, there's concerns about
how likely client code is to reliably ignore the records it doesn't
understand, and there may also be some issues where the names you want
to wildcard for SSP overlap with the ones for SPF.

We've gone around this enough times that I think that if there were a
reasonable way to do wildcards with TXT records, we'd have stumbled
across it by now.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Sat, 2 Jun 2007 14:51:12 -0700

On Jun 2, 2007, at 2:37 PM, John Levine wrote:

> doesn't handle them AXFRs a zone.)

That's exactly what I meant. You'd need to update your authoritative
nameservers to handle internal wildcards, if you were a sender who both
wanted to use SSP and had a vast number of potential sender
subdomains.

> There's been some suggestions for

If you exclude "fix the authoritative server" as an option, then
there isn't a reasonable way to do so. That's a reasonable
exclusion in general.

But... if the only problem is wildcard records, and only a small
number of senders are going to want to use wildcards with
SSP then the obvious engineering solution is to have those
small numbers of senders upgrade their DNS infrastructure,
rather than wait for the far larger number of potential recipients
to upgrade their infrastructure.

And, from what I'm hearing, those who are motivated to use
SSP at all are mostly senders. Having those with the motivation
be the ones who need to do the infrastructure upgrades
would likely speed deployment. (But so would having a
shiny new RR that's well designed and has desirable uses
outside the grubby little niche that is SSP.)

Cheers,
   Steve

---

From: John Levine <[email-masked]>
Date: 2 Jun 2007 22:34:13 -0000

>number of senders are going to want to use wildcards with SSP then
>the obvious engineering solution is to have those small numbers of
>senders upgrade their DNS infrastructure, rather than wait for the
>far larger number of potential recipients to upgrade their
>infrastructure.

The problem is that you've just spec'ed SSP to use a protocol that
is not DNS.  It's fairly similar to DNS, but it's not DNS.  I can't
imagine the IESG accepting that in a standards track document.

The question of wildcards internal to names has been around for years.
Everyone except extreme DNS fundamentalists agrees that they would be
very useful, but they haven't converged on a workable design and we're
unlikely to do it here.

>And, from what I'm hearing, those who are motivated to use SSP at all
>are mostly senders.

Personally, the part of SSP that I would find useful is "I send no
mail".  I get mountains of blowback from spam sent with addresses
subdomains of mine, starting with misscraped message IDs with host
names on the right side, now mutated into various sorts of dictionary
attacks.  I'd want to tell people that it's all bogus.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Sat, 2 Jun 2007 15:51:12 -0700

(wildly off-topic content follows. Hit 'N' now.)

> imagine the IESG accepting that in a standards track document.

No, it's perfectly compliant DNS. Really, it is.

It's not bind, though, and there's a fairly common fallacy at IESG,
amongst other places, that DNS is "what bind does" rather than
vice-versa. So, yeah, you're right about the standards document
issue (were it me, I'd just spec TXT records and not mention
wildcards at all).

I have a dns server that'll do internal wildcard records today (as
do you, IIRC). The information it uses to do that will not transfer
correctly over AXFR - but who, other than some subset of bind
users, uses AXFR to maintain their secondaries, anyway? :)

> very useful, but they haven't converged on a workable design and we're

I think I'm a DNS fundamentalist, and I think it's a fine idea.

> attacks.  I'd want to tell people that it's all bogus.

How is "MX ." working out for you? Not a rhetorical question - it's
likely the closest we have to a standard for "I don't send email"
today, and is more likely (IMO) to be used by recipients than
SSP, so it's an interesting bit of data.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Sat, 02 Jun 2007 16:16:31 -0700

> outside the grubby little niche that is SSP.)

By excluding wildcard MX records in those domains being phished or
spoofed, the logic is rather simple.  When there is an MX record for the
email-address domain in question, then there MUST be a policy record, or
policy does not matter.  Enforcement of policy does NOT require
wildcards!  Simply the MX record MUST NOT use wildcard MXs when policy
matters.

Wildcards create other risks.  Avoiding wildcard DNS records is a far
safer course of action. Conditioning use of non-wildcard MX records
eliminates any need to introduce new RRs.  One simple policy record
using a prefix (hopefully a hash of an associated domain) would be
completely adequate.

This also provides a simple means to solve the next set of problems:

a) replay abuse,
b) broken bounce messages.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 2 Jun 2007 17:17:17 -0700 (PDT)

> users, uses AXFR to maintain their secondaries, anyway? :)

If it was just AXFR all would be great. But in order to do DNSSEC it is
in fact necessary for servers to know how to process wildcards and that 
means any local wildcard-like MACROs have to be part of the spec.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: John Levine <[email-masked]>
Date: 2 Jun 2007 23:26:25 -0000

>No, it's perfectly compliant DNS. Really, it is.

Unfortunately, it's not, because AXFR is part of the DNS spec.  We now
know that they should have separated out the part about query
resolution, which has to interoperate everywhere, and server side
database management which doesn't.  But they didn't, and if you can't
do it with AXFR and IXFR, it's not official DNS.  Also don't forget
the DNSSSEC issues, which I gather have to do with walking the tree of
names, something that internal wildcards makes more difficult.

>I think I'm a DNS fundamentalist, and I think it's a fine idea.

No, if you were a DNS fundamentalist, you'd be saying it's trivial to
add ten million explicit records to a zone so it's not a problem that
wildcards for one type don't cover nodes with data of another type,
and new record types are easy to add so you don't need anything more
than the current wildcards.  (I.e.., if I were AOL, I would like to
tell the world that my dialup farm doesn't receive mail via:

 *.AOL.COM MX .

but since they have all those A records for the addresses in the farm
you need to put an explicit MX next to every A record.)

>today

Actually, I haven't tried it, but I should.  Doesn't have much to do
with SSP, though, other than that it does the useful part of what SSP
proposes to do.

R's,
John

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 2 Jun 2007 19:58:15 -0700

There is a big difference between introducing a new RR to assist the discovery process and introducing a new RR for the policy.

The problem is that publishing the same information in multiple records inevitably leads to a risk of inconsistency. This is particularly problematic when using the DNS as the records are cached and there are long timeouts by network administration standards.

I really really dislike protocols that lead to admin situations where the admin makes a change and the problems it causes only become apparent several hours after they make the change. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Arvel Hathcock
> Sent: Friday, June 01, 2007 10:30 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] SSP issues
> 
> If a new RR can solve the wildcard issue and we feel that 
> this is a significant issue worth solving (or at least 
> addressing) then perhaps we should create a system that looks 
> for a new RR first and failing that, falls back to TXT.
> 
> I don't think the "if you support TXT, don't bother with 
> anything else" position is correct.  If we come out with a 
> spec that states "SSP clients must query for new RR first, 
> then TXT" senders would be right to expect compliance.  This 
> frees senders to deploy the new RR when they need and are

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 2 Jun 2007 20:02:55 -0700

I find the argument from Microsoft where they showed the code for their DNS server and in particular the switch statement saving the file data somewhat more convincing.

What they mean is that they can coax the server to emit the desired bit sequences under certain conditions, not that it is a configuration they would personally accept.

In other words it is administration advice from Linux geeks directed at Windows network admins. It's a bit like taking advice on how to mix a Manhattan from the Temperance Union.

> [mailto:[email-masked]] On Behalf Of Eliot Lear
> Sent: Saturday, June 02, 2007 9:51 AM
> To: Hector Santos
> Cc: [email-masked]
> I don't know, but since he's made a forceful argument in the 
> past on the subject I figure we would do well to not imagine 
> his answer ;-) _______________________________________________

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 2 Jun 2007 20:18:54 -0700

There are two sets of concerns here.

First there is how to achieve the administrative effect desired.
Second there is how to work with DNSSEC without requiring changes.

Administrative wildcards are part of the DNS configuration file and NOT the DNS zone file that is transported by AXFR or whatever. If you are using DNSSEC you are in any case going to be using some form of tool to sign your zone. Expansion of administrative wildcards happens before the DNSSEC signature records are created.

In general if you are editing a file with the signature records in it you are probably doing something ill advised anyway.

> [mailto:[email-masked]] On Behalf Of 
> william(at)elan.net
> Sent: Saturday, June 02, 2007 8:17 PM
> To: Steve Atkins
> Cc: Untitled WG
> Subject: Re: [ietf-dkim] TXT wildcards SSP issues
> 
> 
> >> The problem is that you've just spec'ed SSP to use a 
> protocol that is 
> >> not DNS.  It's fairly similar to DNS, but it's not DNS.  I can't 
> > vice-versa. So, yeah, you're right about the standards 
> document issue 
> > (were it me, I'd just spec TXT records and not mention wildcards at 
> > all).
> >
> > I have a dns server that'll do internal wildcard records 
> today (as do 
> > you, IIRC). The information it uses to do that will not transfer 
> > correctly over AXFR - but who, other than some subset of 
> bind users, 
> > uses AXFR to maintain their secondaries, anyway? :)
> 
> If it was just AXFR all would be great. But in order to do 
> DNSSEC it is in fact necessary for servers to know how to 
> process wildcards and that means any local wildcard-like 
> MACROs have to be part of the spec.
> 
> --
> William Leibzon
> Elan Networks
> [email-masked]

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 2 Jun 2007 20:21:30 -0700

Steve,

Could you expand on this somewhat?

We may be able to push the beastly wildcard issue into touch altogether here.

What is the deployed base for MX . ? How widely is it recognized? Used?

> [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Saturday, June 02, 2007 6:51 PM
> To: Untitled WG
> It's not bind, though, and there's a fairly common fallacy at 
> IESG, amongst other places, that DNS is "what bind does" 
> rather than vice-versa. So, yeah, you're right about the 
> standards document issue (were it me, I'd just spec TXT 
> records and not mention wildcards at all).
> 
> today (as do you, IIRC). The information it uses to do that 
> will not transfer correctly over AXFR - but who, other than 
> some subset of bind users, uses AXFR to maintain their 
> secondaries, anyway? :)
> 
> SSP at all 
> How is "MX ." working out for you? Not a rhetorical question 
> - it's likely the closest we have to a standard for "I don't 
> send email"

---

From: Steve Atkins <[email-masked]>
Date: Sat, 2 Jun 2007 20:53:04 -0700

> We may be able to push the beastly wildcard issue into touch  

I suspect not, but it's worth a try.

> What is the deployed base for MX . ?

I've no idea. I have a zone file and some survey code, but haven't  
pointed
it at that question yet - it may be time to take a look.

> How widely is it recognized?

Fairly widely, I suspect, by spam filters that look for a deliverable  
email
address in the envelope from. All "MX ." does is provide an invalid
MX record that's easily recognized as being intentional (similar to
the .invalid pseudo-TLD in many respects).

http://ietfreport.isoc.org/idref/draft-delany-nullmx/ is the  
(expired) draft
that formalizes the concept, and it was somewhere between discussed
and common knowledge for at least a couple of years before it was
drafted in '05.

> Used?

Not as widely as I thought, apparently. I'm not sure.

Cheers,
   Steve

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 3 Jun 2007 05:42:21 -0700

>From a DNS perspective I don't like MX . As it falls into the category 'folklore', it is an essentially undocumented feature of the infrastructure known only to some.

>From the perspective of DKIM goals I would be entirely happy to document and make use of MX . as an interim measure.

In the longer term I would much prefer to see us defining a NOMAIL policy within DKIM.

Putting it all together we have two options for publishing policy:

1) If your DNS server does not support new RRs

	Specify DKIM policy 'I always sign' using the prefix TXT record at specifc nodes
	Specify NOMAIL policy 'I never send' using MX-dot (which can be wildcarded as normal)

2) If your DNS server does support new RRs 

	Specify DKIM policy 'I always sign' using the prefix TXT record
	Specify NOMAIL policy 'I never send' using the prefix TXT record
	Use XPTR to address the wildcard issue wherever necessary

The administrative wildcard issue is mostly an issue with the newer DNS servers. The DNS wildcard semantics were botched in the original RFC and there being no strong interoperability driver every server implemented in a different way.

The need for consistency only appeared with DNSSEC and that is when the wildcard semantics were redefined. Most DNS servers offer a choice of the old and 'standard' semantics. I don't think it should be too hard to persuade them to support administrative wildcards, something we need regardless of DKIM.

> Sent: Saturday, June 02, 2007 11:53 PM
> To: Untitled WG
> Subject: Re: MX dot RE: [ietf-dkim] TXT wildcards SSP issues
> 
> 
> I've no idea. I have a zone file and some survey code, but 
> haven't pointed it at that question yet - it may be time to 
> take a look.
> 
> Fairly widely, I suspect, by spam filters that look for a 
> deliverable email address in the envelope from. All "MX ." 
> does is provide an invalid MX record that's easily recognized 
> as being intentional (similar to the .invalid pseudo-TLD in 
> many respects).
> 
> that formalizes the concept, and it was somewhere between 
> discussed and common knowledge for at least a couple of years 
> before it was drafted in '05.
> 
> > Used?
>

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 3 Jun 2007 10:01:14 -0400

> SSP, so it's an interesting bit of data.

IMO it's a really odd idea as it causes DNS root queries by standards 
compliant MTAs and changes the semantics of MX (now all of a sudden MX 
relates to sending mail).

I've suggested before that if one wants a standardized "Sends no mail", an 
extract of the string literal for that from the SPF RFC (RFC 4408) could be 
pulled out and made a separate spec for that one meaning avoiding all the 
other baggage.  It's currently standardized and has significant deployment.

It isn't clear to me that either of these proposals though is meant to apply 
to message bodies.  I know SPF is aimed at the envelope, I that's what I 
would have thought for MX . too.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Sun, 3 Jun 2007 08:58:17 -0700

(Still way OT, but it's more interesting than SSP, eh?)

> relates to sending mail).

No, it shouldn't cause root queries.

No, it doesn't change the semantics of MX. It states "This domain does
not accept email", and does so in a standard fashion that is already
specified by the DNS RFCs. If the domain cannot receive email then
there cannot be "legitimate" email using that domain as the envelope
from. That's already common knowledge, as crystalized in many, many
spam filtering systems.

> other baggage.  It's currently standardized and has significant  

It's not a bad idea, but you again have a huge deployment problem
(as SPF deployment is decreasing, so you can't rely on piggybacking
on that).

The main advantage of MX . is that many places already support
it, as a side effect of their rejection of obviously bogus mail at  
receipt
time.

> would have thought for MX . too.

Yes, envelope. The primary goal is to stop bogus bounces. As has
been widely discussed before, constraining the payload of the mail
doesn't really do any good (the only thing it's even claimed to be
useful for is phishing, and it doesn't work there).

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Sun, 03 Jun 2007 09:02:55 -0700

> relates to sending mail).

Agreed.  MX . is a very bad idea.

> other baggage.  It's currently standardized and has significant deployment.

Why not simply No MX RR then No mail?

> would have thought for MX . too.

It really depends upon who is using SPF.  SPF expands macro constructs
which modify subsequent DNS transactions.  This means SPF might be
invoked again and again for each such application.  Repeated invocations
could be required for MAILFROM, PRA, DKIM domains, or EHLO.  Proponents
want to believe a 10 x (instead of a 100 x) increase in the number of
DNS transactions is not a problem.  However, whichever factor that might
be, multiply this factor again by the number of elements within a
message associated with SPF records, and then again by the number of
message local-parts within a spam run.  The DKIM WG should stay far far
way from SPF due to DDoS concerns.

The DKIM WG should understand the risk in using SPF records for
anything.  Add to these problems, a likely need to search for SPF
records.  Few SPF records are small enough to safely permit use of
wildcards.  Why not no MX RR, then No mail?

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 3 Jun 2007 12:06:06 -0400

On Sunday 03 June 2007 12:02, Douglas Otis wrote:

> Why not no MX RR, then No mail?

I can see deprecating implicit MX if there is an A, but that's an issue well 
outside the scope of this WG.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 3 Jun 2007 12:46:15 -0400

On Sunday 03 June 2007 11:58, Steve Atkins wrote:

> ... as SPF deployment is decreasing ...

I'm curious as to the basis for this statement as that's not consistent with 
the statistics I've seen.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Sun, 03 Jun 2007 09:51:07 -0700

> No, it shouldn't cause root queries.

Paul Vixie was fairly convincing in explaining why this construct caused
significant trouble when used with SRV RRs for indicating "No Service".
The SRV draft even documents the meaning of the "." construct from
inception.  Still, software must exclude interpreting this as a valid
host.  When seen as a valid host too often, this construct can not be
safely used, even when initially defined as "No Target."  For the MX
record, this field is defined as a valid host.  Use of this construct
would be expecting software to have the foresight to exclude ".".

Yahoo gets a fair number of queries for "http://www.yahoo.com" A IN
records which was fixed with a cname.  Ignorant software is everywhere,
why expect otherwise?  

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Sun, 03 Jun 2007 18:51:03 +0200

> the statistics I've seen.

Can we please NOT have the "mine is bigger than yours" argument now?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Sun, 03 Jun 2007 10:00:33 -0700

> outside the scope of this WG.

Good point, but this alone could reduce abuse by compromised systems,
especially when combined with DKIM MX/policy requirement.  Those wanting
their email accepted should be equally concerned about receiving their
email, even if they are FEMA. : )

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Sun, 3 Jun 2007 10:03:28 -0700

> records which was fixed with a cname.  Ignorant software is  

This is straying a long way from relevant to DKIM, so I'm not going to
try and explain the basics of DNS here.

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 3 Jun 2007 13:16:03 -0400

On Sunday 03 June 2007 12:51, Eliot Lear wrote:
> > I'm curious as to the basis for this statement as that's not consistent
> > with the statistics I've seen.
>

I don't want to have an arguement.  Stats are hard to come by and I'm 
genuinely curious.  Offlist is fine.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Sun, 3 Jun 2007 14:30:11 -0700

On Jun 3, 2007, at 10:03 AM, Steve Atkins wrote:

> This is straying a long way from relevant to DKIM, so I'm not going  
> to try and explain the basics of DNS here.

A query to "." returns a _root_ SOA record with a no answer  
response.  Each server which might attempt to resolve a "." host name  
will likely repeat the mistake.   There would be no cached record to  
lessen the frequency of these mistakes either.  Multiply the mistake  
by billions of spoofed messages being sent, and this starts looking  
more like a DDoS attack.  Any potential for creating a DDoS  
mechanism, intentionally or not, is relevant to DKIM.   A DDoS  
concern is very relevant when considering record searching methods  
and whether a hostname of "." safely signals "no service."

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 04 Jun 2007 13:10:32 +0100

> genuinely curious.  Offlist is fine.

Offlist is better since this is off topic.

We already decided NOT to include a requirement that SSP be able to
express the "nomail" practice. Let's spend the time elsewhere, where
we have issues to decide.

Stephen.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 04 Jun 2007 14:51:07 +0100

On Sun, 03 Jun 2007 22:30:11 +0100, Douglas Otis <[email-masked]>  
wrote:

> A query to "." returns a _root_ SOA record with a no answer response.   
> Each server which might attempt to resolve a "." host name will likely  
> repeat the mistake.   There would be no cached record to lessen the  
> frequency of these mistakes either.  Multiply the mistake by billions of  
> spoofed messages being sent, and this starts looking more like a DDoS  
> attack.  Any potential for creating a DDoS mechanism, intentionally or  
> not, is relevant to DKIM.   A DDoS concern is very relevant when  
> considering record searching methods and whether a hostname of "."  
> safely signals "no service."

Would it work if the MX record pointed to a domain such as nomail.invalid?  
That ought to get cached AFAIK.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 4 Jun 2007 07:08:18 -0700

> [mailto:[email-masked]] On Behalf Of Stephen Farrell

> We already decided NOT to include a requirement that SSP be 
> able to express the "nomail" practice. Let's spend the time 
> elsewhere, where we have issues to decide.

NOMAIL is out of scope, but wildcard is in scope.

The relevance here is that it looks like we can get 95% or better coverage of the real use cases here by acknowledging that wildcards are primarily an issue for NOMAIL.

Incidentally any DNS lookup is going to load the root zone. SenderID/SPF may be the interim solution here.

---

From: Damon <[email-masked]>
Date: Mon, 4 Jun 2007 11:12:47 -0400

Doug,

 Interesting idea. Can you provide an example of how this would work IRL?
I am confused about the "hash".

Regards,
Damon

---

From: Michael Thomas <[email-masked]>
Date: Mon, 04 Jun 2007 08:37:02 -0700

> The relevance here is that it looks like we can get 95% or better coverage of the real use cases here by acknowledging that wildcards are primarily an issue for NOMAIL.

It is? If I sign everything for my domain, I'd like to be able to say
that for both the top level domain, and all of the subdomains too,
right?

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Mon, 4 Jun 2007 10:49:49 -0700

On Jun 4, 2007, at 8:12 AM, Damon wrote:

>> What I am suggesting is a bit different.  As this label must have  
>> a prefix, why not allow the prefix to associate with another  
>> domain via a hash?  Check the existence of an MX record when no  
>> policy record is found.  When policy record lookup fails and the  
>> MX record exists (we are at two transactions), a third lookup  
>> could be for _dkim-all.<email-address-domain> to determine whether  
>> a lack of an association is acceptable.
>>
>> This approach represents the same number of transactions as  
>> suggested by Phillip, but also provides a means to curtail a  
>> replay-abuse and broken-signature bounce problem.  Doing this now  
>> ensures at most one additional transaction occurs.  This seems  
>> well worth it.
>
> Doug,
>

Several domains within components of an email may reference an  
originating administration.  This includes the EHLO, SMTP MAILFROM,  
the PRA, From, Sender, etc.  While the DKIM signature provides a  
means to authenticate who provided content, often this alone will not  
be enough to prevent a replay problem.  There is also a problem of  
bounces spoofing a DKIM signed message.  BATV allows spoofed bounces  
to be discarded.  But to use BATV, those using the email-address must  
always send through a system that adds the BATV signature.  In  
addition, BATV can not prevent the bounce traffic from being  
initially accepted either.

A better solution can handle the replay problem, and spoofed bounces,  
and any unsigned message that should be signed.

Senders would do the following:

a) Provide an MX record that does not use a wildcard.

b) Provide a default policy record.

c) Provide associated domain policy records.

Recipients can then do the following:

i) Check for the existence of MX record when no domain specific  
policy record exists.

ii) Check for the existence of a default policy record when an MX  
record exists.

When an MX record is not found for an email-domain, refuse the  
message. (See note below.)

When no policy record is found at the location of the MX record,  
there is no policy.

When a message is from a domain having replay abuse problems:	 
(Perhaps as indicated in originator's default policy.)

  - Check for a domain specific policy record for the EHLO hostname.

(Checking for a domain specific policy record would precede a check  
for a default policy when domain specific policies become common.)

When a message might be bounced by subsequent handling then: 	(This  
is only known by the recipient.)

  - Check for a domain specific policy record for the SMTP MAILFROM.

Hostname policies are located by:

  a) Excluding the leftmost label of hostname, and converting the  
remaining domain into a base32 encoded SHA1 hash.

  b) Adding a rightmost prefix to the hash indicating that the policy  
requested is for a hostname, such as:
	 _SMTP_H
	 _SMTP-ALL (default excludes leftmost hash)

  b) Placing the base32 encoded SHA1 hash of the domain and prefix  
below the originating email-domain in question.

When DKIM and email address domains differ, email-address domain  
policies are located by:

  a) Converting the DKIM domain into a base32 encoded SHA1 hash.

  b) Adding a prefix to the hash indicate the policy requested is for  
a specific field or parameter such as:

	_DKIM-MF
	_DKIM-PRA
	_DKIM-F
	_DKIM-S
	_DKIM-ALL (default excludes leftmost hash)

  b) Placing the base32 encoded SHA1 hash of the domain and prefix  
below the email-address domain in question.

When the default hostname policy indicates a message MUST be from an  
associated SMTP client, but the associated hostname policy does not  
exist, refuse the message.

When the default email-address domain policy indicates the email- 
address must be signed by an associated domain, but the associated  
DKIM domain policy does not exist, refuse the message.

Note:

When refusing messages that fail to have an MX record is decided to  
be too problematic, then all A and AAAA records must also include a  
default policy at the same level.  Such records will not collide with  
any existing records due to the prefix.  At least there is no  
searching for a record.  Hopefully, over time the use of A or AAAA  
records in place of MX records can be obsoleted to eliminate this  
need to publish policies at every A or AAAA record location.

-Doug

---

From: Damon <[email-masked]>
Date: Mon, 4 Jun 2007 19:35:11 -0400

> that for both the top level domain, and all of the subdomains too,

I think it is better to say, '*' means: ...and everything else.

So the subdomains that are not currently signed are covered under the '*' rule.
Which begs the question, if ~any~ subdomain is signed, wouldn't the
top level have to have to be signed even though it may be .nomail?

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Mon, 4 Jun 2007 17:49:57 -0700

On Jun 4, 2007, at 4:35 PM, Damon wrote:

>>
>> It is? If I sign everything for my domain, I'd like to be able to  
>> say that for both the top level domain, and all of the subdomains  
>> too, right?
>
> So the subdomains that are not currently signed are covered under  
> the '*' rule.  Which begs the question, if ~any~ subdomain is  
> signed, wouldn't the top level have to have to be signed even  
> though it may be .nomail?

An "all email signed" assertion creates an identical discovery  
problem as that of a statement of "no email sent."  "No email sent"  
is relevant to the DKIM process.  A "no email sent" assertion might  
provide protection against additional query traffic.  It might also  
provide recipients lower overhead when dealing with spoofed  
signatures.  It is not clear why a "no mail sent" assertion must be  
excluded from a policy statement.  Surely not every subdomain will be  
signing messages and sending email.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 05 Jun 2007 02:34:55 +0100

Douglas Otis wrote:
> It is
> not clear why a "no mail sent" assertion must be excluded from a policy 
> statement.  

Well... because that was the concensus. Feel free to re-read
the archive, but basically: End of story.

S.

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 05 Jun 2007 16:27:24 +0100

+1

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Mail

---

From: Steve Atkins <[email-masked]>
Date: Tue, 5 Jun 2007 08:42:52 -0700

On Jun 5, 2007, at 8:27 AM, J.D. Falk wrote:

>>> complexity in the system.  Going through both TXT *and* SSP  
>>> records seems like a recipe for synchronization problems and  
>>> other nasties that we could best do without.  And I could easily  
>>> be convinced by Peter Koch that a new record just isn't that hard  
>>> to get out there.
>> +1
>
> +1

+1.

I think that deploying a new RR isn't as trivial as has been claimed,  
but having TXT and something else just won't work well.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Tue, 5 Jun 2007 08:58:19 -0700

On Jun 4, 2007, at 6:34 PM, Stephen Farrell wrote:
> Douglas Otis wrote:
>>
>> It is not clear why a "no mail sent" assertion must be excluded  
>> from a policy statement.
>
> Well... because that was the concensus. Feel free to re-read the  
> archive, but basically: End of story.

Consensus does not necessarily produce a solution that improves  
security.

Making assertions of "no mail from a domain" remains an important  
aspect for protecting higher overheads in a DKIM process.  This  
assertion efficiently deals with spoofed messages.  Relegating this  
policy to SPF underlines a glaring lack of consideration given security!

Reactions regarding use of wildcards from DSN WGs have been  
predominately "Don't do it."  Limitations regarding new RRs are due  
to a corporate environment established as an integrated solution for  
a commonly desktop solution.  Even overcoming this barrier will still  
confront dangers associated with wildcard abuse.

Unlike other DNS records, wildcards can cause an infinite amount of  
uncached traffic, that while being cached, is not resolved from  
cache.  Often wildcards are utilized by bad actors to deploy random  
labels which happen to be more difficult to filter.  Otherwise  
innocent wildcards can also be exploited a component in some DDoS  
attack as well.

Over the last few years, spammers have  become more malevolent and  
organized.  Their skills can be measured by the growth and nature of  
their networks.  Malware and spam go hand in hand where SPF gives  
this population an effective tool for poisoning DNS or staging a DDoS  
attacks.  Unfortunately, wildcard records also becoming less safe as  
a result of this growing population.

The safe answer would be to require an MX record before accepting a  
message, and publish policy at this location.  As an interim  
solution, also publish policy at the location of other A records as  
well.  The XPTR or any other wildcard scheme will require that these  
records be placed at each and every node within a domain!  How can  
that be safe or sane?

-Doug

---

From: [email-masked]
Date: Tue, 5 Jun 2007 17:09:25 +0100 (IST)

> Consensus does not necessarily produce a solution that improves

Are you saying that you'd like to ignore the established
WG consensus and plan to continue on discussing this topic
on the DKIM WG list regardless of the fact that we've
thrashed this and one of the WG chairs has specifically
asked you to stop?

If the answer is anything synonymous with "no", there's
no need to respond, let's just move on. If the answer is
anything else, please send it to Barry and I off-list.

Stephen.

---

From: <[email-masked]>
Date: Tue, 5 Jun 2007 12:57:13 -0400

+1

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Tuesday, June 05, 2007 11:58 AM
To: Stephen Farrell
Cc: Scott Kitterman; [email-masked]
Subject: Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 12:58:52 -0400

Stephen,

hmmmmmmm,  they way you are stating this runs against what my final 
impression of the issue.

I was under the impression that the NO-MAIL question was not related to 
POLICY but how it was related to Phillip's extremely confusing proposal,
in other words, how a NO-MAIL expectation was DISCOVERED.

I specifically asked about this and I was corrected that I must of 
mis-read his proposal, which I still don't understand.

My position has been that you can discovered this via SSP and others 
argued that you can get the same result via the LACK OF A KEY.  The 
problem is the lack of a KEY doesn't necessarily expose the true intent 
and domain expectation.

I viewed it as an OPTIMIZATION concept since the ideal optimize model 
suggests the policy is obtained first in all cases.  I believe most 
agreed with that, but there were a few that militantly did not want to 
do an SSP first but we left that to be an implementation concept.

In any case, I never felt that this POLICY EXPECTATION was removed but 
that you don't need to do it via a POLICY but rather lack of a key.

In fact, I gave up my work with DSAP because I felt that Jim Fenton's 
SSP draft covered all the bases.  I told you guys this offlist.

If this was in FACT being removed, I would have never gave up on DSAP.

In any case, I wonder if people really understood what they were voting 
on.  I hope it wasn't a typical "follow the chieftain" path.

The DKIM "Policies Concept" design MUST include a "I NEVER SIGN"  or "NO 
SIGNATURE" domain expectation concept as a requirement.   This is a 
fundamental protection for the otherwise unprotected DKIM-BASE signature 
process and now that we are discussing wild cards and sub-domains, this 
no-signature idea becomes even more prevalent.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Tue, 5 Jun 2007 09:58:16 -0700

On Jun 5, 2007, at 9:09 AM, [email-masked] wrote:

> Are you saying that you'd like to ignore the established WG  
> consensus and plan to continue on discussing this topic on the DKIM  
> WG list regardless of the fact that we've thrashed this and one of  
> the WG chairs has specifically asked you to stop?
>
> If the answer is anything synonymous with "no", there's no need to  
> respond, let's just move on. If the answer is anything else, please  
> send it to Barry and I off-list.

Stephen and Barry,

My apologies.  Will all due respect, deciding WG issues individually  
in abstract rather than in respect to a complete strategy appears to  
be leading to poor outcome.  Perhaps that is why a camel is described  
as a horse designed by committee.  The _only_ issue worthy of  
discussion is whether the final result is as safe as possible.  That  
can not be determined on a piecemeal basis.  Analysis requires  
comparisons between whole strategies.  That is _not_ being done.

-Doug

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 5 Jun 2007 10:19:27 -0700

> From: Michael Thomas [mailto:[email-masked]] 

> > The relevance here is that it looks like we can get 95% or 
> better coverage of the real use cases here by acknowledging 
> that wildcards are primarily an issue for NOMAIL.
> 
> It is? If I sign everything for my domain, I'd like to be 
> able to say that for both the top level domain, and all of 
> the subdomains too, right?

Why would you be signing a subdomain that does not have an A record?

Come to that how does your understanding of DKIM policy work for a node that has no A record, no MX record and no related key records? If you have a policy 'I sign all mail' what restrictions do you impose on the key records?

I think that the corner cases for wildcarding seem to be falling into the category of support for NOMAIL and thus out of scope.

We already know how to wildcard NOMAIL. If we find that only 5% of domains actually need to wildcard a DKIM policy for domains that do not exist then we simply direct people to the existing solutions for declaring NOMAIL (MXdot, SenderID/SPF) that work with wildcard.

At that point we can solve 95% of all problems today with no infrastructure changes with the TXT/XPTR/TXT search, and the coverage will reach 100% in the future as infrastructure is upgraded.

We don't need to propose any thrashing about the DNS tree of the type that rightly upsets DNS folk. We set a clean precedent for the future. We get the benefit of an improved admin model. We build out infrastructure that is DNSSEC friendly.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 05 Jun 2007 10:54:09 -0700

> Come to that how does your understanding of DKIM policy work for a node that has no A record, no MX record and no related key records? If you have a policy 'I sign all mail' what restrictions do yo…

Huh?

Let's review the attack:

example.com: "I sign everything"

attacker sends mail purportedly from example.com. I look up example.com, 
get the "I sign everything" record, I know it is forged. All is good.

attacker then sends mail purportedly from alsdkfjasdf.example.com. I
look up policy for that node, and find nothing. All is not good.

If I use a wildcard as well:

*.example.com: "I sign everything"

It will cover all subdomains *except* ones that have an RR (usually an
A record). Thus, we need something that covers those nodes too. Hence
the tree walk, forcing those nodes to have the policy RR there too, etc.

I don't understand what you wrote above has to do with this attack.

		Mike

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 5 Jun 2007 11:05:23 -0700

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.

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.

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.

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.

> Sent: Tuesday, June 05, 2007 1:54 PM
> To: Hallam-Baker, Phillip
> Cc: Stephen Farrell; Scott Kitterman; [email-masked]
> Subject: Re: I think we can punt the hard stuff as out of scope.
> 
> >> better coverage of the real use cases here by acknowledging that 
> >> wildcards are primarily an issue for NOMAIL.
> >>
> able to say 
> > Come to that how does your understanding of DKIM policy 
> work for a node that has no A record, no MX record and no 
> related key records? If you have a policy 'I sign all mail' 
> what restrictions do you impose on the key records?
> 
> Huh?
> 
> Let's review the attack:
> 
> attacker sends mail purportedly from example.com. I look up 
> example.com, get the "I sign everything" record, I know it is 
> forged. All is good.
> 
> attacker then sends mail purportedly from 
> alsdkfjasdf.example.com. I look up policy for that node, and 
> find nothing. All is not good.
> 
> It will cover all subdomains *except* ones that have an RR 
> (usually an A record). Thus, we need something that covers 
> those nodes too. Hence the tree walk, forcing those nodes to 
> have the policy RR there too, etc.
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 05 Jun 2007 11:14:53 -0700

> 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.

   There is? What is the RFC #?

		Mike

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 5 Jun 2007 11:20:14 -0700

RFC 4405-8.

Since the requirement is out of scope we are fully within our rights to merely note the existence and widespread use of the scheme in a non-normative reference. 

> Sent: Tuesday, June 05, 2007 2:15 PM
> > 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.
> > 
> > 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.
> 
> > 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.
> > 
> > 
> > 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.
> > 
> > 
> related key 
> >> records? If you have a policy 'I sign all mail'
> >> example.com, get the "I sign everything" record, I know it 
> is forged. 
> >> All is good.
> >>
> alsdkfjasdf.example.com. I 
> (usually 
> >> an A record). Thus, we need something that covers those nodes too. 
> >> Hence the tree walk, forcing those nodes to have the 
> policy RR there 
> >> too, etc.
> >>

---

From: Douglas Otis <[email-masked]>
Date: Tue, 5 Jun 2007 11:27:17 -0700

On Jun 5, 2007, at 10:19 AM, Hallam-Baker, Phillip wrote:

> We already know how to wildcard NOMAIL. If we find that only 5% of  
> domains actually need to wildcard a DKIM policy for domains that do  
> not exist then we simply direct people to the existing solutions  
> for declaring NOMAIL (MXdot, SenderID/SPF) that work with wildcard.

Neither MX dot or SPF represents a safe solution!!!!  All unused sub- 
domains would be included in an assertion that implies "Don't bother  
processing a signature or mail from these domains, they're bogus."   
This means a 5% estimate is off by a large margin!

> At that point we can solve 95% of all problems today with no  
> infrastructure changes with the TXT/XPTR/TXT search, and the  
> coverage will reach 100% in the future as infrastructure is upgraded.

The XPTR solution requires a wildcard RR be published at _every_ DNS  
node.  There was little interest within the DNS WG to automate this  
construct.  This will also have a significant impact upon the size of  
a typical DNS zone and all the related caching.  It would be highly  
prudent to seek advice from the DNS WG on this matter.

> We don't need to propose any thrashing about the DNS tree of the  
> type that rightly upsets DNS folk. We set a clean precedent for the  
> future. We get the benefit of an improved admin model. We build out  
> infrastructure that is DNSSEC friendly.

Changes to infrastructure is not needed when the SMTP service and  
policy are anchored to the MX record.  Email represents a rather  
unique problem as it pushes a vast amount of information without  
prior arrangement.  It is not clear there are other protocols that  
benefit from introducing of a new type of DNS wildcard.  In each  
case, there are likely other solutions that impose less risk as most  
other protocols pull information.

As email is rather unique, it might be possible to establish an  
interim solution for email where policy is anchored to an A record.   
However, the adoption timeframe will be long, where obsoleting the  
use of A records as an alternative to MX records should also be  
possible when a little pressure is applied.  Less is more with  
respect to security.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 14:29:54 -0400

> going to ever be sent from there.

Of course not. the Policy would say NO MAIL is expected from this domain.

 > 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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 05 Jun 2007 11:31:54 -0700

> Since the requirement is out of scope we are fully within our rights to merely note the existence and widespread use of the scheme in a non-normative reference. 

Wait a minute. There is a requirement that we solve the problem of
something with an A record too that should be signed if it is
from that domain. A wildcarded SPF "I don't send mail" doesn't
solve that problem. Nice try though.

	Mike

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 14:47:31 -0400

Hallam-Baker, Phillip wrote:
> RFC 4405-8.
> 
> Since the requirement is out of scope we are fully within our rights
 > to merely note the existence and widespread use of the scheme in
 > a non-normative reference.

What does SUBMITTER protocol have to do with with SSP Lookups?

Do you realize that there are still MANY people who are 100% against 
using Microsoft's SENDER-ID? or even use SPF?

You can't BASE SSP lookups or Policices on SPF/SENDERID/SUBMITTER

Can we refrain from INTEGRATION ideas here?

DKIM/SSP must WORK as a POST SMTP concept. It can not depend on SMTP 
level ideas and you can't depend on RFC 2822 containing the Return-Path.

I don't see how ANY of these other ideas is RELATED to the issue at hand.

    - Lookup mechanisms
    - Signing Policies

Lets not mix apples and oranges.

-- 
Sincerely

Hector Santos, CTO

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 5 Jun 2007 11:52:44 -0700

In many parts of the world there are folk throwing rocks at each other or worse because they can't settle their differences. Why should that be a concern?

> From: Hector Santos [mailto:[email-masked]] 
> Sent: Tuesday, June 05, 2007 2:48 PM
> Cc: Michael Thomas; Scott Kitterman; [email-masked]
> Subject: Re: [ietf-dkim] RE: I think we can punt the hard 
> stuff as out of scope.
> 
>  > to merely note the existence and widespread use of the 
> scheme in  > a non-normative reference.
> 
> Do you realize that there are still MANY people who are 100% 
> against using Microsoft's SENDER-ID? or even use SPF?
> 
> DKIM/SSP must WORK as a POST SMTP concept. It can not depend 
> on SMTP level ideas and you can't depend on RFC 2822 
> containing the Return-Path.
>

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 14:55:16 -0400

Steve,

I see your point and concern.

If the WG is wanting a new RR, then my vote for a RR/TXT lookup order 
was just the most logical strategy, IMO.

On the other hand, the TXT record can contain an NEWRR=1 attribute that 
tells the client that the same info is available via an RR lookup, if 
its reliable for the client to use.  In this case, it would a TXT lookup 
first time concept.

I don't see that as a problem.

But again, my vote was only if the WG was moving towards a new RR idea. 
   Which I think it should as a long term stategy.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 15:23:09 -0400

Hallam-Baker, Phillip wrote:

> In many parts of the world there are folk throwing rocks at each other 
 > or worse because they can't settle their differences. Why should that be
 > a concern?

Spare me the rhetorical judo.

I think the PROMISING SSP and rather simple protocol has been hijacked 
with academic hogwash and now we got a rabid dog loose in the market 
running unprotected.

We need to get this solved pronto or risk DKIM-based becoming another 
DOMAINKEYS junk/bandwidth inducing generator systems - IGNORED.

You have not been very clear in your proposals or comments towards 
others, atleast not to me.  To me, you exhibited MIXED directions.

We have had lots of ideas here and many were well established feature 
list since day one and for the life in me, I don't quite understand why 
we are trying to CURE cancer when we can't!

In DSAP, I spelled it out very clear regarding some very fundamental 
security issues.

When a EMAIL comes in with a purported DKIM signature, there is a new 
level of security expectations with that transaction.  It is no longer 
an OLD LEGACY transaction.  The concept is akin to a client specifically 
using PORT 587 - when it does, there is a NEW LEVEL of LEGAL/AUTHORIZED 
expectations.   The server can do things that it can not on port 25.

If the domain did not send mail with that domain, a NO-MAIL will cover 
it.  If it signs everything, and it was not, a I ALWAYS SIGN covers 
that. If it doesn't sign mail and it was signed, then I NEVER SIGN 
covers that, etc. etc.   These are basic fundamental ideas.

Instead, we are lost in off-topic stuff, lack of expertise in DNS people 
telling us the best Lookup Methods and now we lost in the building of 
integrated product lines.  Come on, give me a break.  Lets get this 
thing finished.

Who is the DNS expert here?  Lets get the proper best idea and most 
practical method for lookup, recommend strategies, then lets over the 
syntax and get that completed.

Then we can begin voting on initial policies to offer.  But lets not get 
into stupid debates on whether a NO-MAIL POLICY is worthy or not.  Let 
the sysops decide if that it what they want or not.

-- 
Sincerely

Hector Santos, CTO

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 5 Jun 2007 12:29:34 -0700

Who is trying the rhetorical judo on whom?

NOMAIL is out of scope, wildcards for signature policy are not.

There are two deployment stories we need to be able to give, one that meets 95% of needs with legacy infrastructure support, the second that meets 100% of needs with a minor incremental change to the legacy infrastructure.

The second of these provides a slot ready made for NOMAIL, (and for STARTTLE, PGP and SMIME if you like).

I am meeting your set of requirements in full. I am just not doing so in such a way that my proposal is out of scope, that is all.

> Sent: Tuesday, June 05, 2007 3:23 PM
>  > or worse because they can't settle their differences. Why 
> should that be  > a concern?
> 
> I think the PROMISING SSP and rather simple protocol has been 
> hijacked with academic hogwash and now we got a rabid dog 
> loose in the market running unprotected.
> 
> We need to get this solved pronto or risk DKIM-based becoming 
> another DOMAINKEYS junk/bandwidth inducing generator systems 
> - IGNORED.
> 
> You have not been very clear in your proposals or comments 
> towards others, atleast not to me.  To me, you exhibited 
> MIXED directions.
> 
> We have had lots of ideas here and many were well established 
> feature list since day one and for the life in me, I don't 
> quite understand why we are trying to CURE cancer when we can't!
> 
> In DSAP, I spelled it out very clear regarding some very 
> fundamental security issues.
> 
> When a EMAIL comes in with a purported DKIM signature, there 
> is a new level of security expectations with that 
> transaction.  It is no longer an OLD LEGACY transaction.  The 
> concept is akin to a client specifically using PORT 587 - 
> when it does, there is a NEW LEVEL of LEGAL/AUTHORIZED 
> If the domain did not send mail with that domain, a NO-MAIL 
> will cover it.  If it signs everything, and it was not, a I 
> ALWAYS SIGN covers that. If it doesn't sign mail and it was 
> signed, then I NEVER SIGN 
> Instead, we are lost in off-topic stuff, lack of expertise in 
> DNS people telling us the best Lookup Methods and now we lost 
> in the building of integrated product lines.  Come on, give 
> me a break.  Lets get this thing finished.
> 
> Who is the DNS expert here?  Lets get the proper best idea 
> and most practical method for lookup, recommend strategies, 
> then lets over the syntax and get that completed.
> 
> Then we can begin voting on initial policies to offer.  But 
> lets not get into stupid debates on whether a NO-MAIL POLICY 
> is worthy or not.  Let the sysops decide if that it what they 
> want or not.
> 
> --
> Sincerely
> 
> Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 15:47:56 -0400

> NOMAIL is out of scope, wildcards for signature policy are not.

Deja-vu.  NOMAIL is not out of scope in SSP and you need to STOP saying 
it.   The CONFUSING VOTE that was taking - I still don't now show what 
it meant but it was not what it would to be removed from SSP!

> There are two deployment stories we need to be able to give, 
 > one that meets 95% of needs with legacy infrastructure support,
 > the second that meets 100% of needs with a minor incremental
 > change to the legacy infrastructure.

I don't see how SSP violates this principle.

> The second of these provides a slot ready made 
 > for NOMAIL, (and for STARTTLE, PGP and SMIME if you like).

Oy vey! So then it is not out of scope as you said.

> I am meeting your set of requirements in full. I am just 
 > not doing so in such a way that my proposal is out of scope,
 > that is all.

Well, I would like to know who proposed this lame rule that it should be 
out of scope when it wasn't and was clearly part of all the sepcs - SSP 
and DSAP specs.

If people voted under the disquise of a general "NO MAIL" concept across 
the board, well, it is clear now this is not what they voted for because 
you are making provisions for it.

I don't understand why is so secret. I don't want a NO-MAIL DKIM policy 
to be dependent on a KLUDGED MX concept or  LMAP support.

-- 
Sincerely

Hector Santos, CTO

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 5 Jun 2007 12:54:54 -0700

OK how about this as a plan

1) We do policy according to the view of scope currently being expressed by the chairs and myself.
2) You and I submit a four page ID that registers a NOMAIL policy for DKIM.
3) The group decides whether to accept the paragraph of text into the text of the main draft or not during the Draft phase.

> Sent: Tuesday, June 05, 2007 3:48 PM
>  > one that meets 95% of needs with legacy infrastructure 
> support,  > the second that meets 100% of needs with a minor 
> incremental  > change to the legacy infrastructure.
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 05 Jun 2007 21:26:50 +0100

I have no objection to that.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 05 Jun 2007 21:31:16 +0100

Hector,

Tomorrow I'll dig through the archive and find the reference
for where we agreed that the "nomail" requirement text that was
previously in the ssp-reqs draft would be excised.

If someone in an earlier TZ wants to do that in the meantime,
you'll have my thanks,
S.

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 16:44:31 -0400

> 3) The group decides whether to accept the paragraph of text into the text of the main draft or not during the Draft phase.

You see, more rhetorical judo.  You're not intimidating no one Phil. 
Why four?  Why not SIX? or TEN?

I have a better idea. Since the work already done, I can just reissue 
DSAP I-D and if the chairs do no want to consider it, begin promoting 
this independently as an alternative SSP/XPTR solution?

Might not be a bad idea since I can model this as an abstract model and 
give sysops a choice to use DSAP, SSP/XPTR.  We can get it implemented 
into our system, finally turn on the DKIM switch, release it and 
instantly get thousands of Wildcat! systems using it.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 16:52:23 -0400

> previously in the ssp-reqs draft would be excised.

I don't recall that at all.   The issue as I recall, and it was 
confusing, was that it would not be part of Phillips's what seem be a 
DOMAIN discovery concept.  I do recall that I debated Phillip on his 
out of scope statements and I recall a confusing response that it wasn't 
what I thought.

But now he just admitted himself that his proposal does have provisions 
to create a slot for it - whatever that means.

I seriously doubt people had a handle of what they were voting on, and I 
wouldn't be surprise if it was a "follow the chieftain" vote taken.

-- 
Sincerely

Hector Santos, CTO

---

From: <[email-masked]>
Date: Tue, 5 Jun 2007 16:57:41 -0400

Edit/draft follows
The result of a Sender Signing Policy Check is one of five possible
   policies:

      (1) Some messages from this entity are not signed; the message
      SHOULD be presumed to be legitimate in the absence of a valid
      signature.  This is the default policy.

      (2) All messages from this entity are signed; all messages from
      this entity SHOULD have a valid signature, either directly on
      behalf of the originator or on behalf of a third party (e.g., a
      mailing list or an outsourcing house) handling the message.

      (3) All valid messages from this entity are signed, and SHOULD
      have a valid signature from this entity.  Third-party signatures
      SHOULD not be accepted.

      (4) Signing policy for this domain is expressed at the individual
      address level.  A second Sender Signing Policy Check should be
      performed specifying the individual address
      
      (5) This Domain does not send messages/This domain only signs third party messages

Done, now the rest of the WG should be happy
thanks,
Bill

---

From: Damon <[email-masked]>
Date: Tue, 5 Jun 2007 17:04:43 -0400

> no-signature idea becomes even more prevalent.

I hope someone can straighten me out on this because I am getting a
little confused.
There is a difference between "I Never Sign" and "I send no mail".
While I actually support BOTH, I didn't think that "I Never Sign" was
in question.
Is it?

Regards,
Damon Sauer

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 5 Jun 2007 14:12:04 -0700

Now add the three pages of boilerplate.

That is why I said four. 

> Sent: Tuesday, June 05, 2007 5:10 PM
> To: [email-masked]
> Cc: Hallam-Baker, Phillip; [email-masked]; 
> [email-masked]
> stuff as out ofscope.
> Its not 4 pages!!! <grin>
> 
> Good show Bill!
> 
> 
> --
> Sincerely
> 
> Hector Santos, CTO
> [email-masked] wrote:
> > Edit/draft follows
> > Done, now the rest of the WG should be happy thanks, Bill
> > 
> > 
> > 
> > 
> > 
> > 1) We do policy according to the view of scope currently 
> being expressed by the chairs and myself.
> > 3) The group decides whether to accept the paragraph of 
> text into the text of the main draft or not during the Draft phase.
> > 
> > 
> > 
> >> Subject: Re: [ietf-dkim] RE: I think we can punt the hard stuff as 
> >> out of scope.
> >>
> support,  > 
> >> the second that meets 100% of needs with a minor incremental  > 
> >>  > not doing so in such a way that my proposal is out of scope,  > 
> >> that is all.
> >>
> >> Well, I would like to know who proposed this lame rule 
> that it should 
> >> be out of scope when it wasn't and was clearly part of all 
> the sepcs 
> >> - SSP and DSAP specs.
> >>
> >> the board, well, it is clear now this is not what they voted for 
> >> because you are making provisions for it.
> >>
> >> I don't understand why is so secret. I don't want a NO-MAIL DKIM 
> >> policy to be dependent on a KLUDGED MX concept or  LMAP support.
> >>
> >>
> >> --
> >> Sincerely
> >>
> >> Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 17:10:17 -0400

Good show Bill!

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 17:25:26 -0400

Damon,

You're right. I meant the NO-MAIL policy in my paragraph below.  To me, 
the fundamental "natural laws" for DKIM or any SIGNING concept is:

    - I ALWAYS SIGN THIS DOMAIN

    - I NEVER SIGN THIS DOMAIN

    - SIGNED OR NOT SIGNED, DO NOT EXPECT MAIL FROM THIS DOMAIN -
      WE DON'T USE THIS DOMAIN FOR EMAIL. PERIOD.

    - NO ONE BUT MY DOMAIN SIGNS (no 3rd parties)

    - OTHERS CAN SIGN (Preferably from an authorized list)

It really has nothing to do with the validity of the signature.  The 
mere fact that one of the above may conflict with the domain 
expectations is a protocol violation in itself.

And what is very important, which what DSAP was all about, they can all 
easily happen naturally in practice directly and indirectly - hence a 
security issue.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 17:29:15 -0400

Yeah, but don't you see Phillip, this was already done, in SSP for each 
of its drafts, and in DSAP in its expired draft.

Why are we wasting time trying to remove this NO MAIL concept? So that 
you can just create a slot later on in your spec?

I don't get it.

-- 
Sincerely

Hector Santos, CTO

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 5 Jun 2007 14:31:49 -0700

I am trying to punt the wildcard baggage and tree traversal bagage that is being acreted to meet a requirement that is out of scope. 

> Sent: Tuesday, June 05, 2007 5:29 PM
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Yeah, but don't you see Phillip, this was already done, in 
> SSP for each of its drafts, and in DSAP in its expired draft.
> 
> Why are we wasting time trying to remove this NO MAIL 
> concept? So that you can just create a slot later on in your spec?
> 
> I don't get it.
> 
> --
> Sincerely
> 
> Hector Santos, CTO
> >> out ofscope.
> >>>       (5) This Domain does not send messages/This domain 
> only signs 
> >>> third party messages
> >>>
> >>>

---

From: <[email-masked]>
Date: Tue, 5 Jun 2007 17:47:06 -0400

consider it punted
however the same tree/wildcard issue exists to get any policy statement so lets try to think our way out of it. We have policies we want either 1-4 or in my case 1-5 so lets get them extracted without ddosing DNS
thanks,
Bill

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 18:06:30 -0400

Hallam-Baker, Phillip wrote:

> I am trying to punt the wildcard baggage and tree traversal 
 > bagage that is being acreted to meet a requirement that is
 > out of scope.

But what does this have to do with what kind of policy exposes once the 
records are discovered by any method eventually used?

The bottom line is once a domain is discovered, it will have some basic 
ideal boundary conditions:

     - OPTIONAL
     - MUST SIGN
     - NEVER SIGN
     - NO MAIL

plus the no discovery definition:

     - Interdeterminate  (NX_DOMAIN)

I don't care what METHOD is invented to get that information, they all 
work with a basic BLACK BOX model concept returning the same output:

     POLICY = LOOKUP_METHOD(DOMAIN)

We already established the DOMAIN::POLICY association and relationship.

We need a LOOKUP_METHOD - the function generator!!

It seems to me, you are trying to mixed or blend in policy definition 
with the lookup method, maybe in the hope to find some simplicity?

Well, it seems to me, this is restricting real practical policy 
potential and just slowing this process down.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Tue, 5 Jun 2007 15:52:26 -0700

On Jun 5, 2007, at 2:47 PM, <[email-masked]> <[email-masked]>  
wrote:

> consider it punted
> however the same tree/wildcard issue exists to get any policy  
> statement so lets try to think our way out of it. We have policies  
> we want either 1-4 or in my case 1-5 so lets get them extracted  
> without ddosing DNS

Agreed.

Security concerns regarding the SPF experimental draft should  
preclude this mechanism from playing any role in establishing a  
functional DKIM policy assertion.

A single policy record placed adjacent to the domain's MX record  
could be sufficient.  This would eliminate domain transversals or  
wildcard search mechanisms.  However, this approach creates a need to  
obsolete the use of just A records as an SMTP server discovery/ 
confirmation method.  Once an A record discovery/confirmation has  
been obsoleted, then messages might not be accepted when the email- 
address domain is not confirmed by the existence of an MX record.

How many SMTP servers already meet and even make this a requirement  
now?  The few cases where just an A record is available is likely  
already problematic due to high levels of abuse.  How many Fortune  
1000 companies do not publish MX records?

What is _in_ the DKIM policy statement is less critical than what  
other _experimental_ schemes might be expected of recipients for  
determining a complete DKIM policy.

Once in place and defined, policy can then be safely extended to  
authorizes other originating domains, perhaps by using various hash  
prefixes.  The hash prefix approach scales well and has a rather low  
overhead.  The initial DKIM policy record would simply be the  
"default".   Perhaps this could be called the DKIM-ALL policy. : )

-Doug

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2007 08:16:22 -0400

Douglas Otis wrote:
> 
> A single policy record placed adjacent to the domain's MX record could 
> be sufficient.  This would eliminate domain transversals or wildcard 
> search mechanisms.  However, this approach creates a need to obsolete 
> the use of just A records as an SMTP server discovery/confirmation 
> method.  Once an A record discovery/confirmation has been obsoleted, 
> then messages might not be accepted when the email-address domain is not 
> confirmed by the existence of an MX record.

Doug,

The MX/CNAME/A discovery process is long established process and part of 
the SMTP standard for millions of systems world wide, not just the 
Fortune 10, 500, 1000 or 10,000, and it includes legitimate systems with 
no MX records but with a CNAME or A record.

And you want to change this long established methodology for SSP purposes?

You're kidding right?

-- 
Sincerely

Hector Santos, CTO

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 06 Jun 2007 13:58:09 +0100

> no-signature idea becomes even more prevalent.
+1 (assuming s/I NEVER SIGN/NO-MAIL/)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Jun 2007 14:45:41 +0100

> If someone in an earlier TZ wants to do that in the meantime,

No volunteers eh;-)

So I went back in time and found:

Issue 1365 [1] included a mention that we could/shoud
delete the "never send mail" item.

That was raised by Eric on the list [2] in February and
dicussed at length.

Following that discussion I started a strawpoll [3] that
resulted in a 2:1 ratio [4] in favour of deprecating the
feature in SSP.

That's all nice and clear so "nomail" is out of scope, as
the WG agreed, even if not overwhelmingly. It seems like
all of the people who wanted to keep the feature then still
do, and I've not noticed anyone changing their mind. So,
there's no reason to reopen this that I can see.

So let's be grown-ups and move on,
Stephen.

[1] https://rt.psg.com/Ticket/Display.html?id=1365
[2] http://mipassoc.org/pipermail/ietf-dkim/2007q1/007139.html
[3] http://mipassoc.org/pipermail/ietf-dkim/2007q1/007185.html
[4] http://mipassoc.org/pipermail/ietf-dkim/2007q1/007254.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Wed, 6 Jun 2007 09:54:34 -0400

A friend with a small local mail server that ONLY sent out good,
legitimate mail was blocked by almost everyone for lack of an MX record.
Old days are gone.
thanks

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-----Original Message-----
From: Hector Santos [mailto:[email-masked]] 
Sent: Wednesday, June 06, 2007 8:16 AM
To: Douglas Otis
Cc: Oxley, Bill (CCI-Atlanta); IETF DKIM WG
Subject: Re: [ietf-dkim] RE: I think we can punt the hard stuff as out
ofscope.

Doug,

And you want to change this long established methodology for SSP
purposes?

You're kidding right?

-- 
Sincerely

Hector Santos, CTO

---

From: Damon <[email-masked]>
Date: Wed, 6 Jun 2007 09:54:28 -0400

> easily happen naturally in practice directly and indirectly - hence a

Agreed. We are on the same page.
However, does "I sign no mail" mean "I send no mail"?
I don't think it does, but I think this is a source of confusion
because I have seen the terms mixed several times.

Regards,
Damon Sauer

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2007 10:18:45 -0400

Grown up?

Stephen,

I don't think the whatever the STRAWPOLL was based on, it was VERY clear.

Going back, I can now see that it appears this was for the REQUIREMENTS 
not for a SSP proposal itself.

The issue came about MUST NOT REQUIRE THAT SSP LOOKUP BE FIRST.

We debated this back and forth as well and it was made clear that 
requirement does not MEAN proposals can not include such logic.

It does not SAY that a "SSP" proposal MUST NOT include a NOMAIL provision.

You are making it sound that it MUST NOT include a NOMAIL provision 
which is 100% uncategorily wrong.

And now it is clear the issue was not poised correctly. Based on your 
footnotes below, the question was brought up because some one felt 
(incorrectly) that it was a specific form of "strict."

     5.3 (2): IIRC we've identified "never send mail" as a special
     case of "strict", and then just not sending mail, let
     alone signing it. IMO you can delete this point.

if this is basis of the issue, it was INCORRECTLY though out.

There is no relationship with STRICT and NOMAIL.  STRICT is related to 
exclusive SIGNING or NO SIGNING which is different than NO MAIL.

The point is simple:

It doesn't make sense to REMOVE a NOMAIL policy.  If a domain is based 
forged with fake signatures, why should a VERIFIER be left with the 
overhead of processing FAILED signature without any recourse of simply 
DELETING this MAIL?

If the DOMAIN says, there SHOULD BE NO MAIL based on this DOMAIN, then 
that is a CLEAR indicator of abuse which the verifier should delete. It 
protects the verifier and it protects the domain.

We can't say NO SIGNATURE is equivalent to NO MAIL, but that is not 
enough to handle this type of abusive mail.

If I receive an email with an domain such as:

       secured.cs.tcd.de

and it is NOT signed, the DOMAIN can clearly TELL me whether this is 
expected or not:

    1  - This message MUST NEVER be signed

    2  - This message MUST ALWAYS be signed

    3  - This message MAY be signed

    4  - This messages MUST never have secure.cs.tcd.de because
         we DON'T send mail with this this domain.

With 1 and 3, the message is acceptable, with 2 and 4, I can mark this 
message is bad or maybe get rid of this junk.

The #4 is important because this is a HIGH POTENTIAL transaction once 
domains begin to turn on there DKIM system. There will be many currently 
exploited domains that will come in with no signatures and unless they 
all do #2, #4 is the only way to cleanly with NO FALSE positives, to get 
rid of this abuse.

-- 
Sincerely

Hector Santos, CTO

---

From: <[email-masked]>
Date: Wed, 6 Jun 2007 10:24:46 -0400

(1) Some messages from this entity are not signed; 
 the message  SHOULD be presumed to be legitimate in the absence 
of a valid signature.  This is the default policy.
2) All messages from this entity are signed; all messages from
this entity SHOULD have a valid signature, either directly on
behalf of the originator or on behalf of a third
arty (e.g., a mailing list or an outsourcing house) handling the
message.
(3) All valid messages from this entity are signed, and SHOULD
have a valid signature from this entity.  Third-party signatures
SHOULD not be accepted.
4) Signing policy for this domain is expressed at the individual
address level.  A second Sender Signing Policy Check should be
performed specifying the individual address      
(5) This Domain does not send messages/This domain only signs 
third party messages
(6) yer sister resembles a goat

Policy assertion 5 and 6 harm no one, please some and voting is
something you do repeatedly to get the result you want. Some here assert
that policy assertion 5 can be done elsewhere. I was under the
assumption that SSP sender's signing policy was to be complete. If I
cannot assert that I sign but never send, the SSP is not complete.
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
Sent: Wednesday, June 06, 2007 9:46 AM

No volunteers eh;-)

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2007 10:27:31 -0400

I don't think so. This is NOT standard practice.

Now, if you said no CNAME and A records, otherwise a PURE NXDOMAIN, then 
yes, there is a growth in these types of ANTI-SPAM techniques.

We do it ourselves in our WCSAP package with includes CBV.   If there is 
  no MX/CNAME/A, the transaction is rejected with a 45x.

This works nicely with a similar GREYLISTING effect because the BAD GUYS 
do not try again.  The GOOD GUYS do have legitimate setup.

Finally, in the past week we been helping a new customer and he didn't 
have his MX record setup and he still doesn't as of today.

The fact that we been communicating back and forth via our support email 
channel means that the A record fallback is STILL an EXPECTED standard 
in SMTP.    If we used this MX only idea, we would never be able to 
communication with him.

Anyway, I'm not saying you can't use this technique as part of a total 
ANTI-SPAM concept,  but that it shouldn't be part of the SSP concept.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2007 10:36:05 -0400

> legitimate mail was blocked by almost everyone for lack of an MX record.

Bill,

As you saying, that as part as the SSP specification, that it include a 
MX requirement and that the LACK of ONE is a new basis for rejection 
based on a SSP requirement for SMTP?

-- 
Sincerely

Hector Santos, CTO

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Jun 2007 15:44:32 +0100

Hector,

You are correct that there is no MUST NOT. But the fact
that we excised the MUST is significant. I interpret that
as follows:

- Its ok for someone to develop a proposal for how nomail
could be included, so long as it doesn't get in the way
of the meeting the MUST & SHOULD requirements, which we
do first (that's sort-of what PHB suggested yesterday, I
think);
- its not ok to hold up work on the basis that nomail
isn't included.

Later in your mail you seem to say that there was some
ambiguity when we decided the above. I totally disagree
with that - the mail archive is very clear.

Regards,
Stephen.

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2007 10:56:09 -0400

> with that - the mail archive is very clear.

First, I disagree. It wasn't very clear.  The mere fact you are still 
having this issue, proves the point.   Its common sense, if I don't send 
mail (signed or unsigned) with a particular domain, then the DKIM 
VERIFIER and DKIM DOMAIN should be subject to this type of abuse which 
will be naturally be very common which people begin to switch on DKIM.

There were decisions made offlist and in the chat room where there was 
clearly mis-representation.

Second,  I take offense to the insinuation that I am holding up work 
here.   The current approach is whats holding things up. Not me. We are 
now talking about MX methods, SPF and SENDERID methods, with incorrect 
statements that there are well established current methods to achieve 
the NO MAIL policy, or that it is the same as "STRICT", when it is not. 
  If these the basis for eliminating NOMAIL, then the issue was 
presented incorrectly, the straw poll was based on incorrect poising of 
the questios.  This approach was wrong and that is keeping this group 
from moving on.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2007 10:58:54 -0400

> because I have seen the terms mixed several times.

I don't think it does either and yes, this is a source of the confusion 
and it was incorrectly proposed by someone as an issue.

-- 
Sincerely

Hector Santos, CTO

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Jun 2007 16:35:20 +0100

Hector Santos wrote:
> having this issue, proves the point.   

What I see happening is folks who lost an argument trying to
re-open it.

> clearly mis-representation.

I've no idea how you can make that assertion. It is incorrect.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Jun 2007 09:20:56 -0700

Agreed.

Obtaining comprehensive DKIM policy to efficiently establish DKIM's  
disposition of a message should not _require_ processing sets of  
disjointed records.

That necessary to obtain an optimal DKIM handling process _should_ be  
included within DKIM policy.  An iterative process of selecting  
policy items in abstract does not provide clarity in regard to the  
overall process.  Reviewing the overall process appears to be what is  
_desperately_ needed.

To that end:

Obsoleting the A record discovery process will establish one location  
for _any_ email related policy record, and not just that for DKIM.   
Rather than allowing email to create large volumes of unnecessary  
queries (spam is often responsible for >90% of this), email should  
drop a now very problematic option causing dangerous domain  
transversals or excessive use of wildcards.  This simplification  
represents a significant reduction in DDoS related risks and gives  
email a fighting chance.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2007 12:18:57 -0400

> What I see happening is folks who lost an argument trying to

What arguments?  You preemptively prevented any argument and chastised 
anyone (ME) who had any comments.  You strictly wanted a +/- 1 straw 
poll" with no comments - thats clearly promotes a "follow a chieftain" 
poll path.

In addition, thats the point, I was under the impression it was never 
lost because it was already part of two specs. But rather it was a more 
about semantics for the requirements document:

      - DESIGNS MUST NOT REQUIRE A NO-MAIL POLICY

is the not the same as:

      - DESIGNS MUST NEVER INCLUDE A NO-MAIL POLICY

Instead what has clearly happen is that a decision was misinterpreted as 
gospel and 100% out of scope by Phillip and now yourself.  Not making it 
a requirement for a particular DKIM Policy Protocol Proposal such as 
XPTR is an acceptable idea, but Phillip is doing so by saying NOMAIL is 
OUT OF SCOPE is wrong.

Saying NOMAIL is out of scope is SIMPLY incorrect.  It is part of SSP 
and DSAP.

What I was concern about has materialized. Now I am afraid the same will 
happen with the NOT REQUIRED TO LOOKUP SSP issue as well which is 
clearly something I am not following in my design. I will lookup the SSP 
  policy ALWAYS and I am hoping for a DNS lookup method that will 
optimized this.

Finally, I gave up on DSAP 100% because Jim's new SSP draft covered all 
the basic ideas.  NO MAIL is important part of it.  Using the low 
censensus decisions for a Requirement Documents provision as a reason to 
remove it from the SSP specs was the last thing I expected.

-- 
Sincerely

Hector Santos, CTO

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Jun 2007 17:36:14 +0100

Hector Santos wrote:
> What arguments?  

See reference [2] from my earlier mail - its the start of a long
thread.

The rest has been dealt with already, other than:

 > Using the low

If people who wanted to remove the requirement, were in agreement
about including the feature, that'd be interesting. All I see so far
are those who wanted the requirement in, still wanting it in.

This discussion uses up the attention span of the list and distracts
from possible progress towards resolution of the issues Jim wanted
discussed. If we can sort out those then I'll be much more open
to coming back to this kind of thing later on.

We have a requirements draft that's been through WGLC. Let's produce
a protocol that meets that set of MUSTs.

Then by all means you can suggest we revisit the nomail issue, but
not now.

S.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Jun 2007 11:51:22 -0700

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, 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. However I am quite happy for expression of NOMAIL to require deployment of an XPTR capable DNS server.

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. 

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.

> Sent: Wednesday, June 06, 2007 10:45 AM
> To: Hector Santos
> You are correct that there is no MUST NOT. But the fact that 
> we excised the MUST is significant. I interpret that as follows:
> 
> could be included, so long as it doesn't get in the way of 
> the meeting the MUST & SHOULD requirements, which we do first 
> (that's sort-of what PHB suggested yesterday, I think);
> - its not ok to hold up work on the basis that nomail isn't included.
> 
> ambiguity when we decided the above. I totally disagree with 
> that - the mail archive is very clear.
> 
> Regards,
> Stephen.
> 
> Hector Santos wrote:
> > Grown up?
> > 
> > Stephen,
> > 
> > Going back, I can now see that it appears this was for the 
> > REQUIREMENTS not for a SSP proposal itself.
> > 
> > that is a CLEAR indicator of abuse which the verifier 
> should delete. 
> > It protects the verifier and it protects the domain.
> > 
> > domains begin to turn on there DKIM system. There will be many 
> > currently exploited domains that will come in with no 
> signatures and 
> > unless they all do #2, #4 is the only way to cleanly with NO FALSE 
> > positives, to get rid of this abuse.
> > 
> >

---

From: Michael Thomas <[email-masked]>
Date: Wed, 06 Jun 2007 12:06:25 -0700

> 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.

It's an interesting tact to claim that you can solve the subdomain
attack by saying that the top level of a domain can be set to "I sign
everything" and all subdomains set to "No mail". However, they aren't
semantically equivalent and they most assuredly do not meet the actual
requirement that all subnodes be covered. I suggest we stop mudding the
waters here as it's not helpful.

		Mike

---

From: Jon Callas <[email-masked]>
Date: Wed, 6 Jun 2007 14:41:16 -0700

I have a huge fear that I am beating a dead horse down a rathole. I  
also fear that I no longer understand what's being discussed.  
However, I want to make a cryptographic observation.

If you create a suitably-sized RSA key, throw away the private key,  
and put the public key in a DKIM selector, you have made a selector  
that can't have mail signed from it (or if you want to be really  
anal, forging a signature for that selector is equivalent to breaking  
that key).

If you then say, "I sign all mail" for any domain pointing to that  
selector, you've effectively made a cryptographically enforced no- 
mail, no-use, etc. domain using the existing Tinkertoys.

In short -- saying "I sign everything" with a non-existent or bogus  
key is the same thing as saying, "You'll never see a valid one of  
these."

	Jon

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2007 17:49:51 -0400

Hallam-Baker, Phillip wrote:

 > 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

---

From: Steve Atkins <[email-masked]>
Date: Wed, 6 Jun 2007 14:55:16 -0700

On Jun 6, 2007, at 2:41 PM, Jon Callas wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Yup. I think everyone (mostly) understands this. The entertainment
arrives when you want to be able to have a single policy record
refer to a large number of subdomains via wildcard.

The line of reasoning goes something like this:

1. We can already say "NO MAIL" any time we can say
    "NO UNENCRYPTED MAIL".

2. We kinda know how to say "NO UNENCRYPTED MAIL"
   for a single domain.

3. There are a few tricky issues with being able to say
    "NO UNENCRYPTED MAIL" across large numbers
   of domains via wildcard.

4. But the vast majority of cases where we'd want to say
   "NO UNENCRYPTED MAIL" for a wildcard all we really
   want to say is "NO MAIL".

5. So if we can say "NO MAIL" for a wildcard via some other
   protocol we don't need to be able to say "NO
   UNENCRYPTED MAIL" via wildcard, and can avoid the
   tedium referred to in point 3.

I don't believe point 4 is entirely valid, myself, but that's
the line of reasoning, and why people are bringing up
wildcards and "NO MAIL" in the same discussion.

Cheers,
   Steve

---

From: <[email-masked]>
Date: Wed, 6 Jun 2007 17:55:16 -0400

-----Original Message-----
From: [email-masked] on behalf of Jon Callas
Sent: Wed 6/6/2007 5:41 PM
To: IETF DKIM WG
Subject: Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues

	Jon

/me is impressed excellent kiss solution thanks, 
bill

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2007 18:01:23 -0400

> key is the same thing as saying, "You'll never see a valid one of  

The problem is DKIM-BASE mandate of

       'IGNORE FAILURES'

By having an implicit "NO MAIL" policy as the original SSP specs had as 
well as DSAP, it clearly marked the very strong policy concept of what 
the DOMAIN expected.

In other words, saying "I signed Everything",  failed mail does not 
protect the domain from a exploited domain that should had NEVER been 
used in the first place.

If we are willing to fold the failed "I signed Everything" transactions, 
as a clear rejectable transaction, then you are right.  It can work, but 
it a WEAKER statement with some "possibility" for false positive.  With 
a NO-MAIL policy, you have 100% NO FALSE positives.

-- 
Sincerely

Hector Santos, CTO

---

From: Damon <[email-masked]>
Date: Wed, 6 Jun 2007 18:08:48 -0400

> key is the same thing as saying, "You'll never see a valid one of

Jon,

 Horse of a different color that has already been hammered down another hole.
 A message with a broken sig - while less tasty - is still valid message.

In general, verifiers SHOULD NOT reject messages solely on the basis
   of a lack of signature or an unverifiable signature; such rejection
   would cause severe interoperability problems.  However, if the
   verifier does opt to reject such messages (for example, when
   communicating with a peer who, by prior agreement, agrees to only
   send signed messages), and the verifier runs synchronously with the
   SMTP session and a signature is missing or does not verify, the MTA
   SHOULD use a 550/5.7.x reply code.

   If it is not possible to fetch the public key, perhaps because the
   key server is not available, a temporary failure message MAY be
   generated using a 451/4.7.5 reply code, such as:

      451 4.7.5 Unable to verify signature - key server unavailable

   Temporary failures such as inability to access the key server or
   other external service are the only conditions that SHOULD use a 4xx
   SMTP reply code.  In particular, cryptographic signature verification
   failures MUST NOT return 4xx SMTP replies.

   Once the signature has been verified, that information MUST be
   conveyed to higher-level systems (such as explicit allow/whitelists
   and reputation systems) and/or to the end user.  If the message is
   signed on behalf of any address other than that in the From: header
   field, the mail system SHOULD take pains to ensure that the actual
   signing identity is clear to the reader.

   The verifier MAY treat unsigned header fields with extreme
   skepticism, including marking them as untrusted or even deleting them
   before display to the end user.

-Also-

8.7.  Intentionally Malformed Key Records

   It is possible for an attacker to publish key records in DNS that are
   intentionally malformed, with the intent of causing a denial-of-
   service attack on a non-robust verifier implementation.  The attacker
   could then cause a verifier to read the malformed key record by
   sending a message to one of its users referencing the malformed
   record in a (not necessarily valid) signature.  Verifiers MUST
   thoroughly verify all key records retrieved from the DNS and be
   robust against intentionally as well as unintentionally malformed key
   records.

8.8.  Intentionally Malformed DKIM-Signature Header Fields

   Verifiers MUST be prepared to receive messages with malformed DKIM-
   Signature header fields, and thoroughly verify the header field
   before depending on any of its contents.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 06 Jun 2007 15:17:04 -0700

> wildcards and "NO MAIL" in the same discussion.

First: s/UNENCRYPTED/I-sign-everything/g

But other that, I think you've exactly got right about what is being
thrown around here. And I agree that #4 is not valid: for one thing,
wildcards will not cover nodes that have other resource records (eg,
an A record).

		Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2007 18:23:20 -0400

> for _any_ email related policy record, and not just that for DKIM.  

If I understand you, this isn't working to work Doug.  A records are 
required.

Are you familiar with the MX lookup and expansion process?

In case you didn't,  the MX query does not always result in IP 
addresses.  The IP addresses are obtained in A lookups of the host names 
by provided by the MX records.

In other words, not all MX query gives you IP addresses to try.

A good example is YAHOO.COM:

C:\> nslookup -query=A yahoo.com

Non-authoritative answer:
yahoo.com       MX preference = 1, mail exchanger = f.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = g.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = a.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = b.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = c.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = d.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = e.mx.mail.yahoo.com

Now you expand each of these:

C:\> nslookup -query=A f.mx.mail.yahoo.com

Non-authoritative answer:
Name:    f.mx.mail.yahoo.com
Addresses:  209.191.88.247, 68.142.202.247

and you do this for EACH the MX host records to finally get a total 
expanded list of IP addresses.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2007 18:35:15 -0400

> wildcards and "NO MAIL" in the same discussion.

But why NO MAIL?  Why not other policies?

A system can have a default NO MAIL policy or a default I SIGN 
EVERYTHING  or anything else.

Here is a workable Wildcard syntax that has a default NO MAIL POLICY

*._ssp       0  TXT   ... no mail policy...
_ssp         0  TXT   ... I may sign ..
public._ssp  0  TXT   ... I never sign ...
sales._ssp   0  TXT   ... I always sign ..
corp._ssp    0  TXT   ... I always sign ..

and one with a default I ALWAYS SIGN

*._ssp       0  TXT    ... I always sign ..
public._ssp  0  TXT   ... I never sign ...

etc.

In my view, the first one is more plausible and practical to address the 
  real issues this whole effort has been trying to address - to STOP 
DOMAIN ABUSE.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Jun 2007 15:43:26 -0700

> public._ssp  0  TXT   ... I never sign ...

This requires a transaction at every label within the domain in  
question, where of course, this also clobbers SLDs.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Jun 2007 15:43:31 -0700

On Jun 6, 2007, at 3:01 PM, Hector Santos wrote:

> Jon Callas wrote:
>>
>> In short -- saying "I sign everything" with a non-existent or  
>> bogus  key is the same thing as saying, "You'll never see a valid  
>> one of these."
>

This results in a poor solution.

A bad-actor is free to include email-addresses from any sub-domain  
and even reference an existing key selector located within some  
higher domain.  Neither the recipient nor the domain owner are able  
to mitigate damage created by added cryptographic challenges or the  
flood of queries for non-existent records.

Unless SMTP is changed to demand that a domain publish an MX record  
as "proof or existence", there remains a need to declare which  
domains should be excluded from being processed.

Neither SPF nor MX Dot offer a safe solution for this assertion.   
Phillips XPTR is also unlikely to be safe or easily deployed.  The  
DKIM WG should not punt and then assume there is a safe solution.   
DKIM will increase the overhead associated with spoofing at virtually  
no cost to the bad-actor.  The DKIM WG should offer a solution for  
mitigating a likely problem DKIM exacerbates.

> By having an implicit "NO MAIL" policy as the original SSP specs  
> had as well as DSAP, it clearly marked the very strong policy  
> concept of what the DOMAIN expected.
>
> protect the domain from a exploited domain that should had NEVER  
> been used in the first place.

Agreed.

> If we are willing to fold the failed "I signed Everything"  
> transactions, as a clear rejectable transaction, then you are  
> right.  It can work, but it a WEAKER statement with some  
> "possibility" for false positive.  With a NO-MAIL policy, you have  
> 100% NO FALSE positives.

Requiring existence of an MX record with an exception granted by an  
interim period that allows A records would be another solution.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jun 2007 01:11:37 -0400

> question, where of course, this also clobbers SLDs.

Explain to me why this is a problem?

I am borrowing the logic used from one of the original LMAP proposals, 
DMP, which SPF based on its merged designed with another LMAP RMX? proposal.

This is a single lookup by the client, no traversal, no loop, required.

THe *._SSP record gives you the global default result as desired by the 
  main domain.

So regardless of the subdomains provided, you have a GLOBAL default.

Then for specific subdomains, you can further defined specific txt 
records to override the default.

Again, I am no DNS expert, but is there a TECHNICAL problem with this?

Explain it to me in terms of where there is overhead, pressure or lots 
of work, if any, on the DNS server?

-- 
Sincerely

Hector Santos, CTO

---

From: Steve Atkins <[email-masked]>
Date: Wed, 6 Jun 2007 22:43:16 -0700

On Jun 6, 2007, at 10:11 PM, Hector Santos wrote:

> I am borrowing the logic used from one of the original LMAP  
> proposals, DMP, which SPF based on its merged designed with another  
> LMAP RMX? proposal.
>

Your reasoning is unclear to me.

Given the domain a.b.c.d.e.f.g.h.i.j.k.foo, please explain what
single DNS query you would make and what answer you would
expect to receive.

>
> THe *._SSP record gives you the global default result as desired by  
> the  main domain.
>
> Explain it to me in terms of where there is overhead, pressure or  
> lots of work, if any, on the DNS server?

Cheers,
   Steve

---

From: Jon Callas <[email-masked]>
Date: Wed, 6 Jun 2007 23:04:59 -0700

> refer to a large number of subdomains via wildcard.

I get the distinct impression people don't understand. I'm pretty  
sure I don't, and among the things I don't understand is your use of  
"NO ENCRYPTED MAIL.' Encryption is completely not in scope of this  
working group. Even if I figure you've just made a braino, I'm confused.

However, that leads into what I think is a valuable point.

We want to have a way to make a policy statement S, apply to a range  
of subdomains, through some sort of wildcarding. I don't see anything  
that says:

For a given policy statement S that you want to apply to domain range  
D, issue a query that looks like Q.

I think it would help to describe it in broad terms rather than worry  
about the details at present.

	Jon

---

From: Jim Fenton <[email-masked]>
Date: Wed, 06 Jun 2007 23:09:57 -0700

Probably beating a dead horse, but...

> 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.
Since there are wildcard MX records, we might want to consider being
able publish wildcard signing policy for the domain as well.  I say
"might want to consider" because someone suggested that domains
publishing signing policy might prohibit use of MX wildcards, something
I'm still thinking about.
> 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 al…

I'm pretty sure we don't want to create a normative dependence on an
experimental protocol here.  I agree that the group consensus is that
nomail is out of scope, but I think it's dangerous to try to
characterize the motivations for that consensus.  My own reasoning
doesn't have anything to do with SenderID/SPF.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 06 Jun 2007 23:27:42 -0700

A couple of small points:

> mail, no-use, etc. domain using the existing Tinkertoys.

The selector name would be in the signature (which probably isn't
there), not in the policy.  But the same thing can be accomplished by
simply not publishing any key records, which has the advantage also that
it can avoid the computation required to verify a bogus signature.
> key is the same thing as saying, "You'll never see a valid one of  

But I agree with this statement, which I think is your main point.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jun 2007 04:34:27 -0400

> single DNS query you would make and what answer you would

The single DNS query syntax would be:

     a.b.c.d.e.f.g.h.i.j.k._ssp.foo

The result will depend on what this organization is going to define for 
policies at each level.

Practically speaking I can't imagine anyone using such a long set of 
subdomains for email, but nevertheless, it will naturally need to be 
part of the equation.

For the sake of simplicity, lets cut that down to a.b.c.d.foo.com, and 
lets use a well understood tld, .com, just so we can make sense out of 
it, but of course, it can be any valid TLD.

Again, it depends on what a company wishes for policies.

Example #1:

A company may want a I ALWAYS SIGN ALL DOMAINS, with NEVER exceptions 
after the b.c.d.foo.com subdomains:

     *._SSP    		0  TXT   policy=ALWAYS
     *.b.c.d._SSP	0  TXT   policy=NEVER

Example #2:

A company may want a global NOMAIL, with exceptions:

     *._SSP    		0  TXT   policy=NOMAIL
     _SSP    		0  TXT   policy=ALWAYS
     *.d._SSP	        0  TXT   policy=NEVER
     d._SSP	        0  TXT   policy=OPTIONAL
     c.d._SSP	        0  TXT   policy=ALWAYS
     b.c.d._SSP	        0  TXT   policy=OPTIONAL
     *.b.c.d._SSP	0  TXT   policy=NEVER

The client need only to do 1 query for the specific email domain provided.

Lets try some real test example queries for example #2 domain polices 
using the isdg.net domain:

email: isdg.net

	query --> _ssp.isdg.net
	This will return the ALWAYS policy (2nd record)

email: z.isdg.net

	query --> z._ssp.isdg.net
	This will return the NOMAIL policy (1st record)

email: d.isdg.net

	query --> d._ssp.isdg.net
	This will return the OPTIONAL policy (4th record)

email: q.d.foo.com

	query --> q.d._ssp.foo.com
	This will return the NEVER policy (3rd record)

Again, it all depends on what you want and it seems that by using this 
syntax, unless I'm missing something, it works.  The DKIM DNS ADMIN with 
the help of some fancy tool, he will be able to create complex policy 
records.

Finally, I think if DNS server can't handle the sub-domain "unions" of 
policies, then we should move to a syntax on the TXT record itself where 
a more robust wildcard masking can be done by the client.

-- 
Sincerely

Hector Santos, CTO

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 07 Jun 2007 13:20:37 +0100

> In other words, not all MX query gives you IP addresses to try.

So in that case, you can have an MX that directs you to the domain  
nomail.invalid (which has no A record, of course) and that is the end of  
the matter. What is wrong with that?

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jun 2007 09:06:36 -0400

> But I agree with this statement, which I think is your main point.

Sure, but unless I am missing a changing of philosophy, this goes 
against DKIM-BASE "ignore failures" design.

I was under the impression, the whole point of the SSP layer is to give 
DKIM domains and verifiers some authority to handle the DKIM signature 
expectation violations.

Is that what we want? change the semantics of DKIM-BASE?

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jun 2007 09:41:22 -0400

> the matter. What is wrong with that?

A change in long establish SMTP semantics and sending strategies.

The point is that the Sending Strategy is pretty much set by many 
implementations.

What will be your strategy?

   1 MX --> 1 A --> FAILURE --> REJECT?

Or will it follow the standard, with some following varying current 
practices for performing exhausted retries?

Each implementation may have  their own set of wrappers, for example in 
Wildcat! SMTP,  if enabled by the sysop, failure to deliver after the X 
number of retries may get the domain blacklisted.  We also have a CBV 
(SMTP callback) and NXDOMAIN failures promotes 45x responses.  It works 
like a GREYLIST hence bad systems don't try again, good systems do.

Can it be augmented by a new SSP protocol by specifying a MX/A 
requirement and recommendation for a change in SMTP sending strategy? 
Possibly, it might be acceptable in that vain.  SPF enforces FQDN 
operations,  SENDER-ID enforces RFC 2822 operations. Maybe SSP can 
enforce MX operations.

But I don't think this will be accepted in general as part of the SMTP 
especially because there is the presumption the remote system is a DKIM 
system, when in fact, it may not be.

In addition, you have 2821 vs 2822 integration complications, which in 
my view, one "total system" integration strategy is not going to be 
generally acceptable by all.  We have our set of integrated ideas.  The 
next guy has its own set as well.

I think SSP should stand on its own and then allow people to integrate 
them with new proposals if they want to share their integrated business 
methods. But it (SSP) should stand on its own.

My view.

-- 
Sincerely

Hector Santos, CTO

---

From: Jim Fenton <[email-masked]>
Date: Thu, 07 Jun 2007 07:30:59 -0700

Hector Santos wrote:
> I was under the impression, the whole point of the SSP layer is to
> give DKIM domains and verifiers some authority to handle the DKIM
> signature expectation violations.
>

No, this doesn't change the semantics of DKIM-BASE.  The DKIM-Base
"ignore failures" philosophy is basically "an invalid signature is
exactly the same as no signature at all:  no better and no worse."  What
we're talking about is how the missing/invalid signature case is handled.

-Jim

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 7 Jun 2007 08:58:56 -0700 (PDT)

On Thu, 7 Jun 2007, Hector Santos wrote:

> Example #1:
>
> A company may want a I ALWAYS SIGN ALL DOMAINS, with NEVER exceptions after 
> the b.c.d.foo.com subdomains:
>
> Lets try some real test example queries for example #2 domain polices using 
> the isdg.net domain:
>
> email: isdg.net
>
> 	query --> _ssp.isdg.net

Why would I look at q.d._ssp.foo.com rather then q._ssp.d.foo.com or
_ssp.q.d.foo.com?

---

From: Damon <[email-masked]>
Date: Thu, 7 Jun 2007 11:09:06 -0400

> we're talking about is how the missing/invalid signature case is handled.

The document already covers this case. It assumes that anyone doing so
must be a bad actor. Says nothing about good players doing it on
purpose :-)

Regards,
Damon Sauer

---

From: Steve Atkins <[email-masked]>
Date: Thu, 7 Jun 2007 08:41:04 -0700

On Jun 7, 2007, at 1:34 AM, Hector Santos wrote:

> The result will depend on what this organization is going to define  
> for policies at each level.

No. You're simply displaying a lack of understanding of DNS.

There is no conceivable way that can work in general.

By your reasoning, if presented with the hostname
sales.demon.co.uk you would query for sales.demon.co._ssp.uk.

That won't work. At all.

Please, before making assertions about how DNS resolution
should work, think about the basics of how DNS actually works.

Cheers,
   Steve

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jun 2007 12:40:19 -0400

> No. You're simply displaying a lack of understanding of DNS.

Why not? and How so?

> sales.demon.co.uk you would query for sales.demon.co._ssp.uk.

Why not?

> should work, think about the basics of how DNS actually works.

Fair enough, and I am going to make a greater serious effort to study, 
explore BIND source code, to see exactly how it all works.  There is 
probably some truth that BIND should be a good candidate in your eyes, 
correct?  It won't take me long since I already written DNS client code 
and understand client operations inside and out.

That said.  Give me some credit for trying. You didn't even try to 
understand the resolution yourself. You are saying it is WRONG. I don't 
see why.  Maybe you should explain if you know and rather then shoot it 
down, explain your NO and why it will not work.

What I don't know for sure and I will find out is the server side lookup 
overhead issue.

Now, from what I am sensing here is that for a domain such as:

        sales.demon.co.uk

the zone file is based on what?

        demon.co.uk?
        co.uk?
        uk?

Is it a HARD CORE RULE either way?   Do you know? If so, explain it.

I see no problem with the resolution for our set of domains. It resolves 
perfectly and its PDQ. I don't have subdomains at 10 levels and I 
seriously DOUBT many systems do.  But sure, it should work the same. 
Unrealistic and even then, low occurrences, but still, it should work 
the same.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jun 2007 13:03:00 -0400

> Why would I look at q.d._ssp.foo.com rather then q._ssp.d.foo.com or

Because I established a TWO LEVEL rule as this the WORLD WIDE norm, and 
you can get to the other subdomains with juse TWO levels.

Also think about the global default record:

      *._SSP   0   TXT  ... your default policy ...

That allows you cover the entire company (zone), and for strict systems, 
a NOMAIL default will be ideal to combat fake subdomain abuse.

I understand it doesn't have to be that way, but I would like to know 
why there is a problem with that.

You guys are the DNS administrators. Tell me. My skin is very thick.  If 
I am wrong with this method, explain how?

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jun 2007 13:20:49 -0400

> should work, think about the basics of how DNS actually works.

For the record, has you tried it?

I have it prepared for my santronics.com zone file.

; default NOMAIL
*._ssp     0  TXT "v=dsap1.0; rr=0; op=; 3p=; fa=fail; fx=fail;
                     fs=fail;

; santronics.com OPTIONAL policy, no 3PS
_ssp       0  TXT "v=dsap1.0; sd=*; rr=0; op=optional; 3p=never;
                    a=rsa-sha256; fa=fail; fx=fail; fs=fail;

; alway sign with corp.santronics.com
corp._ssp  0  TXT "v=dsap1.0; sd=corp; rr=0; op=always; 3p=never;
                    a=rsa-sha256;

; alway sign with sales.santronics.com
sales._ssp 0  TXT "v=dsap1.0; sd=sales; rr=0; op=always; 3p=never;
                    a=rsa-sha256;

; alway sign with europe.santronics.com
europe._ssp 0 TXT "v=dsap1.0; sd=europe.sales; rr=0; op=always;
                    3p=never; a=rsa-sha256;

; never sign with public.santronics.com
public._ssp  0 TXT "v=dsap1.0; sd=public; rr=0; op=never; 3p=never;

; never sign with list.santronics.com
list._ssp 0 TXT "v=dsap1.0; sd=list; rr=0; op=never; 3p=optional;
                  3pl=mipassoc.org

Do the DNS query for the valid ones and fake sub domains, or no subdomains:

     NSLOOKUP -query=txt  SUBDOMAINS._ssp.santronics.com

You said it won't work "AT ALL."   I would like to know why not?   Every 
  policy I want is defined including eliminating the ABUSE with a global 
NOMAIL record.

-- 
Sincerely

Hector Santos, CTO

---

From: Jim Fenton <[email-masked]>
Date: Thu, 07 Jun 2007 21:28:13 -0700

Hector Santos wrote:
> You said it won't work "AT ALL."   I would like to know why not?  
> Every  policy I want is defined including eliminating the ABUSE with a
> global NOMAIL record.
>

You're right, that one works.

Now suppose that, instead of santronics.com, you were
santronics.homestead.fl.us (domains of this form do exist).  The query
for SUBDOMAINS.santronics.homestead._ssp.fl.us wouldn't yield the
desired result.

Steve overstated his case when he said it would not work at all, but it
does not work in general.

-Jim

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 08 Jun 2007 09:59:49 +0100

On Thu, 07 Jun 2007 14:41:22 +0100, Hector Santos <[email-masked]>  
wrote:

>> nomail.invalid (which has no A record, of course) and that is the end  
>> of the matter. What is wrong with that?
>

No. Just a way to say this domain does not want to receive any email, even  
though it has an A record. That MX should get cached (so no excessive load  
on the authoritative server). And nomail.invalid should also get cached,  
as a DNS failure, or so I have been informed, so no excessive load on the  
root servers; a smart DNS resolver will already have built into it that  
'invalid' is not even worth looking up. I proposed it as an alternative to  
the suggested "MX .", which apparently had problems.

> like a GREYLIST hence bad systems don't try again, good systems do.

A domain which does not want to receive email should welcome such  
blacklisting. Agreed it should be reviewed after some TTL.

---

From: Jon Callas <[email-masked]>
Date: Fri, 8 Jun 2007 02:02:08 -0700

> must be a bad actor. Says nothing about good players doing it on

Yes, sorta....

If I have a valid public key for which there is no private key, it's  
not malformed. As a matter of fact, you can't tell that I burned the  
private key.

It's perfectly well-formed, it's just incapable of executing  
successfully.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Fri, 8 Jun 2007 02:01:32 -0700

> Is that what we want? change the semantics of DKIM-BASE?

It doesn't change any semantics at all. DKIM-BASE does recommend  
ignoring failures. But the whole point of SSP is to consider the case  
where we don't want to ignore failures. We want a missing/broken/etc.  
signature to have meaning.

The receiver doesn't have to do anything. It can ignore all of DKIM.  
But if it doesn't want to, that's where SSP comes in.

The hack I describe is merely setting up your DKIM parameters so that  
any signature on a message must be erroneous; the receiver then does  
whatever they want, including using SSP.

	Jon

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 08 Jun 2007 10:28:03 +0100

>> sales.demon.co.uk you would query for sales.demon.co._ssp.uk.

Actually, I think Hector is asking for sales.demon._ssp.co.uk to be  
queried, but that is just as bad.
> Why not?

So you are expecting Nominet (the managers of the uk TLD, and of co.uk,  
org.uk, net.uk, etc under it) to administer the '_ssp.uk' domain on behalf  
of Demon and all the 99999 other *.co.uk domains that have been registered  
by the umpteen registrars licensed by Nominet?

The only way your scheme could possibly work is by invoking some Magic  
that tells you to look at sales._ssp.demon.co.uk, so that Demon get to  
manage their own policies. The only possible such Magic suggested so far  
is Doug Otis's global registry of registrable domains, or maybe some  
inventive examination of SOA records. Neither of these has net with much  
approval in this WG.

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Jun 2007 05:44:21 -0400

> signature to have meaning.

I believe that is what I said above.

> whatever they want, including using SSP.

I believe the question you inherently raised was if SSP needed a NOMAIL 
concept - hence why it was deemed to be a REDUNDANT concept and removed 
from the requirements.

I am merely pointing out that the idea of using a bogus key to signal a 
failure concept was well established, but that without a NOMAIL policy 
concept, that key failure only would not be enough to handle the 
transaction for rejection from a domain complete expectation point of 
view -

       I don't expect mail from this domain - kill it, don't
       tag it or mark it as bad for user's to see, kill it,
       don't pass it on. Its not ours!  - If you do, it is
       no longer our responsibility as DKIM-BASE suggest it
       is."

So it is not a redundant.  SSP requires a NOMAIL concept.  The bogus key 
may assure am invalid signature from a technical standpoint, the SSP 
NOMAIL declaration assures a rejection from a policy standpoint.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Jun 2007 09:16:19 -0400

> does not work in general.

Its amazing how these are perceived here. :-)

Ok, I understand the point about the gTLDs, and ccTLDs now.

I think the main thing that I wanted to extract from this exercise is 
that the TXT record layout technique I describe was doable. In other 
words, once the query question can be  established, the layout of the 
wildcard TXT records  would satisfy the requirement for sub-domain policies.

I think I accomplish that. Am I still wrong there?

So the issue is now what is the query question or more specifically, 
where does the domain ownership begins and can the client understand 
what are the gTLDs and/or ccTLDs.

I think we can solve this query question various way:

1) Provide a HINT in the DKIM-signature.

2) Use a Doug suggestion to make it part of the LOOKUP algorithm to 
contain a list name space of currently gTLDS and ccTLDs.

3) Less optimal, use a SOA or ANY to where the tlds end and domain
ownership begins.  This can be cached so subsequent queries will be more 
direct.

4) Provide a discovery record for the full domain.

Also, we have two design requirements to resolve:

    - One that satisfies as written requirement that you only
      need to look for SSP for failed signatures,

    - One that satisfies ALLOWABLE implementations that
      can do a SSP lookup at all times.

I think I proved via DSAP that abuse is possible for non-signed messages 
abusing a domain.  So if one takes the presumption is that a NON-SIGNED 
message is an INVALID message, a lookup for SSP will be desirable.

What that means is that option #1 will not work reliable.  SSP *should* 
not be dependent on having a DKIM-Signature record present.

However, those who believe that SSP is not active unless a 
DKIM-Signature is available, then a HINT can be provided on 
DKIM-Signature header.

I think that the safest bet is to make SSP independent of the 
DKIM-Signature header.

There has got to be a way to resolve that TLD vs domain ownership level 
issue.  It seems so simple, but it might require some initial two 
queries.   In lieu of that, Doug Idea sounds like the only real way to 
solve this - the client must be aware of the gTLD and ccTLD or there 
must be a way to extract this information.

-- 
Sincerely

Hector Santos, CTO

---

From: [email-masked] (Wietse Venema)
Date: Fri, 8 Jun 2007 09:19:19 -0400 (EDT)

>        no longer our responsibility as DKIM-BASE suggest it

Enough is enough.

I thought we already debunked the myth that SSP can tell receivers
what they should do.

It's a sender signing policy. It's not a receiver disposition policy.
       ====== =======                    ======== ===========

Sender != Receiver

Signing != Disposition

I am of course assuming that this forum is conducting business in
plain English, not some variant with radically different semantics.
If my assumption is in error, please ignore this erroneous comment.

        Wietse

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Jun 2007 09:32:10 -0400

> I thought we already debunked the myth that SSP can tell receivers

Only in your exclusive circle of friends.

What was WELL established is that it provided a HINT to RECEIVERS.

SSP IS EXACTLY ABOUT TELLING THE RECEIVER WHAT TO DO WITH DKIM 
violations.  What is EXPECTED and NOT EXPECTED!

Why is that people like yourself keep thinking that sending JUNK to 
receivers, that YOU want them to PROCESS is going to always be acceptable?

If you don't give them HINTS, they might just IGNORE it completely or 
take actions you seem to fail not recognize at this point.

> It's a sender signing policy. It's not a receiver disposition policy.

So why are you bringing it up that it is?

> Sender != Receiver

So why are you bring up this silly bogus idea?

> Signing != Disposition

So why are you bring up this silly bogus idea?

> If my assumption is in error, please ignore this erroneous comment.

I'm sure many, your "exclusive circle of friends" will blindly agree 
with you.

Lets watch the silly +1 nows from the same "circle of friends."

-- 
Sincerely

Hector Santos, CTO

---

From: <[email-masked]>
Date: Fri, 8 Jun 2007 09:40:05 -0400

Like I said when the initial vote was taken, without a NOMAIL policy I
don't have any real interest in what SSP can do. DKIM Base is enough.
Well I tried to bring it back up, seems to be going nowhere so will bow
out and let you folks do what you do. Please note from an ISP standpoint
only 3 things will matter
I sign all mail
I never send mail
I sign some mail
Anything else is just another burdensome query over strained DNS
resources. Heck it might be easier just to send mail via the AIN
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wietse Venema
Sent: Friday, June 08, 2007 9:19 AM
To: Hector Santos
Cc: IETF DKIM WG
Subject: Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues

Enough is enough.

Sender != Receiver

Signing != Disposition

        Wietse

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Jun 2007 09:49:23 -0400

> I thought we already debunked the myth that SSP can tell receivers

For the record,  the SSP draft contains "instructions," 
"recommendations,"  [PICK YOUR ENGLISH], on mail handling mail.

But what VERY WELL ESTABLISHED is that it was left to the decretion of 
the receiver.

2.8.  Suspicious

    Messages that do not contain a valid Originator Signature and which
    are inconsistent with a Sender Signing Practices check (e.g., are
    received without a Valid Signature and the sender's signing practices
    indicate all messages from the entity are signed) are referred to as
    "Suspicious".  The handling of such messages is at the discretion of
    the Verifier or final recipient.  "Suspicious" applies only to the
    DKIM layer; a Verifier may decide the message should be accepted on
    the basis of other information beyond the scope of this document.
    Conversely, messages deemed non-Suspicious may be rejected for other
    reasons.

5.1.  Mailing List Manager Actions

    ...

    Mailing List Managers MAY:

    o  Reject messages with signatures that do not verify or are
       otherwise Suspicious.

I don't know what WORLD you live in, but DKIM/SSP is simply about 
CLEANING UP SPAM  - call it or market it like you want.  The WORLD will 
see it as a ANTI-SPAM solution.

SSP is about providing DKIM failures some "reason" and verifiers a 
better handle on what to do with it, and if the DOMAIN is not interested 
in getting rid of abusive mail in there name, then I fail to see the 
purpose of DKIM.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Jun 2007 07:03:48 -0700

On Jun 8, 2007, at 1:59 AM, Charles Lindsey wrote:

> On Thu, 07 Jun 2007 14:41:22 +0100, Hector Santos  
> <[email-masked]> wrote:
>
>> Charles Lindsey wrote:
>>
>>>> So in that case, you can have an MX that directs you to the  
>>>> domain nomail.invalid (which has no A record, of course) and  
>>>> that is the end of the matter. What is wrong with that?
>>
> No. Just a way to say this domain does not want to receive any  
> email, even though it has an A record. That MX should get cached  
> (so no excessive load on the authoritative server). And  
> nomail.invalid should also get cached, as a DNS failure, or so I  
> have been informed, so no excessive load on the root servers; a  
> smart DNS resolver will already have built into it that 'invalid'  
> is not even worth looking up. I proposed it as an alternative to  

This is a different name with a worse problem.  An MTA is unlikely to  
know that either "." or "nomail.invalid" is an invalid host name.   
The "." is valid and represents "root".  The "nomail.invalid" will  
cause a flood of unterminated transactions requesting name servers  
for "invalid".  Perhaps this scheme could use "nomail.arpa" where  
there is a long lived record published to curtail the traffic that  
older MTAs will create.  However a method that returns an "invalid-by- 
name" will cause these older MTAs to consider the hostname to exist  
when it does not.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Jun 2007 07:04:36 -0700

> whatever they want, including using SSP.

While that should be possible, it also does not provide an optimal  
construct.  Exclusions would be possible only as a result of  
processing a signature.  Providing a method to directly indicate  
whether a signature is valid based upon its domain can offer better  
protection from subsequent queries or the processing of signatures.   
This could also be extended by an authorization schemes where DKIM is  
only checked when it is likely to provide a valid result.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Jun 2007 12:57:14 -0400

Charles Lindsey wrote:

> org.uk, net.uk, etc under it) to administer the '_ssp.uk' domain on 
> behalf of Demon and all the 99999 other *.co.uk domains that have been 
> registered by the umpteen registrars licensed by Nominet?

No. I was ignorant of ccTLDs. No longer. :-) I've done the research. Now 
I am studying how the gTLD root server are related to the ccTLD root 
servers.

> inventive examination of SOA records. 

Right. I don't see a reason why the protocol can not implement a gTLD, 
ccTLD name space logic in order to find the level where the domain 
ownership begins.

The protocol can include these in a name space and instantly determine 
where the domain ownership begins.

I don't see a problem programming for this.  Par for the course.

-- 
Sincerely

Hector Santos, CTO

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 8 Jun 2007 11:14:22 -0700 (PDT)

On Fri, 8 Jun 2007, Hector Santos wrote:

> No. I was ignorant of ccTLDs. No longer. :-) I've done the research. Now I am 
> studying how the gTLD root server are related to the ccTLD root servers.
>
>> The only way your scheme could possibly work is by invoking some Magic that 
>> tells you to look at sales._ssp.demon.co.uk, so that Demon get to manage 
>> their own policies. The only possible such Magic suggested so far is Doug 
>> Otis's global registry of registrable domains, or maybe some inventive 
>> examination of SOA records. 
>
> Right. I don't see a reason why the protocol can not implement a gTLD, ccTLD 
> name space logic in order to find the level where the domain ownership 
> begins.
>
> The protocol can include these in a name space and instantly determine where 
> the domain ownership begins.

The closest thing you can do is talk gTLD and ccTLD into putting some
record at _xyz.TLD that tells root level of deligation for that TLD.
Unfortunetly cases like .US make it worth since there are multiple
deligation roots.

> I don't see a problem programming for this.  Par for the course.

You haven't done it. I have - large database that is hard to maintain.
Here is one for well-known domain for example (which does both 2nd
and 3rd level deligation):

DoWhois_MainDomains(Buffer, Query, "whois.cira.ca", "", 6, "SUBDOMAIN:",
"on.ca, qc.ca, nl.ca, pe.ca, nt.ca, nu.ca, bc.ca, ab.ca, nb.ca, ns.ca, 
yk.ca, sk.ca, mb.ca", querylevel);

Here is another less well-known:

DoWhois_MainDomains(Buffer, Query, "whois.nic.hu", "", 13, "DOMAIN:",
"co.hu, 2000.hu, erotika.hu, jogasz.hu, sex.hu, video.hu, info.hu, agrar.hu, 
film.hu, konyvelo.hu, shop.hu, org.hu, bolt.hu, forum.hu, lakas.hu, suli.hu, 
priv.hu, casino.hu, games.hu, media.hu, szex.hu, sport.hu, city.hu, hotel.hu, 
news.hu, tozsde.hu, tm.hu, erotica.hu, ingatlan.hu, reklam.hu, utazas.hu", 
querylevel);

It goes like this for almost every large-enough TLD (for others I often
simply don't know).

---

From: Steve Atkins <[email-masked]>
Date: Fri, 8 Jun 2007 10:28:47 -0700

On Jun 8, 2007, at 9:57 AM, Hector Santos wrote:

> Charles Lindsey wrote:
>
>>>
>>> Why not?
>> So you are expecting Nominet (the managers of the uk TLD, and of  
>> co.uk, org.uk, net.uk, etc under it) to administer the '_ssp.uk'  
>> domain on behalf of Demon and all the 99999 other *.co.uk domains  
>> that have been registered by the umpteen registrars licensed by  
>> Nominet?
>
> No. I was ignorant of ccTLDs. No longer. :-) I've done the  
> research. Now I am studying how the gTLD root server are related to  
> the ccTLD root servers.
>
>> The only way your scheme could possibly work is by invoking some  
>> Magic that tells you to look at sales._ssp.demon.co.uk, so that  
>> Demon get to manage their own policies. The only possible such  
>> Magic suggested so far is Doug Otis's global registry of  
>> registrable domains, or maybe some inventive examination of SOA  
>> records.
>
> Right. I don't see a reason why the protocol can not implement a  
> gTLD, ccTLD name space logic in order to find the level where the  
> domain ownership begins.

No, that's impossible in general.

I'll point you at us.com, uk.com and dyndns.org as some obvious examples
you should consider.

>
> The protocol can include these in a name space and instantly  
> determine where the domain ownership begins.

Actually, no, it can't. A third party cannot reliably identify the  
domain cut
associated with an administrative entity.

It can guess, and often be right, but that's all. Look at the gross  
hacks
in your typical "smart" whois client for an example of the hideousness
even the guessing involves.

> I don't see a problem programming for this.  Par for the course.

Yes, indeed. Par for the course.

Cheers,
   Steve

---

From: SM <[email-masked]>
Date: Fri, 08 Jun 2007 13:59:37 -0700

At 06:16 08-06-2007, Hector Santos wrote:
>There has got to be a way to resolve that TLD vs domain ownership 
>level issue.  It seems so simple, but it might require some initial 
>two queries.   In lieu of that, Doug Idea sounds like the only real 
>way to solve this - the client must be aware of the gTLD and ccTLD 
>or there must be a way to extract this information.

It's not as simple as it sounds.  It may take a long time to get that 
information out of all the gTLDs and ccTLDs.  I doubt they'll even 
agree to a registry for that.  It's not a technical problem.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Jun 2007 17:51:56 -0700

On Jun 8, 2007, at 1:59 PM, SM wrote:

>> level issue.  It seems so simple, but it might require some  
>> initial two queries.   In lieu of that, Doug Idea sounds like the  
>> only real way to solve this - the client must be aware of the gTLD  
>> and ccTLD or there must be a way to extract this information.
>
> It's not as simple as it sounds.  It may take a long time to get  
> that information out of all the gTLDs and ccTLDs.  I doubt they'll  
> even agree to a registry for that.  It's not a technical problem.

It can be simple.  Your view overlooks significant motivations  
registries would have to enroll their domain.  An enrollment process  
could be fairly simple and easily automated via a web based response  
(via an encoded link) sent to the SOA record addresses.  It seems  
this process and the these results should be published by IANA.  An  
alternative to the use of email as a confirmation method, could be to  
have registries publish an "illegal" domain of "_REGISTRY" for  
example.  This might require the cooperation of ICANN or other  
organizations to permit the use of such a record.

Only owners of these domains would be able to enroll as a registry  
domain.  Their motivation would be to curtail searches which attempt  
to either begin or end at their domain.  Such searches may occur as a  
result of several protocols.  Enrollment into a registry domain list  
would offer a general means to curtail all such searches.

Many organizations internally develop these lists, as such lists  
provide an instrumental means for limiting domain related searches.   
Use of such lists is not restricted to just DNS.  It seems wholly  
appropriate to provide a means for domain owners to directly indicate  
the nature of their domain.  It should not require a great deal of  
time for such a list registration process to become reasonably  
comprehensive.  The overall number of such domains will likely be a  
few 1000.  A very small number compared to the 5 million daily domain  
additions and deletions out of more than 100 million which challenges  
any scheme attempting to track domains.  The rate of change of such a  
list should also appear glacial in comparison.

All parent domains must be listed before a sub-domain would be  
allowed.  It might help limit abuse by also allowing registry domains  
to indicate whether there are any valid registry domains below the  
domain they are registering.

-Doug

---

From: "Patrick Peterson" <[email-masked]>
Date: Fri, 8 Jun 2007 18:28:11 -0700

I (respectfully) disagree with Wietse. I think it is very important for
the sender to be able to express their desire to the receiver for how to
handle mail in specified circumstances. I do not believe expressing this
desire constitutes "telling receivers what to do".

This is a very important point as many of the senders I know who want to
deploy DKIM feel this is an important component. Large scale deployments
of DKIM require significant time and testing before adequate confidence
can be established of reliability. Once adequate confidence is
established many senders want to request that receivers do not deliver
unsigned or improperly signed messages.

These senders are not under the illusion they can force receivers to do
anything. But they feel it is a significant value to express their
desire.

pat 

> Sent: Friday, June 08, 2007 6:19 AM
> To: Hector Santos
> Cc: IETF DKIM WG

---

From: "Patrick Peterson" <[email-masked]>
Date: Fri, 8 Jun 2007 18:39:28 -0700

I read the posts as best I could and found some ambiguity.

I strongly believe nomail is important so I may be biased but it did not
appear to be cut and dry. In fact, some of the "No nomail" votes said
the objective could be accomplished in a different manner.

Since I didn't vote I do not feel I can raise the issue again. But it is
clear to me that summarily striking down any discussion of this item as
out of scope is not appropriate. Putting it in a box or deferring it may
be. But I would ask everyone to listen to the justification for nomail
regardless of when/if it is addressed. Many of our assumptions change as
design continues and input is received.

Would it help the discussion if large deployers of DKIM expressed their
opinions on nomail? (Again, they could express their opinions and this
item could still be held for later.)

pat

> Sent: Wednesday, June 06, 2007 6:46 AM
> To: Stephen Farrell

---

From: Jim Fenton <[email-masked]>
Date: Fri, 08 Jun 2007 21:45:05 -0700

This capability (expressing desire for how the receiver should handle
mail in specified circumstances) is somewhat along the lines of an
"expectation" as defined in the SSP Requirements draft.  What it says
there is that, in addition to signing practices like "I sign all mail",
SSP also conveys an expectation about whether the recipient should
always expect a valid signature.  For many domains, this is "no" because
they send messages through mailing lists and other things that may break
signatures.  Other domains, such as those used for transactional mail,
would have a greater expectation of a valid signature because they don't
expect to send through such things.

To put it another way, some domains are more interested in
deliverability (even if the signature is broken), and others are more
interested in security.

So while the wording is somewhat different, I interpret the
"expectations" expressed in the requirements document as providing the
sort of capability Pat describes.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 08 Jun 2007 21:55:18 -0700

Pat,

It's somewhat of a political issue:  I don't favor a NOMAIL policy
because I don't feel that the DKIM WG has the authority to create a
policy framework describing the overall use of email, just the use of DKIM.

What a non-mailing domain can do that is almost equivalent and within
scope is to express a policy that they sign everything, and an
expectation that receivers should receive signed mail from the domain,
and then publish no public keys (selectors).  If the verifier can't
retrieve the public key, then the signature can't possibly be good and
there's no use verifying it.  The only extra overhead compared with a
NOMAIL policy is that with NOMAIL it isn't necessary to retrieve the
public key. But many verifiers will only do SSP if there's no valid
originator signature, so they won't know of the NOMAIL policy yet anyway.

So I think this could be accomplished in a different manner.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Jun 2007 07:27:01 -0400

Jim,

Isn't this is a contradiction here?

First you made a statement that the "DKIM WG has no authority to create 
a  policy framework describing the overall use of email, just the use of 
DKIM."

But then yet you just went ahead and described one anyway, further you 
went ahead and dictated receiver design.

Just think about this:

Do you considered a message that is not DKIM signed has a presumption of 
invalidity?  Thus promoting a SSP check?

Whether you do or not, your angle seems to be to dictate local policy, 
how systems will be design, how email is to handled, how verifiers must 
tolerate abuse,  how optimization, scalability and overhead is or not 
considered and worst, how we need to present all this to customers in 
ways that may not be appropriate to them, thus increasing the adoption 
barrier.

In any case, I am happy to see more SMTP system vendors, especially from 
larger systems, voice their input here.

-- 
Sincerely

Hector Santos, CTO

---

From: John Levine <[email-masked]>
Date: 9 Jun 2007 11:57:19 -0000

>item could still be held for later.)

If nomail is indeed the most useful SSP-ish assertion, which I agree
it is, it might make sense for people who care about it to go work on
moving MX . (or some other pure nomail approach) along the standards
track rather than getting entangled in SSP.

One killer problem of putting nomail into SSP is that if example.com
publishes a nomail SSP, and sends signed mail, there is no agreement
at all here on which one you believe.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Jun 2007 08:29:06 -0400

> track rather than getting entangled in SSP.

-1.  IMO, I don't see any entanglement and it would be far easier to 
implement this via a new SSP protocol rather than begin changing the 
long time semantics of MX which IMO has a far greater chance of not 
being considered.

> at all here on which one you believe.

The same can be said when he declares "I ALWAYS SIGN" or "I NEVER SIGN" 
and sends unsigned or signed mail anyway, respectively.

Should we believe him?  Where you do draw the line?

In either case, it is an easy decision. Its the fault of the domain. 
Hence, as always, the domain bears the consequences of its mistakes.

-- 
Sincerely

Hector Santos, CTO

---

From: [email-masked] (Wietse Venema)
Date: Sat, 9 Jun 2007 10:29:06 -0400 (EDT)

> anything. But they feel it is a significant value to express their

I agree with the sentiment that senders must be able to indicate
under what conditions mail is un/authentic. DKIM provides a more
reliable tool to rank mail than looking at the FROM header.

However, I disagree with the sentiment that senders can tell
receivers to "kill it, don't pass it on" as expressed here.
This implies that senders control the threshold at which receivers
discard mail. I consider this unrealistic.

More realistic, IMHO, is that receivers maintain control over their
threshold, and that they use DKIM as a tool to rank mail against
that threshold.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Sat, 9 Jun 2007 07:51:51 -0700

On Jun 9, 2007, at 4:57 AM, John Levine wrote:

>> Would it help the discussion if large deployers of DKIM expressed  
>> their opinions on nomail? (Again, they could express their  
>> opinions and this item could still be held for later.)
>
> If nomail is indeed the most useful SSP-ish assertion, which I  
> agree it is, it might make sense for people who care about it to go  
> work on moving MX . (or some other pure nomail approach) along the  
> standards track rather than getting entangled in SSP.

For any DKIM SSP to be useful at assisting recipients understand  
whether an email is valid, SSP MUST be able to indicate whether the  
domain or a sub-domain MUST BE SIGNED.

Discovering the policy record containing the MUST BE SIGNED assertion  
is as difficult as discovering a sub-domain USED/UNUSED assertion.   
 From a DKIM standpoint, a fair amount of DKIM related overhead can  
be mitigated by also offering a means to determine whether a sub- 
domain is USED, in addition to whether a sub-domain MUST BE SIGNED.   
Due to DKIM's added overhead, an assertion of USED/UNUSED represents  
a significant aspect of defending the signature validation process.

The discovery process itself might provide a solution.  For a message  
to contain a valid email-address, the domain of this address MUST  
locate either an MX or A record.  The DKIM WG could strongly  
recommend A record discovery be deprecated, and that only MX records  
be used for discovery.  Within a few years, it should be possible to  
obsolete use of A record discovery.  An email-address would not be  
valid without an MX record.  This would mean that policy placement  
adjacent to the MX record would be the only location any policy  
record would need to exist.  In this case, the discovery process  
itself indicates whether or not the sub-domain is USED/UNUSED.

If this "proof of use" approach is not used with DKIM, then flooding  
a zone with some type of policy record is the alternative.  When  
"proof of use" is not utilized by the DKIM process, then stipulations  
via policy represents the only other reasonable alternative.  In  
which case, an assertion of USE must be included simply due to the  
overhead related to either the policy publishing or the discovery  
process.  In which case, it would be completely _unreasonable_ to  
neglect including within hundreds or thousands of policy assertions,  
whether the domain is being used or not.

> One killer problem of putting nomail into SSP is that if  
> example.com publishes a nomail SSP, and sends signed mail, there is  
> no agreement at all here on which one you believe.

This really depends upon overhead required for either process.  When  
DKIM does not depend upon "proof of use", then "proof of policy"  
should truncate DKIM processing that might otherwise occur.  A  
reliable means to discover whether a sub-domain is USED impacts DKIM  
to any significant degree.

-Doug

---

From: John Levine <[email-masked]>
Date: 9 Jun 2007 15:06:56 -0000

>discard mail. I consider this unrealistic.

I think we all agree that receivers will only do what's in their own
self-interest, and they'll only take senders' advice if it helps that
along.

"It's all spam" is about the simplest useful advice a (non) sender can
give.  In my case, which I don't think is unusual, I get buckets of
spam and blowback to subdomains that have never, ever, sent a real
message.  The domains are the names of computers on my network, which
were probably scraped out of usenet or mail archive message IDs.  If
receivers were to reject or drop all mail purporting to be from those
domains, it would be uniformly better both for the receivers (less spam,
cheap filter) and for me (less blowback.)

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Jun 2007 12:01:06 -0400

+1

+1

IMV, the bottom line is that operators or everyone for that matter, do 
not want abuse, senders and receivers.  No one is interested in stopping 
mail.  Thats no fun.

But when abuse begins, they will want help to stop or control it, and of 
course, they want to do so in a way that is 100% correct.

For us, when it comes to a base of customers who want as much help as 
they can get, lots of hand holding, automatic logic, etc, and taking on 
more and more of this responsibility, we need to ability to offer the 
options and hopefully, define the defaults, that works best for them.

It was only about 3 years ago (when I began to get involved in all 
this), that I had absolutely no interest in providing SMTP rules to 
control spam.  If the sysop wanted it outside of the basic SMTP 
protocol, he did it himself.   All we did was provide the "hooks" for 
them to do it.

But what hooks were available back them?

With the infamous SORBIG attack and the variants that followed, this 
changed every part the industry at all levels.  It put the spot light on 
the SPAM problem. People needed new regulations, new tools to help them 
control the mess, and like you said, any automated system advice they 
can get, helps the process.

You and your ASRG efforts helped tremendously to jump start ANTI-SPAM 
efforts and you should be recognized for that.

When we take away all the personalization, we all do seem to one thing 
in common:  The common goal to make sure it makes sense, hopefully make 
it as transparent as possible, without hindering the flow of "good mail."

-- 
Sincerely

Hector Santos, CTO

---

From: Jeff Macdonald <[email-masked]>
Date: Sat, 9 Jun 2007 12:22:18 -0400

> know that either "." or "nomail.invalid" is an invalid host name.

I didn't think they were proposing any particular name, just that after
looking up the MX record, the corresponding A lookup failed. Surely all
MTAs should be able to handle that case. Newer ones would realize that
the domain in question doesn't want any mail, while older ones may
retry till the message expires.

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

---

From: Jeff Macdonald <[email-masked]>
Date: Sat, 9 Jun 2007 12:36:43 -0400

> itself indicates whether or not the sub-domain is USED/UNUSED.

Are you referring to the process that some MTAs follow? For example, if
a MTA needs to deliver a message, it is suppose to find a MX for the
right hand side of the email address and deliver it to the eventual A
record (Hector's claim that some MX records return IPs confused me).
Some MTAs, when they don't find an MX record, just lookup an A record
instead and deliver to the resulting IP.

If that's the case, shouldn't the deprecating of A lookups when a MX
lookup fails be brought to the SMTP group?

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Jun 2007 13:48:14 -0400

> record (Hector's claim that some MX records return IPs confused me).

I was referring to MX expansion and how each DNS client within a SMTP 
client may behave.  More below.

> lookup fails be brought to the SMTP group?

Yup, and IMO, I can almost guaranteed the idea will be killed ASAP.  I 
would vote against it.

I seriously doubt people will begin to screw around with their various 
retries logic.  Plus, you are going to hear those who say MX is about 
inbound, not outbound and "Never The Twain Shall Meet."

What I was referring to was MX expansion. MX lookups return the 
hostnames, not IPs.  When you perform MX expansion, you look at the A 
record per hostname. Each can return 1 or more IP addresses.

Depending on the DNS client you are using, it may or may not 
automatically expand the host names.   How this is done varies by each 
implementation depending on their sending strategy.  For our own SMTP 
product, our internal DNS client will expand them all and then grab the 
first X amount or all of them.

You can't really use the lack of A record for a SSP NOMAIL concept for 
the following reason:

Lets just use a large system for example, like YAHOO.COM:

	nslookup -query=MX yahoo.com

Suppose that when your client begins to expand these, all except two 
return IP addresses.

Is that enough for this NOMAIL rule?

Or does this apply when no hostname can be expanded?

What if all of them are successful, but no connection can be made to any 
of the IP addresses? or maybe a certain amount?

Is that enough for this NOMAIL rule?

What each you can make a connection to all of them but they all return 
55x at the greeting?

Is that enough for this NOMAIL rule?

I personally agree that each system should have a proper setup, but that 
is not guarantee in practice.

I recall many years ago how we gave sysops an option to use a very tight 
MX/A equation to quickly blacklist bad host systems.

This was almost immediately removed as it created more support headaches 
than it was worth.

People's systems do go down, DNS responses may not be there and we found 
that allowing retries to expire after 72 attempts, 1 per hour or 3 days. 
(defaults) reduce these support issues.

And this had nothing to do with small ISP/DNS providers, but VERY VERY 
VERY large ones as well.  Just a few months back I was assisting my 
brother with his new SMTP setup for his new SOHO.   He was having all 
kinds of strange DNS issues. At first, I just thought that his new DNS 
MX and hosting A records did not propagate through the network yet.  But 
when resolution problems continued,  I finally got in contact with this 
VERY VERY VERY large DSL/ISP/DNS provider on his behalf.

The answer was simple:

They were having DNS server problems and they didn't bother to them him 
to change his fixed DNS server IPs in his network setup.   Once changed, 
he is running as smooth as silk.

These things happen.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Sat, 9 Jun 2007 11:15:30 -0700

On Jun 9, 2007, at 9:36 AM, Jeff Macdonald wrote:

>> The discovery process itself might provide a solution.  For a  
>> message to contain a valid email-address, the domain of this  
>> address MUST locate either an MX or A record.  The DKIM WG could  
>> strongly recommend A record discovery be deprecated, and that only  
>> MX records be used for discovery.  Within a few years, it should  
>> be possible to obsolete use of A record discovery.  An email- 
>> address would not be valid without an MX record.  This would mean  
>> that policy placement adjacent to the MX record would be the only  
>> location any policy record would need to exist.  In this case, the  
>> discovery process itself indicates whether or not the sub-domain  
>> is USED/UNUSED.
>
> Are you referring to the process that some MTAs follow? For  
> example, if a MTA needs to deliver a message, it is suppose to find  
> a MX for the right hand side of the email address and deliver it to  
> the eventual A record (Hector's claim that some MX records return  
> IPs confused me). Some MTAs, when they don't find an MX record,  
> just lookup an A record instead and deliver to the resulting IP.
>
> If that's the case, shouldn't the deprecating of A lookups when a  
> MX lookup fails be brought to the SMTP group?

This depend upon how the DKIM WG decides to handle policy discovery.

It seems unreasonable to expect receiving MTAs adopt a strategy of  
searching all labels (below the TLD) in hopes of finding a policy  
record that might exist in some small percentage of cases.  This  
would also hammer SLDs, such as co.uk.  (A registry list might help  
mitigate the harm.)

It also seems unreasonable to expect sending domains to publish a  
policy record at _every_ DNS node as needed to support use of  
wildcard records.  This would be especially true when the policy can  
only indicate whether a message is expected to be signed.  To improve  
handling of signature failures (common with DKIM) not providing a  
indication as to whether the domain itself should be considered valid  
makes this even more _unreasonable_!

Phillip's discovery concept justified publishing XPTR records at  
every node by having them indicating a principal domain to be used  
for policies of all types!  Yikes!  Reliance upon wildcards is _not_  
welcomed by DNS groups, as these records are increasingly utilized to  
stage DDoS attacks and can be problematic in other ways.  Although  
answers for wildcard records are cached, when dealing with random  
labels, the cache itself becomes flooded without any outward  
indication of an attack occuring.  The maximum domain name size in  
conjunction with the pointer returned is also likely to approach or  
perhaps exceed the maximum DNS message size permitted.

On the other hand, if the DKIM WG were to recommend that "proof of  
use" be confirmed before accepting a message, then signature  
validation and policy would be expected only at domains with records  
that offer "proof of use."  To greatly simplify this process, A  
record discovery should be deprecated and then obsoleted ASAP.  This  
would of course need to be done by a different WG.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sat, 9 Jun 2007 11:25:00 -0700

On Jun 9, 2007, at 10:48 AM, Hector Santos wrote:

>>> strongly  recommend A record discovery be deprecated, and that  
>>> only MX records  be used for discovery.  Within a few years, it  
>>> should be possible to  obsolete use of A record discovery.  An  
>>> email-address would not be  valid without an MX record.  This  
>>> would mean that policy placement  adjacent to the MX record would  
>>> be the only location any policy  record would need to exist.  In  
>>> this case, the discovery process  itself indicates whether or not  
>>> the sub-domain is USED/UNUSED.
>> example, if
> I was referring to MX expansion and how each DNS client within a  
> SMTP client may behave.  More below.
>
> Yup, and IMO, I can almost guaranteed the idea will be killed  
> ASAP.  I would vote against it.
>
> I seriously doubt people will begin to screw around with their  
> various retries logic.  Plus, you are going to hear those who say  
> MX is about inbound, not outbound and "Never The Twain Shall Meet."

This is not about using MX records as a means to resolve an outbound  
path.  This is only about confirming the domain used in an email- 
address simply exists.  Existence is determined by the mere existence  
of records used to discover the inbound path for the email-address.   
This does not require that inbound and outbound servers be one-in-the- 
same.

"Proof of use" would not require that any IP address match that of  
the SMTP client, or that the email-address domain associated with an  
MX also provide an A record, or that an A record actually locate an  
SMTP server.

-Doug

---

From: John L <[email-masked]>
Date: Sat, 9 Jun 2007 15:39:13 -0400 (EDT)

> record (Hector's claim that some MX records return IPs confused me).

Right.  It is true that some misconfigured MX records contain a name that 
looks like an IP address and is probably intended to be the IP address of 
the server, but I'm not interested in going down the road of second 
guessing all the ways that people can screw up their DNS, so we'll ignore 
that.

> instead and deliver to the resulting IP.

That should be ALL MTAs, since the RFCs have always said that's what you 
do.

> lookup fails be brought to the SMTP group?

I'm sure this has come up before, but it's probably worth running by them 
again.  This was intended to be a transitional feature 25 years ago, and 
given how few legit MTAs are identified by A records, we should try to 
declare the transition to be over.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Jun 2007 16:51:42 -0400

John L wrote:

> I'm sure this has come up before, but it's probably worth running by 
> them again.  This was intended to be a transitional feature 25 years 
> ago, and given how few legit MTAs are identified by A records, we should 
> try to declare the transition to be over.

Good luck!!!

It has nothing to do with many "few legit" exists (which is more than 
you think), but how many legacy and current SMTP systems exist that 
would have to be updated!!   Expecting burned in stone working history 
of all the many smtp servers out there, with continued clear cut 
operational issues with sysops, to alter their system for this is asking 
a bit much.

A reminder from the 2821 standard:

5. Address Resolution and Mail Handling

    ....... The lookup first attempts to locate an MX
    record associated with the name.  If a CNAME record is found instead,
    the resulting name is processed as if it were the initial name.  If
    no MX records are found, but an A RR is found, the A RR is treated as
    if it was associated with an implicit MX RR, with a preference of 0,
    pointing to that host.  If one or more MX RRs are found for a given
    name, SMTP systems MUST NOT utilize any A RRs associated with that
    name unless they are located using the MX RRs; the "implicit MX" rule
    above applies only if there are no MX records present.  If MX records
    are present, but none of them are usable, this situation MUST be
    reported as an error.

That said, some systems, such as our own, have a one attempt only for 
the "Implicit MX" rule. i.e. No MX -> A Lookup --> 1 attempt only.

This past week alone we would have electronic mail communications fails 
with legit customers lacking MX records if this rule was enforced.

I just can't see this happening.  I will have to see snow balls falls 
from these South Florida skies before I would have our SMTP system 
changed.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 9 Jun 2007 14:59:30 -0700

On Jun 9, 2007, at 1:51 PM, Hector Santos wrote:
>
> That said, some systems, such as our own, have a one attempt only  
> for the "Implicit MX" rule. i.e. No MX -> A Lookup --> 1 attempt only.
>
> This past week alone we would have electronic mail communications  
> fails with legit customers lacking MX records if this rule was  
> enforced.
>
> I just can't see this happening.  I will have to see snow balls  
> falls from these South Florida skies before I would have our SMTP  
> system changed.

The concept is to first deprecate use of A records for discovering  
inbound SMTP servers.  After some period of time, then obsolete the  
use of A records for this purpose.

Any receiving SMTP wishing to take full advantage of DKIM and any  
exclusions afforded by DKIM policy will need to:

  - implement DKIM signature verification and,
  - verify use of the domain.

  (Initially this would be by checking for either MX or A records.)

Publishing DKIM policy becomes easier to administer once A record  
discovery is obsoleted.  When DKIM policy is intended to defeat sub- 
domain spoofing, domains will need to publish policy at every domain  
level containing an A or MX record.  Once A record discovery is  
obsoleted, then policy would only need publishing adjacent to MX  
records.

- The alternative is a registry domain list and domain transversal  
searches. (More work for receiving MTAs)
- Publishing policy and wildcarded policy records at _every_ DNS  
node. (More work for sending MTAs while also risking DNS wildcard  
related exploits.)

There will not be instant compliance regarding DKIM's policy  
exclusions of bogus messages.  DKIM + Policy alone may remain  
ineffective as an exclusionary mechanism, regardless of publication  
methods.

"Proof of use" establishes a basis to exclude much more than just  
bogus DKIM messages.  Why not simplify how "proof of use" can be done  
efficiently?

-Doug

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Jun 2007 20:42:41 -0400

Douglas Otis wrote:
>> fails with legit customers lacking MX records if this rule was enforced.
>>
> inbound SMTP servers.  After some period of time, then obsolete the use 
> of A records for this purpose.

Well Doug, go ahead and proposed it, write an I-D, see how it flies in 
IETF-SMTP.  And while you are there see if you get the IMC.ORG to stop 
using MAIL.IMG.ORG as the return path domain WITHOUT a MX record.

Using your concept, you effectly stopped all bounce mail back to their 
return path.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Sat, 9 Jun 2007 18:56:20 -0700

On Jun 9, 2007, at 5:42 PM, Hector Santos wrote:

>> inbound SMTP servers.  After some period of time, then obsolete  
>> the use of A records for this purpose.
>
> Well Doug, go ahead and proposed it, write an I-D, see how it flies  
> in IETF-SMTP.  And while you are there see if you get the IMC.ORG  
> to stop using MAIL.IMG.ORG as the return path domain WITHOUT a MX  
> record.
>
> Using your concept, you effectly stopped all bounce mail back to  
> their return path.

Hector,

You seem to have confused the concept of deprecate and obsolete.  The  
suggestion was to deprecate the use of A records for discovery.  (As  
in suggesting this will soon become obsolete.)
This suggestion will not cause mail.imc.org to cease functioning.   
(Don't expect this field to be tested with respect to DKIM either.   
Refusing a message due to a failure to confirm "proof of use" based  
solely upon MX records would be far less disruptive than refusing to  
discover a return-path using A records.)

Nothing can be done quickly.  Any changes to email will take time.   
Ideally, these changes will result in a cleaner and easier to manage  
set of records.  This goal would tend to exclude any type of wildcard  
scheme.  Searching up domains also generates a fair amount of  
NXDOMAIN traffic.

The cleanest approach is to simply publish policy records adjacent to  
MX records.  Over time, this should be all that is needed.  Those  
being phished might wish to publish policy records adjacent to their  
A records for the period of time it takes to obsolete A record  
discovery.  This would likely depend upon how likely A records are  
used to spoof domains.

Those developing phishing filters which utilize DKIM can also readily  
utilize policy information found adjacent to MX records.  Much of  
what needs to be stopped often can not be determined by email- 
addresses within headers.  The general appearance of a message body  
along with a likelihood the From email-address can not be clearly  
viewed is often how people are being fooled.  A policy record next to  
the MX record, even when only used to instruct anti-abuse message  
filters, will go a long way in preventing much of the abuse without  
becoming disruptive.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Jun 2007 23:57:55 -0400

Douglas Otis wrote:

> suggestion was to deprecate the use of A records for discovery.  (As in 
> suggesting this will soon become obsolete.)

HA!  I call this a state of purgatory!! :-)

> [CLIP]

Doug, this all sounds great.

But you still need to convince Paul to fix the return path for all
the managed IETF mailing list before you can even begin to discuss this
in IETF-SMTP. :-)

Once the argument is thrown out that only a "Few legit" systems still 
exist, hence it is safe to enforce a MX record, people will point that 
that not even an IETF entity is following the very concept you wish to 
make obsolete. So its not going to be very convincing that it now safe 
to do what you want across the board, yet alone change the SMTP 
specification.

This reminds me of the classic scene in Dumb and Dumber:  "What are my
chances?"  "Like one in a million"  "So I still have a chance!?"  :-)

-- 
Sincerely

Hector Santos, CTO

---

From: Jim Fenton <[email-masked]>
Date: Sun, 10 Jun 2007 22:16:44 -0700

Hector Santos wrote:
> First you made a statement that the "DKIM WG has no authority to
> create a  policy framework describing the overall use of email, just
> the use of DKIM."
>

I'm just saying that there's way to accomplish very much the same thing
as is being requested by expressing the policy in a way that is (IMO)
in-scope for the DKIM working group.

I am not trying to dictate receiver design.  Receivers can continue to
do whatever they want.  But many receivers will be interested in the
alleged sending domain's suggestion for how they would like unsigned
mail supposedly from their domain to be handled.  There is no mandate
for the receiver to do so.

>
> Just think about this:
>
> Do you considered a message that is not DKIM signed has a presumption
> of invalidity?  Thus promoting a SSP check?

There is no presumption of invalidity, any more than there is a
presumption that messages being content filtered are spam.  If SSP says
that the messages should have a valid signature and they don't, then
there might be a presumption of invalidity (although I would prefer to
call it "suspicious") but that a result of the SSP check, not a
presumption of an unsigned message by itself.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Mon, 11 Jun 2007 07:28:40 -0400

Hi Jim,

I appreciate your comments.

Thats the thing, it is not the same thing.  I will explain how below.

 > do whatever they want.

No, not really.  With NOMAIL eliminated under the incorrect theory that 
it is redundant policy and be emulated or "accomplished very much the 
same thing", you have inadvertently dictated a specific receiver design.

Here's how:

NOMAIL BASELINE:

For the sake of illustration, lets assume that NOMAIL was part of the 
requirement, as it was part of the original SSP specification.  This was 
allow us to establish the BASELINE GOAL for comparison.

The goal here is to declare the strong policy with a clear and 
definitive, zero false positive, declaration by a domain to eliminate 
the random and indirect abuse of their unauthorized domain.  This is one 
of the highest abusive currently going on. Random exploitation of domains.

In short, the RECEIVER, who has a high interest in eliminate abuse as 
well, has a clear and definitely signal from the DOMAIN that the usage 
of the domain for electronic mail was illegal and not expected, 
therefore the receiver has a strong opportunity to eliminate the 
"suspicious" unauthorized message.

What is critical important here is that the NOMAIL policy can be 
considered regardless if the mail is signed or not.  Hence this has 
optimization considerations for receivers and clear and definitive 
declarations by the domain.

NOMAIL EMULATION:

Now, we eliminate this NOMAIL policy that 100% blocks and protects 
domain from unauthorized usage from the SSP requirements because some 
feel it is redundant and the same goal can be accomplished by other means.

So what are these other means that "emulate" the same the NO-MAIL policy?

Regardless of the methods are used that satisfies the current as written 
requirements, it must handle the following two possible scenarios:

   - Incoming message is signed
   - Incoming message is not signed

Again, the GOAL here is to end up with a NO-MAIL emulation.

1) Handling Signed Mail:

   In this case, we have a signature header selector and we have the
   From domain:

   1.1) DKIM-Signature selector returns NXDOMAIN
   1.2) DKIM-Signature selector returns NULL KEY (intentionally bogus)
   1.3) From domain returns a SSP record with NEVER SIGN

2) Handling Unsigned Mail:

   In this case, we only have the From domain:

   2.1) From domain returns a SSP record with ALWAYS SIGN

As you can see, there is a From domain SSP policy conflict with mail 
that is either signed or not signed.

If the email was signed,  you have enforced the receiver design to 
always do the DKIM verification first. There is more overhead which can 
only by reduced by creating a design that does a PUBLIC KEY lookup first 
to see if there is a public key  (1.1, 1.2)

If the receiver did 1.3 first (check SSP), then it conflicts with the 
NON-SIGNED mail scenario 2.1 where you will need a "ALWAYS SIGN" policy 
to handle the non-signed mail scenario.

So you now dictated a receiver design where it MUST do a DKIM 
verification first if the message is signed and if it wants to reduced 
overhead, it will need to check for the PUBLIC KEY first and perform the 
HASHING only if the key is not NXDOMAIN or not NULL.

If the message is not signed, then the only POLICY you can have here is 
a "ALWAYS SIGN" policy.

But as I indicated, you can not create a "ALWAYS SIGN" if you want to 
cover the signed mail situation where you will need instead a "NEVER 
SIGN" policy.

If the domain did declare a "ALWAYS SIGN", then you dictated a Receiver 
Design that an only work one way.

Did that make sense to you?

In summary, to have a NOMAIL policy, you have dictated the following in 
order to satisfy the as written requirements:

o KEY and SSP records setup for a NOMAIL emulation

    - DKIM: Bogus Public NULL Key
    - SSP:  Never Sign Policy

o Verification Logic:

    1) If the mail is not signed, check SSP for "NEVER SIGN" policy

    2) If the mail is signed, check Public KEY for "Bogus Null Key"

       - Do not perform HASH first - this will create overhead

       2.1) if the key is not bogus, perform the hashing, verify
            with key.

       2.2) if the signature is invalid, check SSP for "NEVER SIGN"

       2.3) if the signature is VALID, no check for SSP

            - POSSIBLE SECURITY LOOPHOLE

And this is great Jim, but you can't do it any other way.  The loophole 
in 2.3 is theoretically possible, low chance, but possible.

Overall, I have determined that a SSP check should be done first at ALL 
times.  This goes against the requirements.  Otherwise may disagree with 
my determination, and thats fine.  But I am even given the chance to 
optimize the DKIM/SSP implementation in our system.

You may say that I'm not restricted from doing a SSP check first, and 
you would be correct.

If I did SSP first:

If the message is not signed, a SSP "ALWAYS SIGN" policy will work 
ideally here.

If the message is signed, a SSP "ALWAYS SIGN" policy will not work 
ideally here, because it will break step 2.2 above..

So now you have create a high overhead potential by forcing me to only 
do it your way to minimize the possible "NO MAIL" scenarios and you 
removed the ability to close the possible security hole.

If a system is getting hit hard with SPAM, and most are, the odds are 
very good that as DKIM is adopted, that it will be included high among 
this group of unwanted failures.

A NOMAIL policy is clear, definitive, no-overhead situation. It doesn't 
go against any design any one wishes to do.

> presumption of an unsigned message by itself.

As I shown above, you can't use a "ALWAYS SIGN" policy to cover the 
unsigned mail transactions because this will conflict the failed signed 
message condition.

The receiver is left in limbo.

The design is very complex, and I avoid the 3rd party issues above.  But 
if you begin to throw that in, it really gets messy, when all along, the 
domain simply was trying to say "I DO NOT SEND MAIL" - a condition that 
an direct and straight SSP policy would satisfy without any specific 
design or overhead issue.

Again, if an implementator has reduced options to get the job done as 
they think fits the bill for them system, then the current requirements 
without NOMAIL is dictating a receiver design.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Mon, 11 Jun 2007 08:41:23 -0400

Jim,

I'm sorry, in my vain attempt to reduce the complexity of the problem 
and my past post to you, I had removed complex 3rd party analysis and 
incorrectly changed a few conclusions.

The final conclusion is the same:

    As a implementator, with NOMAIL removed, my design options are
    reduced, the design is predetermined and more complex in order
    to help protect domains from unauthorized domain usage and
    to help reduce incoming mail system abuse.

Let me summarize it this way:

A NOMAIL "Emulation" must cover the basic mail scenarios:

   - Unsigned Messages,
   - Signed Messages,

For unsigned mail, you can only used a "I ALWAYS SIGN" policy because 
there would be no DKIM-Signature header to check the selector for a 
possible bogus null public key.

Thats a given.  You must use a "I ALWAYS SIGN" policy to cover the 
unsigned mail scenario.

For the signed mail scenario, using a bogus key can be used.

In short, to duplicate this NOMAIL emulation, you have:

   o Domain Public Key and SSP records for a NOMAIL emulation

     - DKIM: return Bogus Public NULL Key
     - SSP:  return "I ALWAYS SIGN" Policy

The problem, which included  3rd party conditions that I incorrectly 
removed and changed the wording, is when:

   - the DKIM-Signature header selected produces a NXDOMAIN, and
   - the signed message is by a 3rd party.

If the selector lookup returns NXDOMAIN, DKIM-BASE allows a 451 response 
code to occur under dynamic SMTP implementations (checking is done at 
SMTP) conditions.   For POST SMTP (message is accepted first) 
implementations, this conflicts with protection against ACCEPT/BOUNCE 
abusive operations.

If the selector lookup returns 3rd party conditions and the signature is 
valid but the domain did not expect mail from this FROM domain, 
requirement 5.3 item 8 creates a conflict:

    8.   There is no requirement that SSP publish a Practices of any/all
         third parties that MUST NOT sign on the domain holder's behalf.
         This should be considered out of scope.

So in summary:

1) Is not possible to fully emulate the NOMAIL scenario using other 
means using the current requirements.

2) The lack of a NOMAIL enforces a specific design that requires us to 
do key and hash checking which creates unnecessary possible overhead.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 11 Jun 2007 13:43:24 +0100

+1

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Jun 2007 08:55:05 -0700

On Jun 11, 2007, at 5:43 AM, J.D. Falk wrote:

>>> "It's all spam" is about the simplest useful advice a (non)  
>>> sender can give.  In my case, which I don't think is unusual, I  
>>> get buckets of spam and blowback to subdomains that have never,  
>>> ever, sent a real message.  The domains are the names of  
>>> computers on my network, which were probably scraped out of  
>>> usenet or mail archive message IDs.  If receivers were to reject  
>>> or drop all mail purporting to be from those domains, it would be  
>>> uniformly better both for the receivers (less spam, cheap filter)  
>>> and for me (less blowback.)
>> +1
>
> +1

'Proof of use' as acceptance criteria should also eliminate much of  
this.  Deprecating and then obsoleting A record discovery would  
safely arrive at this goal.

Use of * MX "." would be something a root server will be unable to  
defending against.  If this were to become popular, these records may  
lead to a type of DDoS attack against the root servers.  This  
construct assumes millions of email applications will be modified to  
recognize "." as an invalid domain name.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Mon, 11 Jun 2007 09:00:36 -0700

On Jun 11, 2007, at 8:55 AM, Douglas Otis wrote:

>>>> or drop all mail purporting to be from those domains, it would  
>>>> be uniformly better both for the receivers (less spam, cheap  
>>>> filter) and for me (less blowback.)
>>> +1
>>
>> +1
>
> defending against.  If this were to become popular, these records  
> may lead to a type of DDoS attack against the root servers.  This  
> construct assumes millions of email applications will be modified  
> to recognize "." as an invalid domain name.

Why do you believe this?

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Jun 2007 09:47:21 -0700

On Jun 11, 2007, at 9:00 AM, Steve Atkins wrote:

>>>>> usenet or mail archive message IDs.  If receivers were to  
>>>>> reject or drop all mail purporting to be from those domains, it  
>>>>> would be uniformly better both for the receivers (less spam,  
>> 'Proof of use' as acceptance criteria should also eliminate much  
>> of this.  Deprecating and then obsoleting A record discovery would  

Largely based upon the advice of a root operator.  May I suggest this  
issue be taken to a DNS WG.  Few protocols compare to email's ability  
to directly induce third-parties into making DNS transactions.  As  
such, email design should be cognizant of dangers associated with  
this anonymous push model.

-Doug