Subject: [ietf-dkim] Jim's issues - one more try

From: Stephen Farrell <[email-masked]>
Date: Fri, 08 Jun 2007 10:47:01 +0100

Let's try get back to Jim's issues. What we need to do is help
get ssp-00 out so that we have an I-D as a basis for discussion.

What I'd like to do is get a sense of what we'd like to see
in draft-ietf-dkim-ssp-00, in terms of the options that Jim
(as editor) has chosen. (So please don't start with your
favourite alternative approach, at least not in this thread.)

At this stage its perfectly fine to want to see how something
pans out, and ask for it to be included now, but later ask for it
to be changed/removed - this isn't WGLC, we're just helping the
authors decide what to include in the -00 version.

I think that Jim is planning to edit -00 in the coming days
so if you say nothing, he'll just pick what he wants to include.
If you say too much, he'll also just pick what he wants to
include. If its inconclusive, he'll also just pick what he
wants to include.

To that end, please respond, by Monday, to this with +1/-1's as
described below (the description of the issues is from Jim's
original mail [1]):

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

    Issue#1: +1 - include use of XPTR as part of ssp-00
    Issue#1: -1 - exclude use of XPTR from ssp-00

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

    Issue#2: +1 - Define how to use a TXT RR for SSP policies (with or
                  without something else)
    Issue#2: -1 - Don't use TXT at all, only use new RRs for SSP

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

    Issue#3: +1 - Define an upward query based approach to finding SSP
                  statements
    Issue#3: -1 - Define a wildcard based approach to finding SSP
                  statemetns

Stephen.

[1] http://mipassoc.org/pipermail/ietf-dkim/2007q2/007537.html

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Jun 2007 9:03:03 -0500

>    Issue#1: -1 - exclude use of XPTR from ssp-00

+1

>    Issue#2: -1 - Don't use TXT at all, only use new RRs for SSP

+1

>    Issue#3: -1 - Define a wildcard based approach to finding SSP

-1

>[1] http://mipassoc.org/pipermail/ietf-dkim/2007q2/007537.html
Scott K

---

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

On Jun 8, 2007, at 2:47 AM, Stephen Farrell wrote:

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

-1

+1

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

Not +1

and Not -1

There are two other options:

- Anchor policy to existing records such as the MX or A record that  
would be used as "proof of existence".

- Establish a registry to mitigate the damage that would other be  
done to SLDs.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Fri, 8 Jun 2007 10:33:06 -0400 (EDT)

+1

+1

	Wietse

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Jun 2007 11:00:56 -0400

-1

+1

>    Issue#3: -1 - Define a wildcard based approach to finding SSP

Either, I guess that 0

-- 
Sincerely

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 08 Jun 2007 08:34:33 -0700

Stephen --

This list of yes/no's is not helpful is it quite possible to permute
these independent variables and arrive with something that cannot
work. What we *really* *really* need is an *exact* proposal that
claims to solve this problem so that we can evaluate the alternatives
against the Requirements, as well as their other merits. Design by
hum here is doomed to fail.

My suggestion: require those *fleshed out* proposals to be submitted as
ID's so that we can have time to read them, get clarification and
consider the tradoffs. Yes, an ID not just one-off wg mailing list
handwaving messages.

		Mike

---

From: Damon <[email-masked]>
Date: Fri, 8 Jun 2007 11:45:28 -0400

-1

+1

>    Issue#3: -1 - Define a wildcard based approach to finding SSP

I lean heavily towards -1 but will go for a +1

Regards,
Damon Sauer

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 08 Jun 2007 16:50:39 +0100

Mike,

Those were the questions for which Jim was looking for guidance
in the production of draft-ietf-skim-ssp-00. As I said, I don't
think we're setting anything in stone at this point (e.g. responses
so far all picked the "do a TXT RR" option - regardless of what
you think of that technically, it may just not fly in the IETF,
but even so, I'd have no problem if -00 says to use TXT.)

I don't think we want to have a number of I-Ds on the table,
but rather one WG draft, that will evolve over the next few
months. We did that already and make little progress with
four different proposals. Yes, we now have the requirements
agreed, but I think we've seen this week on the list that
people will stray from those if given the chance;-) I'd
much prefer we concentrate on one I-D from now on - its
basically the only way we can have a chance to meet our
charter goal of WGLC on SSP by November.

So, I'd ask you to suspend your disbelief until Jim's
managed to get that -00 out.

Then, if you still feel there's a need for more I-Ds, I guess
you can write draft-thomas-dkim-ssp-00 if you think that's a
better approach than working to get a draft-ietf-dkim-ssp-01
that you think works,

Sound reasonable?
S.

Michael Thomas wrote:
>> were about 20 messages discussing this from 5 people.  I'm not reading 
>> a clear consensus on this.
>>
>> 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.
>>

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Jun 2007 09:24:24 -0700

+1

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Jun 2007 09:42:08 -0700

> S.

Stephen,

Exclusion of possible overall strategies based upon votes for various  
abstract elements is _not_ a good approach.  Nor does it appear to  
provide a reasonable basis for cobbling together a draft.  Allow this  
process to take the time it might require.  In the past, email  
related WGs have placed a reliance upon _unsafe_ DNS practices.  The  
proverb "Look before you leap" would seem to apply.

Those victimized by ill-considered email mechanisms should and  
eventually will have greater input.  The "how" is more important than  
the "what" at this point in the process.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 08 Jun 2007 17:47:56 +0100

Douglas Otis wrote:
 > ...Allow this
> process to take the time it might require.  

draft-ietf-dkim-ssp-requirements-00 was published on 2006-08-10

I think we've mulled this enough and its time to start producing
results.

Stephen.

---

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

>> consider the tradoffs. Yes, an ID not just one-off wg mailing list

+1. Might be a cue to rehash DSAP with the new considerations,

-- 
Sincerely

Hector Santos, CTO

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 8 Jun 2007 11:58:18 -0700

> Let's try get back to Jim's issues. What we need to do is 
> help get ssp-00 out so that we have an I-D as a basis for discussion.

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

+1

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

+1

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

-1

---

From: Jeff Macdonald <[email-masked]>
Date: Sat, 9 Jun 2007 13:43:00 -0400

-1

+1

-1

-- 
:: 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: Eric Allman <[email-masked]>
Date: Mon, 11 Jun 2007 15:02:37 -0700

>     Issue#1: -1 - exclude use of XPTR from ssp-00

0 (if the decision is to go TXT-only, then -1, else neutral).

>     Issue#2: -1 - Don't use TXT at all, only use new RRs for SSP

+1 (with a new RR that is searched ahead of TXT).

>     Issue#3: -1 - Define a wildcard based approach to finding SSP

This isn't independent of Issue#2.  If we use existing RR types (TXT, 
no XPTR) then we are pretty much constrained to +1.  If we use a new 
RR type of some sort, then I prefer -1.

My thought would be to search for a new record type if you can (i.e., 
if your resolver supports the new type, be it XPTR or SSP). 
Wildcards would be used to catch these.  If you can't, or if there is 
no such record, then fall back to TXT, at which point you have to 
search up the tree.  The intent would be to (someday) deprecate the 
TXT search, if possible, which it probably isn't, but it does give 
you a way to do the lookups more efficiently (wildcarding) if both 
sides are willing to play.  My hunch is that most of the big players 
will.

eric

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Jun 2007 15:48:00 -0700

On Jun 11, 2007, at 3:02 PM, Eric Allman wrote:

> My thought would be to search for a new record type if you can  
> (i.e., if your resolver supports the new type, be it XPTR or SSP).  
> Wildcards would be used to catch these.  If you can't, or if there  
> is no such record, then fall back to TXT, at which point you have  
> to search up the tree.  The intent would be to (someday) deprecate  
> the TXT search, if possible, which it probably isn't, but it does  
> give you a way to do the lookups more efficiently (wildcarding) if  
> both sides are willing to play.  My hunch is that most of the big  
> players will.

It would appear section 5.1 item 3 of SSP requirements excludes use  
of wildcards.

  3.  SSP's publishing mechanism MUST be defined such that it does not
      lead to multiple records of different protocols residing at the
      same location.

A wildcard record of any type MUST appear at the _same_ location as  
those of other protocols also making use of a wildcard resource record.

If SSP were to define a new RR type, must this RR type always remain  
backward compatible, or would there be versioned RRsets?  It seems  
likely other protocol extensions will attempt to extend such an RR  
record, much as was done with TXT RRs.

-Doug

---

From: Eric Allman <[email-masked]>
Date: Mon, 11 Jun 2007 16:15:32 -0700

--On June 11, 2007 3:48:00 PM -0700 Douglas Otis 
<[email-masked]> wrote:

>>  Wildcards would be used to catch these.  If you can't, or if
>> there   is no such record, then fall back to TXT, at which point
>> you have   to search up the tree.  The intent would be to
>> (someday) deprecate   the TXT search, if possible, which it
>> probably isn't, but it does   give you a way to do the lookups
>> more efficiently (wildcarding) if   both sides are willing to
>> play.  My hunch is that most of the big   players will.
>

My interpretation of that is that a "place" is defined by an RR type 
as well as the address --- this requirement is to avoid overloading 
of TXT records.

> If SSP were to define a new RR type, must this RR type always
> remain backward compatible, or would there be versioned RRsets?  It
> seems likely other protocol extensions will attempt to extend such
> an RR record, much as was done with TXT RRs.

I'm assuming no versioning, and that other protocols would define 
their own RR types.

eric

---

From: Michael Thomas <[email-masked]>
Date: Mon, 11 Jun 2007 17:22:37 -0700

Douglas Otis wrote:
>> if your resolver supports the new type, be it XPTR or SSP). Wildcards 
>> would be used to catch these.  If you can't, or if there is no such 
>> record, then fall back to TXT, at which point you have to search up 
>> the tree.  The intent would be to (someday) deprecate the TXT search, 
>> if possible, which it probably isn't, but it does give you a way to do 
>> the lookups more efficiently (wildcarding) if both sides are willing 
>> to play.  My hunch is that most of the big players will.
> 
> It would appear section 5.1 item 3 of SSP requirements excludes use of 
> wildcards.
> 

No, the draft is ambiguous here. The intent is multiple RR's of the
_same_ kind, or I suppose within the same RR. Ie, let's not redo the
SPF/SIDF fiasco of overloading the same RR at the same node. I've
fixed that.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Jun 2007 17:28:05 -0700

On Jun 11, 2007, at 4:15 PM, Eric Allman wrote:

>
> My interpretation of that is that a "place" is defined by an RR  
> type as well as the address --- this requirement is to avoid  
> overloading of TXT records.

Eric,

Policy related wildcard RRs are intended for non-existing sub- 
domains, however a Wildcard RR will not synthesize a resource record  
for all sub-domains.  Full coverage therefore requires both non- 
wildcard and wildcard instances of resource record be placed at  
_every_ existing DNS node below or at the domain level where coverage  
is desired.  It is not clear whether even illegal domain names are  
safe to ignore.

Rather than devising schemes that return policy records for _every_  
possible label (revealing zone structure), existing domains used for  
email are already evidenced by appearance of MX (and A) records  
necessary for a discovery process.  The anachronistic necessity of A  
records in a discovery process has long since passed.   Within a  
similar time frame, support of A record discovery can be announced as  
deprecated, and then obsoleted when a few domains begin to refuse  
messages from domains lacking MX records.

When a message is received that is considered _not_ signed, a query  
would be made for an MX (or A) record.  All resource records for this  
domain might be requested to expedite discovery of either MX (or A).   
When a policy record is placed below a prefix label, these records  
will not be returned by a query at the domain.  This record would be  
at a different location.  Use of a prefix therefore reduces the  
number of partial answers that might then demand separate specific  
DNS transactions.  However, wildcard records will be at this common  
location.

  So when wildcard records are not used,
  after receiving a message considered not signed:

   - When neither an MX (or A) record are found, refuse the message.
   - When an MX (or A) record are found, query for a policy record.
   - When no policy is found, there is no policy. (Searching not  
required.)
   - When policy requires DKIM signatures, refuse the message.

This approach will not require wildcards or the transversal (up or  
down) of domain labels.

Assume a message being received is from a bad-actor more than 90% of  
the time.  A bad-actor will spoof _any_ number of sub-domains.  A  
scheme returning a policy record for each spoofed sub-domain creates  
a separate instance of a (likely bulky) policy record.  Just as there  
are an infinite number of domains a bad-actor might wish to spoof,  
there would be an infinitely higher demand placed upon DNS cache and  
transport.  Each query will be generating fresh traffic, and placing  
a demand upon the cache.

Checking for an MX or A record is also likely to detect more spoofing  
than would checking for a policy record.  MX (and A) records MUST be  
present, whereas there will be only a small percentage of a new RR  
type published.  As currently constrained, this DKIM policy is unable  
to cause the refusal of messages from a bogus domain unless all  
messages MUST BE SIGNED.  However, such a policy will prove  
disruptive in many cases.  Hence, utilization of existing MX (and A)  
records will prove more effective at mitigating domain spoofing than  
will use of wildcard policy records.

-Doug

---

From: Jon Callas <[email-masked]>
Date: Mon, 11 Jun 2007 17:34:07 -0700

+1

+1

>    Issue#3: -1 - Define a wildcard based approach to finding SSP

- -1, but I agree with Eric that if we end up with exiting RR types,  
then we kinda have to make it +1.

	Jon

---

From: Hector Santos <[email-masked]>
Date: Mon, 11 Jun 2007 22:42:56 -0400

> those of other protocols also making use of a wildcard resource record.

I didn't read this that way.

In lieu of a brand new RR number usage for SSP, i.e, TXT record lookup, 
I took this to basically mean that an unique prefix for SSP is required 
in order to avoid collisions with other protocol usages of a TXT record.

Mike's follow up to you suggest he was simply trying to avoid the 
"SSP/SIDF Fiasco."

Well, I don't know what "FIASCO" he is referring too, but now it seems 
that he meant avoiding multiple RR records responses period - whether it 
was different protocols or not.

The only design issue I remember with SPF/SIDF and multiple TXT records 
is that when the 512 buffer was exceeded and the server automatically 
split the response blocks.   The DNS client has to be ready for that. 
Other than that, the v= tag help detect the proper TXT record.

Anyway, he is right that he needs to fix the semantics up.  The only way 
I can see avoiding this is by:

    - The use of a specific RR number, and
    - Avoiding long records.

or

    - Using a unique prefix or infix tag,
    - Including a protocol ident tag, i.e. v=SSP1, and
    - Avoiding long records.

-- 
Sincerely

Hector Santos, CTO

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 11 Jun 2007 23:05:40 -0500

>   Issue#1: -1 - exclude use of XPTR from ssp-00

I confess to not completely understanding this one so I'm neutral on it.

+1

 > Issue#3: -1 - Define a wildcard based approach to finding SSP

I agree with what Eric said on this point.

Arvel

---

From: Jim Fenton <[email-masked]>
Date: Mon, 11 Jun 2007 22:07:45 -0700

Just for the record:

-1

Rationale: XPTR is mostly for making the SSP mechanism more extensible
for expressing other sorts of policy.  It requires an additional lookup,
the other things it deals with are outside the scope of DKIM, and this
issue of general policy and extensibility is better dealt with by the
DNSEXT working group.

>    Issue#2: -1 - Don't use TXT at all, only use new RRs for SSP

0

Rationale:  I think that using a new RR is the right thing to do, but I
don't know all of the deployment issues.

+1

Rationale:  Required to support TXT RR (what I think is what we'll end
up with).  Even with a new RR, it avoids the need to publish an
additional new-RR record to go with every other label in the zone to
deal with the characteristics of DNS wildcarding.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Jun 2007 09:00:53 -0700

On Jun 11, 2007, at 10:07 PM, Jim Fenton wrote:

> Rationale:  Required to support TXT RR (what I think is what we'll  
> end up with).  Even with a new RR, it avoids the need to publish an  
> additional new-RR record to go with every other label in the zone  
> to deal with the characteristics of DNS wildcarding.

Jim,

Your conclusions seem correct, however they exclude the possibility  
of first checking the existence of MX or A records.  Checking the  
existence of MX or A records is an alternative to domain transversal  
of the use of wildcards.  The DKIM policy is limited and unable to  
indicate whether a domain is bogus anyway.  This means recipients  
will be unable to differentiate between broken signatures and bogus  
domains.  Checking the existence of MX or A records ensures bogus  
domains are avoided.

For many years at least, DKIM policy will be present within a small  
percentage of domains sending email.  What this means for recipients,  
is that most domain transversals will either begin or end at the TLD  
without any benefit.  This will also cause SLDs to experience a high  
amount of unanswered transactions.  The desire to use a wildcard or  
domain transversals is to detect bogus domains.  Checking the  
existence of MX or A records provides a much safer, more effective,  
and simpler method.  Every valid email-address domain MUST publish  
either an MX or A record.  A request for ANY record at the email- 
address domain is likely to return the desired information within a  
single DNS transaction.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Jun 2007 21:28:21 -0400

Douglas Otis wrote:
> Your conclusions seem correct, however they exclude the possibility of 
> first checking the existence of MX or A records.  Checking the existence 
> of MX or A records is an alternative to domain transversal of the use of 
> wildcards.  The DKIM policy is limited and unable to indicate whether a 
> domain is bogus anyway.  This means recipients will be unable to 
> differentiate between broken signatures and bogus domains.  Checking the 
> existence of MX or A records ensures bogus domains are avoided.
> 
> percentage of domains sending email.  What this means for recipients, is 
> that most domain transversals will either begin or end at the TLD 
> domain transversals is to detect bogus domains.  Checking the existence 
> of MX or A records provides a much safer, more effective, and simpler 
> method.  Every valid email-address domain MUST publish either an MX or A 
> record.  A request for ANY record at the email-address domain is likely 
> to return the desired information within a single DNS transaction.

My desire at 2822 is detect bogus 2822 policies.

My desire at 2821 is detect bogus 2821 transactions.

TWO DIFFERENT THINGS!

For our package, we already do MX checks with its CBV feature.

But overall bad people fall thru the 2821 cracks, hence why I thought 
the purpose of this PROJECT was to invent a 2822 solution?

Anyway, our statistics tell me atleast 84% of the time:

         2821.Mail From == 2822.From

That is based on over 2 years of daily accumulated logs from various 
cross section customer sites who participated in our analysis.  Millions 
of transactions.

This is why I think the SENDER-ID "Patented Business Method" was 
frivolous and atleast for 84% of the time the resolution at 2821 
satisfies the result you are looking for. Performing SENDER-ID at 2822 
creates high payload overhead issues.

But like SENDER-ID, now you are asking we incorporate more MX/A logic at 
2822 and the only way to optimize this is to signal this rule when:

        2822.Return-Path != 2822.From

So for atleast 16% of the time, we may have to do more MX/A lookup 
logic. Not a bad consideration, being that is will only be considered 
16% of the time.

However, what if the MX/A is not bogus?

Do you still check for POLICY records?

What if the implementator decides to not do a MX/A check at 2821, but to 
delay it until 2822 thinking that it would have to do the 2822.FROM and 
possible 2822.Return-Path MX/A checks?

In other words, this idea will require a SSP specification that says:

      - You may split the SSP logic between 2821 and 2822.
	
         a) Logic for 2821
         b) Logic for 2822

Because if it does not, you create overhead on systems that may already 
have some form of MX/A logic.   Or do they not count?  And they must 
MOVE all MX/A logic to 2822?  In this case, we create a potential high 
payload overhead problem again.

Finally, how reliable is a ANY query?  And wouldn't this exert more DNS 
network overhead pressure with larger size than probably necessary 
responses?

Basically, I think mixing MX/A 2821 considerations with the 2822 Sender 
Policies considerations creates a big mess to get straight.

Now we are more about Application Level design considerations - 
designing a package for the email infrastructure, altering and 
dedicating various changes and how things are done.

But that shouldn't stop a specific vendor from putting together a 
integrated suite of ideas for his own system - something many already do.

In any case, completing SSP, IMO, should stand on its own and it should 
not be dependent on MX/A.

IMV, if MX/A 2822.FROM logic was incorporated,  I would like to see 
first what percentage is NXDOMAIN.  If it is a low amount, then we have 
a higher DNS overhead issue.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Jun 2007 22:09:32 -0400

> deal with the characteristics of DNS wildcarding.

+1, I was either way with this before, but now I agree with Jim.

I know this is obvious to many, but wildcarding is not about the client 
issuing a wildcard request.  It is a server-side setup.  So I don't 
think we have any control how a DNS administrator may or may not use 
wildcards to describe his zone.

But that may depend on the syntax.

Currently Jim,  SSP describes a syntax of:

      _policy._domainkeys.<domain>

Based on my testing, I don't think this lends itself to a wildcard 
preparation. Is this correct?

The exploration I did using a DMP (LMAP idea) approach with a sub-domain 
zone cut off, does allow for a wildcard approach:

      [subdomain]._policy._domainkeys.<main-domain>

where main-domain is where the DOMAIN ownership begins.  I am not sure 
how DNS administrators officially label the "main-domain" but the 
problem seems to be that it is "impractical" for the client to determine 
where the domain ownership begins without some additional lookups.

In any case,  not ideal, but without a reliable gTLD/ccTLD detection 
method,  it seems we have no other choice but to use a sub-domain 
traversal approach as currently described in SSP-03.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Jun 2007 21:31:03 -0700

On Jun 12, 2007, at 6:28 PM, Hector Santos wrote:

> Douglas Otis wrote:
>> Jim,
>> Your conclusions seem correct, however they exclude the  
>> possibility of first checking the existence of MX or A records.   
>> Checking the existence of MX or A records is an alternative to  
>> domain transversal of the use of wildcards.  The DKIM policy is  
>> limited and unable to indicate whether a domain is bogus anyway.   
>> This means recipients will be unable to differentiate between  
>> broken signatures and bogus domains.  Checking the existence of MX  
>> or A records ensures bogus domains are avoided.
>> For many years at least, DKIM policy will be present within a  
>> small percentage of domains sending email.  What this means for  
>> recipients, is that most domain transversals will either begin or  
>> end at the TLD without any benefit.  This will also cause SLDs to  
>> experience a high amount of unanswered transactions.  The desire  
>> to use a wildcard or domain transversals is to detect bogus  
>> domains.  Checking the existence of MX or A records provides a  
>> much safer, more effective, and simpler method.  Every valid email- 
>> address domain MUST publish either an MX or A record.  A request  
>> for ANY record at the email-address domain is likely to return the  
>> desired information within a single DNS transaction.
>

Hector,

Thank you for responding.

The desire is to establish a "policy discovery method" that prevents  
bad-actors from side-stepping policy by purporting to be from a bogus  
sub-domain.  Determining whether an email-domain within a field  
defined by RFC2822 is bogus, might utilize essential elements  
required by RFC2821.  These elements (MX or A records) provide  
evidence of the email-domain being valid.  This is _not_ about  
detecting bogus RFC2821 transactions.

> But overall bad people fall thru the 2821 cracks, hence why I  
> thought the purpose of this PROJECT was to invent a 2822 solution?

The goal of DKIM is to curtail message spoofing.  Policy should  
permit stricter acceptance requirements when desired by both the  
transmitter and receiver.

> That is based on over 2 years of daily accumulated logs from  
> various cross section customer sites who participated in our  
> analysis.  Millions of transactions.
>
> satisfies the result you are looking for. Performing SENDER-ID at  
> 2822 creates high payload overhead issues.
>
> But like SENDER-ID, now you are asking we incorporate more MX/A  
> logic at 2822 and the only way to optimize this is to signal this  
> rule when:
>
> logic. Not a bad consideration, being that is will only be  
> considered 16% of the time.
>

Knowing whether an email-domain is bogus eliminates a policy search  
by transversing the domain or expecting transmitters to deploy  
wildcards records.  A check at a valid email-domain will clearly  
indicate whether the transmitting domain has established any policy.

> What if the implementator decides to not do a MX/A check at 2821,  
> but to delay it until 2822 thinking that it would have to do the  
> 2822.FROM and possible 2822.Return-Path MX/A checks?
>
> Because if it does not, you create overhead on systems that may  
> already have some form of MX/A logic.

Excluding email-domains determined as bogus by their missing  
discovery records reduces the overhead associated with DKIM  
handling.  This eliminates bogus email-domains prior to any DKIM  
processing.

> Or do they not count?  And they must MOVE all MX/A logic to 2822?   
> In this case, we create a potential high payload overhead problem  
> again.

DKIM incurs a high overhead per rejected message, as the entire  
message must be acquired.  DKIM is not an anti-spam, but rather an  
anti-spoofing technology.  MX/A logic provides an alternative to  
rather problematic wildcards, or expensive domain transversals.   
Domain transversals will introduce even higher overhead, possibly to  
the point of hindering services of SLDs.

> Finally, how reliable is a ANY query?  And wouldn't this exert more  
> DNS network overhead pressure with larger size than probably  
> necessary responses?

Admittedly, TXT at these locations might tend to reduce success  
rates, but this would only need to work most of time for an ANY query  
to be a preferred method.  Only a single A or MX record needs to be  
returned.  A subsequent query is still able to make specific requests  
when there is a partial reply lacking either A or MX records.

> Basically, I think mixing MX/A 2821 considerations with the 2822  
> Sender Policies considerations creates a big mess to get straight.

The MX/A logic answers two simple questions:

  - Should policy be expected at this location if there is one?
  - Is this email-domain bogus?

What is messy?

> In any case, completing SSP, IMO, should stand on its own and it  
> should not be dependent on MX/A.

The SSP draft should expect domain transversals instead?

> first what percentage is NXDOMAIN.  If it is a low amount, then we  
> have a higher DNS overhead issue.

Of course there will be an even more NXDOMAINs when requesting DKIM  
policy.  Even so, DKIM policy as constrained is unable to indicate  
whether a domain is bogus.  DKIM policy is only able to indicate  
whether a message must be signed.  This constraint necessitates other  
steps be taken to determine whether a message with an apparently  
broken signature should be rejected or accepted.  The MX/A logic can  
deal with this problem, as well as reject outright bogus email- 
addresses without the use of DKIM.  This provides a fairly high  
benefit.  Also when a query does not return NXDOMAIN, there is also a  
good chance this record was found within a local cache.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Jun 2007 11:47:31 +0100

>    - When policy requires DKIM signatures, refuse the message.

That works for the domain that "never sends mail"
                                 "never receives mail"

But what about the domain that receives, but never sends?

In that case you will publish several MX records (with assorted
preferences) as usual. But then you also publish an extra MX record with a
ridiculously low preference (99 say) which points to something
unresolvable (e.g. nomail,invalid).

By convention, that means "sends no mail". So if you are a receiving site
considering whether some message can be discarded, you just ask to see the
MX records for the domain, and see if they include one pointing to
nomail.invalid.

I reckone there would be no need then to depracate A records where |MX was
absent, or anything like that.

-- 
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: Douglas Otis <[email-masked]>
Date: Wed, 13 Jun 2007 07:24:59 -0700

On Jun 13, 2007, at 3:47 AM, Charles Lindsey wrote:

> That works for the domain that "never sends mail" "never receives  
> mail"
>
> preferences) as usual. But then you also publish an extra MX record  
> with a ridiculously low preference (99 say) which points to  
> something unresolvable (e.g. nomail,invalid).

Had DKIM policy permitted such a statement, it could be handled via  
policy.  However, this is a rather odd case for anti-spoofing.  Any  
DKIM policy related protection will require such a "never sending"  
domain to lie.  In this case, the "never sending" domain must  
indicate they "always sign" the email they "never send".

> By convention, that means "sends no mail". So if you are a  
> receiving site considering whether some message can be discarded,  
> you just ask to see the MX records for the domain, and see if they  
> include one pointing to nomail.invalid.

Of course spammers utilize lower preference MTAs, as might legitimate  
senders during network related problems.  Low preference  
"nomail.invalid" MX records is not a good method to signal that a  
domain "only" receives.  A "nomail.invalid" will also hammer roots  
when senders attempt to resolve the bogus hostname.  In the more  
common case where a sub-domain does not receive or send, adding an  
MTA with any preference and bogus hostname is sure to cause these  
records to be processed, much to the detriment of the roots.

> I reckone there would be no need then to deprecate A records where  
> MX was absent, or anything like that.

Adding an MX record where an MX record is appropriate, rather than  
adding MX records where they don't belong seems a far safer  
solution.  Deprecation is in respect to utilizing A records for  
discovery.  The impact of this change may eventually mean messages  
from a domain might be refused without there being an MX record  
within this domain.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 14 Jun 2007 11:33:43 +0100

>> By convention, that means "sends no mail". So if you are a receiving  
>> site considering whether some message can be discarded, you just ask to  
>> see the MX records for the domain, and see if they include one pointing  
>> to nomail.invalid.
>
> "nomail.invalid" MX records is not a good method to signal that a domain  
> "only" receives.  A "nomail.invalid" will also hammer roots when senders  
> attempt to resolve the bogus hostname.  In the more common case where a  
> sub-domain does not receive or send, adding an MTA with any preference  
> and bogus hostname is sure to cause these records to be processed, much  
> to the detriment of the roots.

Actually, publishing a bogus undeliverable address as your lowest-priority  
MX record is one of the standard ways of avoiding spam. Moreover, using an  
address ending in ".invalid" in the From: line is the recommended  
technique for munging addresses in Usenet articles for those who wish to  
avoid their addresses being 'scraped' by spammers (better than to use a  
random domain which might turn out to be real, and that would in any case  
incur DNS overhead in looking it up). A well organized lookup system  
should have '.invalid' hard coded into it as something that never needs to  
be queried, but even if this is not done I have been assured that such  
bogus addresses will rapidly become cached, and so avoid any undue load on  
the root servers. In any case, it will only be spammers who will normally  
be attempting to send mail to addresses not capable of receiving it.

And those querying MX records to see if a 'conventional' address such as  
'nomail.invalid' is present do not then need to try to retrieve its IP  
address.
>
>> I reckone there would be no need then to deprecate A records where MX  
>> was absent, or anything like that.
>
> adding MX records where they don't belong seems a far safer solution.   
> Deprecation is in respect to utilizing A records for discovery.

But, as has been pointed out to you, that "deprecation of A records" is  
just not going to happen. I am just trying to point out an alternative  
that might work instead.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 14 Jun 2007 19:41:16 -0700

On Jun 14, 2007, at 3:33 AM, Charles Lindsey wrote:

> On Wed, 13 Jun 2007 15:24:59 +0100, Douglas Otis <dotis@mail- 
> abuse.org> wrote:
>
>>> you just ask to see the MX records for the domain, and see if  
>>> they include one pointing to nomail.invalid.
>>
>> Of course spammers utilize lower preference MTAs, as might  
>> legitimate senders during network related problems.  Low  
>> preference "nomail.invalid" MX records is not a good method to  
>> signal that a domain "only" receives.  A "nomail.invalid" will  
>> also hammer roots when senders attempt to resolve the bogus  
>> hostname.  In the more common case where a sub-domain does not  
>> receive or send, adding an MTA with any preference and bogus  
>> hostname is sure to cause these records to be processed, much to  
>> the detriment of the roots.
>
> Actually, publishing a bogus undeliverable address as your lowest- 
> priority MX record is one of the standard ways of avoiding spam.  
> Moreover, using an address ending in ".invalid" in the From: line  
> is the recommended technique for munging addresses in Usenet  
> articles for those who wish to avoid their addresses being  
> 'scraped' by spammers (better than to use a random domain which  
> might turn out to be real, and that would in any case incur DNS  
> overhead in looking it up). A well organized lookup system should  
> have '.invalid' hard coded into it as something that never needs to  
> be queried, but even if this is not done I have been assured that  
> such bogus addresses will rapidly become cached, and so avoid any  
> undue load on the root servers. In any case, it will only be  
> spammers who will normally be attempting to send mail to addresses  
> not capable of receiving it.
>
> And those querying MX records to see if a 'conventional' address  
> such as 'nomail.invalid' is present do not then need to try to  
> retrieve its IP address.

Spam is often highly distributed, perhaps to millions of servers.   
When such spam induces DNS resolution of bogus names, negative  
responses might be cached for a few minutes, and in some cases not at  
all.  RFC2308 'suggests' using the SOA minimum field, which is often  
1 day at the root.  There is _no_ assurance negative caching is  
implemented.  To safely thwart spammers without hammering roots,  
point targets within the MX records to 192.0.2.0/24 address space.   
See RFC3330.

In the case of MX records, it is code, not people, that see  
"nomail.invalid".  A well considered scheme will not induce automated  
use of bogus names which might then pound root severs.  Perhaps a TLD  
of "invalid" could be established.  Perhaps IP addresses for  
"invalid" names servers could be assigned the address of  
"192.0.2.2"   After all, who wants to pay for a large amount of bogus  
traffic?  As it is now, critical roots bear the brunt.  Don't assume  
publishing bogus names in DNS records is safe, especially with  
respect the most abused anonymous push protocols there is, SMTP.

>>> I reckone there would be no need then to deprecate A records  
>>> where MX was absent, or anything like that.
>>
>> discovery.
> But, as has been pointed out to you, that "deprecation of A  
> records" is just not going to happen. I am just trying to point out  
> an alternative that might work instead.

This is _not_ about deprecating A records.  It is about deprecating  
their use for discovery.  More to the point, once a few ISPs refuse  
messages from domains lacking MX records, it will not take long  
before requisite MX records are published.  It can happen faster than  
you might imagine. : )

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Jun 2007 14:55:58 +0100

>> And those querying MX records to see if a 'conventional' address such  
>> as 'nomail.invalid' is present do not then need to try to retrieve its  
>> IP address.
>
> Spam is often highly distributed, perhaps to millions of servers.  When  
> such spam induces DNS resolution of bogus names, negative responses  
> might be cached for a few minutes, and in some cases not at all.   
> RFC2308 'suggests' using the SOA minimum field, which is often 1 day at  
> the root.

Yes, the root server I looked at had one day, which means that the  
non-existence of the 'invalid' TLD should be cached for that long.

>  There is _no_ assurance negative caching is implemented.

It seems to be required by RFC2308. I should think it is now implemented  
on most resolvers worldwide.

>  To safely thwart spammers without hammering roots, point targets within  
> the MX records to 192.0.2.0/24 address space.  See RFC3330.

Yes, an MX record pointing to some 'conventional' address in that space  
would serve our purpose, but I think MX records are supposed to point to  
domains rather than IPs.
> use of bogus names which might then pound root severs.  Perhaps a TLD of  
> "invalid" could be established.

It IS established (see RFC 2606), and if you stare at the ICANN website  
for long enough you will find they have agreed never to allocate it. But  
registering it on the root servers with a huge TTL would indeed help.

>  Perhaps IP addresses for "invalid" names servers could be assigned the  
> address of "192.0.2.2"   After all, who wants to pay for a large amount  
> of bogus traffic?  As it is now, critical roots bear the brunt.  Don't  
> assume publishing bogus names in DNS records is safe, especially with  

> their use for discovery.

I don't believe that is goiung to happen either.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Jun 2007 10:46:04 -0700

On Jun 15, 2007, at 6:55 AM, Charles Lindsey wrote:

>> responses might be cached for a few minutes, and in some cases not  
>> at all.  RFC2308 'suggests' using the SOA minimum field, which is  
>> often 1 day at the root.
>

The "invalid" TLD might be cached, not should be cached.  Of course  
might should be a should.

> It seems to be required by RFC2308. I should think it is now  
> implemented on most resolvers worldwide.

Sorry, but no.  There are many problematic implementations where  
negative caching has been disabled to facilitate faster recovery.   
This happens fairly often in "corporate" environments using  
admittedly problematic network handling.

Negative caching is NOT required by RFC2308.  Here is a section that  
makes this clear.
----
2.2.1 - Special Handling of No Data
...
3 - Negative Answers from Authoritative Servers

    Name servers authoritative for a zone MUST include the SOA record of
    the zone in the authority section of the response when reporting an
    NXDOMAIN or indicating that no data of the requested type exists.
    This is required so that the response _may_ be cached.  The TTL  
of this
    record is set from the minimum of the MINIMUM field of the SOA  
record
    and the TTL of the SOA itself, and indicates how long a resolver  
_may_
    cache the negative answer.  The TTL SIG record associated with the
    SOA record should also be trimmed in line with the SOA's TTL.
----

>>  To safely thwart spammers without hammering roots, point targets  
>> within the MX records to 192.0.2.0/24 address space.  See RFC3330.
>
> Yes, an MX record pointing to some 'conventional' address in that  
> space would serve our purpose, but I think MX records are supposed  
> to point to domains rather than IPs.

Yes.  Within _your_ domain of "<example.com>", you could have  
"invalid.<example.com>" as a target in the MX record which then  
points to 192.0.2.2.

>> "nomail.invalid".  A well considered scheme will not induce  
>> automated use of bogus names which might then pound root severs.   
>> Perhaps a TLD of "invalid" could be established.
>
> It IS established (see RFC 2606), and if you stare at the ICANN  
> website for long enough you will find they have agreed never to  
> allocate it. But registering it on the root servers with a huge TTL  
> would indeed help.

These damains are established to prevent conflicts with test code  
that might be inadvertently found in the wild.  Indeed when there is  
a chance a human might see the domain name, "???.invalid" would make  
it clear to the human.  It would not be clear to code that will use  
this domain in an automated fashion.

>>> records" is just not going to happen. I am just trying to point  
>>> out an alternative that might work instead.
>>
>> This is _not_ about deprecating A records.  It is about  
>> deprecating their use for discovery.
>
> I don't believe that is going to happen either.

Do you use MX records to locate your SMTP servers?  What percentage  
do not?

Could MX records be a requirement for email-domain _acceptance_ in  
some cases?

The small percentage of email-domains might then feel obligated to  
publish an MX record.  These MX records will be _valid_ and point to  
_valid_ host names.

The alternative you recommend is that the entire name space be filled  
with bogus wildcard and non-wildcard MX records pointing to bogus  
host names?

You envision massive publishing of bogus MX records pointing to bogus  
host names, rather than publishing a few appropriate MX records  
pointing to valid host names?

What a mess.  One must hope others don't share this view. : (

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Jun 2007 12:01:09 -0700

Rather than developing a positive means to prove that a protocol is  
supported at a particular domain, some advocate use wildcard records  
containing invalid hostnames to signal non-support.

Will the IETF/ICANN then need to establish a TLD of "invalid" to  
support the concept of invalid hostnames used in automated  
scenarios?  For example, invalid hostnames used in an automated  
fashion, such as those within MX records.

Will a wildcard scheme attempting to indicate non-support of protocol  
become utilized in various DDoS attacks?

Much of the overhead related to DNS traffic might exist within the  
size of domain name itself, as this may occupy half the allotted DNS  
packet which must also be repeated within the response.   A wildcard  
scheme provides bad-actors a means to ensure their transaction is  
never answered from cache, by just randomly generating a label.  Even  
negative caching therefore offers no relief from this type of DDoS  
attack.  There is also likely a problem created at the roots,  
especially from domains that do not implement negative caching.  The  
cache itself may also be made ineffective due to sheer volumes of  
bogus wildcard records it now contains.

With MX records, some receiving domains utilize SPF.  SPF treats DNS  
records in a script like fashion and may synthesize _10_ MX record  
transactions for each:

  - recipient (1 to minimum of 100)
  - validated email-domain/address (EHLO, MAILFROM, PRA, n * DKIM  
signing domain?)

SPF macro expands various components of the email-domain/address  
questioned, where each different email-address must invoke a new set  
of transactions.  A spammer is able to utilize a _single_ SPF record  
to induce perhaps millions of third-parties to flood their victim  
domains with non-cached transactions.  This could be done by simply  
employing different local-parts and domains within the email-address  
contained with the spam campaign.  In addition, SMTP logs would not  
trace what is causing the attack either, hidden within an unseen SPF  
record.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Jun 2007 20:38:28 +0200

Stephen Farrell wrote:

> please respond, by Monday, to this with +1/-1's

You were probably not talking about this Monday, but...

>     Issue#1: -1 - exclude use of XPTR from ssp-00

...I still like Phil's general solution (+1).

>     Issue#2: +1 - Define how to use a TXT RR for SSP policies
>                   (with or without something else)

IFF #1 AND #3 end up with -1 I'd favour a new RR (-1) for #2.

>     Issue#3: +1 - Define an upward query based approach to finding
>                   SSP statements

Don't care, both ways are far from optimal.  Folks run into the
known limitations with TXT wildcards if they try to use this for
SSP _and_ SPF _and_ whatever comes next.

Frank