James Ebright wrote: > SPF fails on ALOT of ISPs that use national pop accounts for > customers outside their own popsites (QUEST, GlobalPOPs, > Superheronetworks, etc)... 99.9% of those customers WILL fail SPF as > they are sending from an IP outside your range but using your domain > name (and by god I hope you have not added those IP blocks to your > relay file....)
I'm not entirely certain what sort of "you" you might be referring to here. 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". Which, depending on said provider's SPF record, may be entirely legit anc correct, if annoying as hell to the ISP customer whose email just got rejected because they're sending email while on the road. In which case those companies have one of three configuration problems: 1) Misconfigured SPF record that doesn't include everything it should. 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! 3) No provision for authenticated SMTP through their own servers, which they can and do list properly in their SPF record. 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. -kgd -- Get your mouse off of there! You don't know where that email has been! _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang