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 _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang