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

[Hector Santos]

Douglas Otis wrote:
> 
> On Jun 11, 2007, at 10:07 PM, Jim Fenton wrote:
> 
>>> (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
>>>                  statements
>>
>> +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,
> 
> 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.

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
http://www.santronics.com
http://santronics.blogspot.com