Re: A note about draft-ietf-spfbis-4408bis

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]