On Thu, 2005-02-10 at 14:26 -0500, Stuart D. Gathman wrote:
I think the original poster meant to imply that if we just wait long enough,
admins around the world will do what you just described, and make
both their SPF records and their email configs more accurate. He wasn't
expecting the bits to spontaneously undergo beneficial mutations,
but rather that intelligent agents would bring about needed changes.
Yes, I would like to think so. My point, admittedly in a somewhat harsh
and 'round-about way, was that if someone is going to post an SPF
record, they should make sure it accurately reflects their setup. Part
of the problem SPF has had since day one is the perception that the
party checking and enforcing SPF records is the one at fault when a
reject occurs -- this is incorrect, even if one could argue that it is
different than how things were done in the past. If a reject occurs,
baring issues with the implementation of the various SPF MTA plugins, it
is not something that the party who is checking needs to fix, but rather
something that the sending/forwarding party/parties need to resolve.
Not that the SPF-enforcing receiver can't help lessen the burden by
using local whitelisting or trusted-forwarder.org, but these should be
considered non-permanent work-around stop-gap measures rather than a
valid fix for publishing an SPF record that doesn't accurately reflect
your configuration.
--
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>