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.
My desire at 2822 is detect bogus 2822 policies.
My desire at 2821 is detect bogus 2821 transactions.
TWO DIFFERENT THINGS!
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.
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?
The goal of DKIM is to curtail message spoofing. Policy should
permit stricter acceptance requirements when desired by both the
transmitter and receiver.
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?
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?
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.
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?
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.
The SSP draft should expect domain transversals instead?
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.
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
