Jason Bertoch wrote:
<pedestal> It's my opinion that if an administrator misconfigured his SPF record, or a number of other things on their side, it is their fault that mail cannot be delivered. In the case of SPF_FAIL, they have explicitly told us they don't want mail to come from a server not listed in their record and I believe we should follow their directive. In fact, isn't that the point of SPF; to help us reject forged messages coming from unauthorized servers? Why bother even dealing with SPF if we're still going to let people get away with poor administration? That's partly how we got here in the first place... </pedestal>
I don't disagree with this, though I can give you an example of what can happen. I used to host the DNS for my domain with speakeasy.net who I had in general been quite happy with. Then they decided they needed to implement SPF and they were going to do it RIGHT NOW. They didn't create an addition to their otherwise wonder DNS admin webapp (I guess they were in a panic and didn't have the time), so instead they generated SPF records based on the MX records for your domain. In my case I also used my employers mail server to send email (and therefore needed to add it to my SPF record), but it was certainly NOT OK to add them as a MX record for my domain, so I suddenly found my emails being bounced from some mailing lists (this might have been one of them). I tried to explain to Speakeasy.net that they were generating incorrect SPF records, but they thought they were "close enough" and tried to talk me into some unacceptable workarounds. I don't know if they ever changed this, but I was no longer using them for DNS hosting in a matter of days. Since Speakeasy really is pretty good in a lot of ways, I can only imagine what goofy things some other ISPs have come up with. Steve
