On Tue 01/May/2012 13:20:13 +0200 ned+ietf-smtp wrote:
Even if it's a test system or a home system, the way you deploy
that protocol reveals your personal preferences and attitudes
toward it.
I'm sorry, but that's just not true. Like most of the other people
on this list, I'm a developer, and as such I deploy things for
reasons having nothing whatsoever to do with my personal
preferences for how an email server should be run. Additionally, my
experience is routinely based on feedback I get from customers
*when they are having problems*. It is a rare customer indeed that
calls up and says, "We deployed such and such and it is working
fine".
Oh well, yes, attitudes related to your customers' needs may obfuscate
your personal preferences, for some time. My questions assume that
respondents hadn't modified their settings for a good deal of time,
which might be false in some cases. Whether you're happy or
dissatisfied, free or compelled, stable or ever-changing, you answers
would have reflected some kind of tendency.
I may admit it's not very accurate, but the point, IMHO, is to grasp
which is true among "(almost) nobody does that", "there's a small but
non-negligible cluster of operators who'd do that", and "that's being
done by a considerable amount of people".
But why settle for an extremely small and biased set of responses when a
different set of questions to the same audience can tap into much more useful
and relevant information?
Again, you're talking to people who implement and deploy email software here.
So why not ask:
(1) Whether or not their products support SPF, and why.
(2) If they implemented SPF, what the customer response has been.
(3) What interoperability problems have shown up.
I note that this is close to the set of questions we ask when trying to assess
interoperability. There are good reasons for having setttled on this approach.
Now, if I had to answer these myself, I'd say:
(1) We have built in support for both SPF and SRS in our product. We
implemented both in anticpation of customer requests, not because of them.
(2) We have observed relatively little interest in using our SPF support,
considerably more in SRS. In and of itself this would seem to indicate
that SPF is seen less as a useful thing and more as problem to work around.
There are, however, additional factors in play that would tend not to
support any such conclusion. One is that we typically don't hear from
people who deploy something without incident, and SPF is easy to set up
whereas SRS is a bit tricky. Another is that there was a substantial bug
in our SRS implementation (my fault), whereas the only bug I recall in our
SPF implementation was one having to with IPv6, which due to the level of
deployment of IPv6 for mail service had little if any effect.
And probably most important of all, it's entirely possible that sites
are relying on SPF support that's built into whatever AS/AV software they
are using, making our support of it irrelevant. OTOH, it's also possible
sites are content with the non-SPF filtering these packages provide and
don't care about SPF at all. There's just no way for us to tell.
(3) We have not observed any interoperability problems with either SPF or SRS,
unless you count the problems SPF causes that SRS solves.
I've included SRS here because I think mitigation strategies for the issues
SPF causes are highly relevant to the question of whether or not SPF should
be placed on the standards track.
IMHO, omitting to take the survey, you --in general, non responders--
just express lack of interest in SPF. Am I wrong?
Yes, you are completely wrong.
Do you mean on your case in particular or on why, in general, few
people respond to that survey?
You're wrong in concluding that a failure to respond to your survey indicates a
lack of interest in SPF. And since several people agreed with my original
posting on this, I don't think I'm alone in this.
If you want to ask questions of an audience of implementors, I
suggest that you ask them what kind of support for SPF do they
provide in their products and perhaps what they know (or don't
know) about actual customer usage of those features.
Agreed, if I had been more clever I'd have done that. But then,
those who would have taken the burden to answer such more lengthy
questions are probably participating in SPFBIS already. My
questions are easier to ask as well as to answer.
And that's 0 for 3. I am comprehensively well versed in what
features our product has, including the parts of the product I
didn't write, because I am constantly answering complicated
questions about how to accomplish various things using our
product's capabilities.
Similarly, I am constantly receiving and assessing information
from customers about problems they are having as well as what
additional capabilities they want. This is how I decide what
features to add, remove, or enhance.
Since I think about this stuff all the time, it is trivial for me
to regurgitate some subset of it when asked.
I believe that's true for you personally, as your helpfulness can be
readily evinced by your patience in going along with my ruminations on
this subject --thank you for that, btw. However, I doubt anyone at,
say, Microsoft would ever consider such questions, let alone reply to
them.
That may or may not be true, but there are plenty of email vendors besides
Microsoft.
As I said, I'm not clever enough to do that. I'd need real
assistance to carry it out. I'm open to proposals...
I thought I made a fairly specific proposal in my original response, but
I've firmed it up here. See above.
Ned