On Wed, 30 Mar 2005 16:46:22 -0500, Kris Deugau wrote >I think you meant "99.9% of those customers WILL fail SPF as they > are sending from an IP outside [their POP provider's] range but using > [their POP provider's] domain name".
Yes, that is exactly how I meant you. in the general sense. > 1) Misconfigured SPF record that doesn't include everything it should. No, you should never include DHCP roaming, shared IPs in your SPF record for your road warriors. This address space is not "yours" and is shared by many others, thus SPF is configured correctly. > 2) SPF shouldn't even be used. This is most likely; if a company > explicitly does NOT know where their customers may be sending email > from, they can't usefully enforce any kind of sender policy! I disagree, I know exactly where 90% of my customers are sending from.. its again.. only the road warriors. I should mention though.. most of my competitors in this area do not even have their own pop sites anymore.. effectively making ALL of their customer base fall under my "road warrior" category. Not to mention even my road warriors send their outbound mail through my server (tls auth first to enable relay among other things) so the SPF failure will ONLY be occuring on my server(s).. thus it is manageable. Frankly I cannot think of a single legitimate reason for any ISP/WISP NOT to publish SPF. > 3) No provision for authenticated SMTP through their own servers, which > they can and do list properly in their SPF record. SPF and sender auth are two different things and I believe I have mentioned this twice already. We do both, if you authenticate I do not care about your connections SPF as you are already authenticated using one of my customers credentials. I see nothing to gain even examining SPF records for my own customers in the ISP sense, its just wasted cpu cycles to do so IMHO. > Personally, I can't see using anything other than a soft-fail for SPF > for ISP domains (at least for a few years...); customers *will* do > strange things like, oh, say, take the laptop on [vacation/business > trip] and try to send through the hotel's provided (and enforced) > SMTP smarthost. Softfail simply means the ISP does not have a SPF record published (most likely) or you could not find one for them or some other temp fail or guess type situation... or they have not tested their SPF implementation and have the softfail all in their record.... which somewhat defeats the whole purpose of even having a SPF record... /sigh. As for the Smarthost proxy issue... well thats a bugger that will cause worse issues than the one I mentioned above, as it grabs the entire smtp connection transparently behind the scenes... thus all other servers world wide including my customers own mail server will see SPF fails for this customer and I would not have the authentication/envelope rewrite to fall back on to correct this. Guess that is another thing to keep in mind! :-) PS, all yous and yours are in the general sense, It is nothing personal, I am a lazy typist! ;-) Jim -- EsisNet.com Webmail Client _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
