On 5/5/2013 11:58 AM, S Moonesamy wrote:
Hi Mark,
At 15:57 04-05-2013, Mark Andrews wrote:
The publisher can choose to interoperate with everyone by publishing
both.
The client side can choose to interoperate with everyone by looking
for both.
Both side can choose their level of interoperability. There is no
bug.
Thanks for the feedback.
Based on the quoted text I would write the text as:
(i) you must have X and Y where X and Y are identical.
(ii) I ask you for both X and Y (see [1] for example).
Item (i) is a combination of the previous items (a) and (c). Item (ii)
is the last part of previous item (d).
Overall, IMV, this is common sense migration path logic used in many
concepts:
Try X first,
Fallback to Y second;
Where X is the preferred protocol *PATH*. It is implicit that the data
is functionally equivalent. I have used a nomenclature of X/Y to signify
this logic. I thought it was implicit. In fact, for BIS, I posted an
issue [1] suggesting a clarification on its tip of using a "Parallel"
method. Ultimately, and in theory, this complexity would not be
necessary, but it may be the only practical solution if there is slow
resolutions on the existing DNS query barriers.
I guess there is no concern about having dual SPF/TXT calls, either in
series or in parallel, if there are no delays. The way I long time
viewed it, the SPF overhead, high redundancy and waste is based on:
- NXDOMAIN
- NOERROR
- Relaxed SPF policies (No Payoff)
I expected the overhead would be short term as more records as published
and more domains began to switch to -ALL operations. After 10 years,
with a slow growth climb, today, I see a 20% SPF rejection rate at our
support site:
http://www.winserver.com/SpamStats
Our implementation does not perform HELO/EHLO SPF checking by default
since it is historically high incorrect value, and the return path SPF
domain checking is done after the RCPT TO field is validated. This delay
in SPF processing lowers the SPF DNS overhead by 60%.
--
HLS