- SPF checking libraries will no longer be returning a nice, simple,
multiple-choice response. They'll be returning a probability. This
changes and complicates the interface with other programs.
You can map the probabilities into multiple-choice.
- Currently, the way the MTA is supposed to react to each of the
possible SPF returns is pretty cut and dried. When you throw in
probabilities, it becomes much hazier. At what point do I bounce the
mail? 95%? 90%? 50%? Everyone will make their own choices, and we no
longer really have a standardized, predictable response. The whole
thing becomes much more non-deterministic. Different sites will be
treating the same SPF record completely differently.
If the mapping from probabilities to multiple-choice is defined, then
consistency is maintained and in fact more so. Because now those
multiple-choices have more well-defined meaning.
- This would be enough of a change to the syntax to require a new
version string and new versions of all the libraries. Is it worth it?
That is not my call obviously. I think getting data from Earthlink about how
many of it's customers are using SMTP auth is important input to anti-spam.
That is what I visualized it being used for. Or for me to say that I use
non-approved relay of accuspam.com, only 0.1% of the time, so in that rare case
I do, then I am not absolutely deleted but simultaneously forgery of me is
heavily tilted towards spam. How would you measure data on accuspam.com or
coolpage.com if you never seen it before? Forgery tends to be a very sparse
phenomenon.