Nor is it against the RFC. But the point here is that somebody
published their policy records with certain expectations that they
would be used according to a standard technical specs and they are
not, so the publisher has the right to demand that they be used
properly. . .
Under that assumption, it's no less incumbent on us -- "us," even
under this most aggressive concept of enforcement, still being
individual postmasters using using some boilerplate text and with
management approval, not any "council rep" -- to demand that those who
have MTAs capable of interpreting SPF, yet refuse to reject on SPF
FAIL, comply immediately with our "expectations of how [policy
records] would be used."
I actually had a debate with an admin on another list about precisely
this situation. This guy was claiming that not only would he not be
weighting PASSes and UNKNOWNs, but that the well-worn forwarding and
authentication debates made it impossible for him to reject, or even
weight, FAILs. Nonsense, I shot back: if a policy creator has decided
on implementing a sender policy that FAILs on a given message,
accepting that message is in open defiance of the entity controlling
the domain--and you must discard any gut instinct that the policy
creator was ignorant.
But while I believe that debating with an admin with whom my clients
don't do any business was reasonable, I would never be caught sending
out any "warning" messages from a client site; I know from experience
how often such warnings lead to your own reprimands in the corner
office. So I'm not jockeying for _either_ kind of enforcement, since
it really won't be necessary after people try using SPF as PRA for a
while and deal with their users' rage at rampant FPs. What admin in
her/his right mind would decide that grinding away on a whitelist is a
better use of time than just retreating to a PRA-as-PRA, SPF-as-SPF
setup?
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: sandy(_at_)cypressintegrated(_dot_)com
------------------------------------