[Mimedefang] Integrating SPF...

[James Ebright]

On Thu, 31 Mar 2005 02:02:24 GMT, Mark wrote

> You are confusing a few things, I'm afraid. As per,
> 
> http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt
> 
> "softfail" holds the middle between a "fail" and "neutral". 
> "softfail" is typically used to indicate a transitional phase; it 
> means something like: "I am done configuring; I think I got it all 
> set up correctly. The IP you just checked is in all likelihood not 
> authorized; but, please take the 'fail' with a grain of salt, as I 
> may not have published a good enough SPF record yet to cover all IP 
> relevant sender IP space."
> 
> The case where "the ISP does not have an SPF record published" is 
> "none", not "softfail". And "some other temp fail or guess type 
> situation" is not covered by "softfail" either, but by "TempError 
> (section 2.5.6). And if you choose to REJECT based on TempError, a 
> 451 reply code is warrented
> (4.4.3 extended).

I may have the no record published part confused (I admit it has been a little
while since I read through all of this), but I am not quoting the standard
either, I am quoting results I have found, I have been logging SPF records
since the perl module was avaiable, e.g. I am logging the returns from the
module and now compare them to SA now that SA has SPF checks embedded, this is
just what I noticed SA is doing with them: SPF_SOFTFAIL and speculated that
many ISPs are just lazy in this regard or do not really know what they have
out there and are not giving out a "FAIL" return in most every case and are
abusing the softfail section. In other words... softfail should not be a
permanent situation, but in many cases I have seen, the response has remained
a softfail return for over a year..... go figure.

Also do not forget, if you do not rewrite your envelope for "road warrior"
type consumers, whether they auth or not, it will fail SPF (or softfail <grin>
) for mail sent to another domain hosted elsewhere that also checks your SPF
record. It will fail locally too but I would hope you do not care about SPF
checks for your local consumers after they auth.

 
> The whole smarthost issue does not exist. :) Seriously. Any ISP 
> worth its money should open port 587, and allow (SMTP AUTH only) 
> submissions on it. Hotels and such blocking/smarthosting port 587, 
> to my knowledge, never happens. And would be rather silly too, as 
> submissions to port 587 are authenticated-only.

Perhaps you misunderstand where the smarthost would come into play here, or
perhaps you overestimate the hospice industry? The smarthost in question is
not the ISPs but the one located behind the NAT at hotel XYZ. Of course any
ISP worth a damn has port 25 blocked and only allows SMTP traffic out from its
space via port 587 auth or through their own mail severs (well we do have
exceptions for static IP business accounts, but we also SWIP their assigned IP
space too.) 

Regardless you may be right, this may not be an issue, this was speculation as
well, I thought I prefaced it that way, but, I would bet money it is in fact
an issue.. it all boils down to this.. how competent the consultant was when
he setup and configured the proxy/nat/firewall.

Its not the incompetent ones that will cause a problem here, they wont have
anything blocked.... its the marginally competent ones that really think they
know what they are doing that can wreak havok.... we call them "experts" here.

Jim

--
EsisNet.com Webmail Client