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