Barry Leiba wrote: >> Then it needs explicit clarification in implementation guides. I think that >> what the RFCs say is good. It's enough to give real benefit to recipients, >> whereas the misinterpretation will make ADSP practically unusable (as if >> only "discardable" existed). > > [as chair] > You're welcome to suggest specific text for the "deployment" document. > It still has to go into IETF last call, so changes are still open. > > [as participant] > It's still true that no matter how much we say how we want it to work, > deployments will do what seems to them to maximize the blocking of > spam. Some will prefer to block spam even at the expense of > significant false positives. We'll just have to see how it works out, > but we can take a cue from SPF, where there was a LOT of deletion > based on SPF failures, even when the SPF records said softfail or > neutral, approximately the same as ADSP's "all".
As among one of the early implementators of SPF, I was never aware that SOFTFAIL and NEUTRAL was creating rejections, or at levels that was reported as a problem. However, statements to this were seen written by those who never liked SPF. It just wasn't true. All you needed to do is look at the software implementations to show that logic did not back that up. Instead, I was one of the first to point out that relaxed provisions such as SOFTFAIL did do anyone a favor and NEUTRAL was a waste of people's time. I advocated people should avoid using SOFTFAIL and I believe over time, people began to see this as well. As I and other stated many times, ALL would become the SOFTFAIL for DKIM and we will mostly see nearly the same adoption pattern: - people start with NEUTRAL (DKIM=UNKNOWN) - people begin to use DISCARD for some high-value domains - people being to use ALL for other less valued domains - people see abuse with ALL - people begin to switch some to DISCARD In any case, I don't see how any of this relates to establishing a persistent protocol methodology. ADSP as written is pretty clear: DISCARDABLE (HARDFAIL) has explicit mail handling instructions. ALL (SOFTFAIL) does not. How people do the SOFTFAIL should be entirely up to implementations and local policy. This is what we have in our SPF operator configuration file (default settings): ; SPF can return low trust results. A pass means the sender has ; a valid SPF record and is accepted. Softfail and Neutral means ; no match is found but rejection is not automatic. Setting a ; true accept can provide a loop for potential spoofers who have ; SPF records and think they will allow them in. The options ; below allow you to control this. Accept-SPF-Pass True ; if false, continue testing Accept-SPF-SoftFail FALSE ; if false, continue testing Accept-SPF-Neutral FALSE ; if false, continue testing I don't see any reason DKIM=ALL will not evolve to the same sort of learning we had with SPF. --- _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
