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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html