I wish to clarify my response David using a real-life (customer) example.
----- Original Message -----
From: "David Woodhouse" <dwmw2(_at_)infradead(_dot_)org>
The network in which I participate is known as "the Internet". It is not
'correctly' setup for outbound mail, by the definition you're using.
My point is that you shouldn't use SPF if you don't have your network of
outbound mail machines under its umbrella.
Don't you agree?
In our experience, there are two key issues to contend with SPF domains:
1) Relaxed Provisions,
2) Heterogeneous Systems
Relaxed Provisions:
As I pointed out in one of my messages, I personally feel part of the
problem with the SPF forwarding issue is the SPF web site marketing and
promotion for Ntwork Amins to begin getting ready for SPF by first
publishing SPF domains. This is recommended even if the server software is
not SPF ready themselves.
This has produced much of the forwarding issues that came about. The
proposed recommendation, which in my view is a terrible recommendation, is
to use a relaxed SPF provision called SOFTFAIL and NEUTRAL results. I say
it is terrible because in my view, SPF attempts to to address a security
problem yet introducing new ones.
In addition, in our R&D, this has greatly increased the complexity of the
software logic. Although, my research has shown that relaxed provisions can
be used in analyzing mix policies in some cases, it has clearly shown that
the permutations of trust states grows to levels that simple make the whole
idea of SOFTFAIL and NEUTRAL unacceptable to deal with. I can show proof of
this if any one is interested.
Heterogeneous systems:
In short, this means a MIX of compliant and non-compliant "Spoof Protection"
systems within a company's network.
As we quickly discovered when our system was official released to our
customer base, some of the high end corporate systems who have invested
thousands if not millions in corporate AVS frameworks, wanted to see how
the new Wildcat! SMTP server SMTP level "Spoof Protector" can fit into their
network.
In short, to use but one example, we have a customer with the "Barracuda"
??? AVS system. Since we do not offer AVS solution directly (only
integrated via a sysop definable programmable DATA hook) they wanted to
continue using its AVS stuff, so they setup two MX:
MX1 mail.Wildcat.Server
MX2 mail.Barracuda.Server
And they setup Barracuda.Server to route mail to Wildcat.Server, thus the
forwarding problem begins.
When mail hit Wildcat.Server, there are no issues.
However, when hit mail hit Barracuda.Server there were issues.
In essence, Barracuda is not SPF ready. It does its AVS checking and then
routes the mail to Wildcat which performs the SPF check and thus fails for
published SPF domains - the classic forwarding problem.
So there are two issues here:
The first one is the most likely realistic migration path many companies
will take. An exploration of a solution within their current non-compliant
framework. This is a factor all vendors must anticipate.
The second, is the realization is that its a "all or nothing" solution.
As I explained to the customer, they solutions were:
1) Wait until Barracuda added SPF and/or SUBMITTER support
2) Make MX2 a Wildcat! Server host with Barracuda as the AVS backend
3) If possible, program barracuda with sender-rewriting methods,
4) White list the Barracuda host.
However, with the last option by white listing barracuda, the SPOOF
protection was bypassed which defeated the purpose.
Finally, I should note that in our experience this far, this was a very low
support issue.
Most Network admins are sharp enough to understand whats going on and will
do what is takes to make it work or realize they are not ready to use this.
Most similar incidents were with integrating enterprise Norton or McAfee
systems as proxies. But this Barracuda incident was a good classic example
of a heterogeneous network where someone invested in an expensive home
security system with cameras, motion detections, guard dogs, etc, yet, they
leave the front door key under the poach potted plant. To implement
non-standard advanced SMTP stuff, you need to address and implement all
"considerations" across the board.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office