I'm inclined to say no, the primary reason being:

scotiabank.com.         600     IN      TXT     "v=spf1 ip4:205.210.222.131
ip4:205.210.222.132 ip4:205.210.223.9 ip4:205.210.223.10 ~all"

What happens when I either can't resolve my bank's SPF record, or they stop
publishing it?  Users still get the mail whitelisted, even phish forging the
domain.  IMO that's worse than any of the situations above.

whitelist_from_spf is meant to be a reliable means of whitelisting a sender. 
Falling back to whitelist_from (which is best never used) does nothing for the
reliabilty of whitelist_from_spf.

(In reply to comment #1)
> I'm inclined to say no, the primary reason being
[...]

Yeah, I'm -1 on this.  Falling back bypasses the whole purpose of using this in the first place.  By 
definition, this rule should only ever hit if there's an SPF record.

I don't want to miss mail from paypal because they stop publishing spf records
and their mail otherwise looks like spam!

whitelist_from should mean that mail is blocked ONLY IF the sender publishes spf
records and the delivering relay is not listed there.

Any other alternative forces the user either to risk missing mail when the
sender stops publishing spf records or to accept mail that is obviously phish. 

"Any other alternative forces the user either to risk missing mail when the
sender stops publishing spf records or to accept mail that is obviously phish."

Your alternative also results in phish being whitelisted.

If you're having major problems with your senders dropping SPF support, I
suggest you use whitelist_from_rcvd instead.

> Your alternative also results in phish being whitelisted.

If the sender publishes an SPF record and the derlivering relay is not listed
then the mail is blocked and the phish does not get through.  Phish only gets
through if the sending domain does NOT publish spf records.  As I said before,
my reason for whitelisting is that I would rather risk getting phish from that
address than risk missing mail from that address.  

> If you're having major problems with your senders dropping SPF support, I
> suggest you use whitelist_from_rcvd instead.

I don't want to have to check whether my new bank has spf records in order to
decide on which whitelist to put them.  I want to whitelist them and have spf
just work.

also -1.   whitelist_from is trivially forgeable; whitelist_from_spf is
rock-solid.  Major difference in trustworthiness levels.

(In reply to comment #6)
> also -1.   whitelist_from is trivially forgeable; whitelist_from_spf is
> rock-solid.  Major difference in trustworthiness levels.

Ok.  Then the change should be in whitelist_from rather than in
whitelist_from_spf.  In particular:

  whitelist_from should not result in delivery of provably forged mails.

If the alleged sender publishes spf records and the delivering relay is not
listed on them, the mail should not be delivered even if the from address is
whitelisted. The person using whitelist_from obviously was not intending to
receive forgeries.

This meta rule will achieve what you want:

meta     WL_BUT_SPF_FAILED      (USER_IN_WHITELIST && SPF_FAIL)
describe WL_BUT_SPF_FAILED      Whitelisted address failed SPF check
score    WL_BUT_SPF_FAILED      100

meta     WL_BUT_SPF_FAILED      (USER_IN_WHITELIST && SPF_FAIL)

fwiw, this is an atrocious idea ;)   Sadly, SPF, Domain Keys, and DKIM all have
a habit of producing failures in various common usage scenarios, so an SPF_FAIL
is not a reliable sign of anything.

Justin, I think the meta rule would work ok because it make the SPF_FAIL be
worth +100 only when there is a USER_IN_WHITELIST that provides -100. So it it
not saying "force scoring as spam whenever SPF_FAIL", which as you point out
would be subject to false positives. It is saying "force scoring as ham whenever
USER_IN_WHITELIST unless there is SPF_FAIL". That is vulnerable to phishing when
there is no SPF record, but is no worse than plain USER_IN_WHITELIST, and is
what Alex says that he wants.

The semantics of WHITELIST_FROM_SPF is "force scoring as ham whenever
USER_IN_WHITELIST and spf success". Alex wants it to be "force scoring as ham
whenever USER_IN_WHITELIST unless there is SPF_FAIL". Comment #8 shows how Alex
can use a meta rule to get what he wants, even if we do not change what
WHITELIST_FROM_SPF does.

I'm closing this once again as INVALID, for that reason. Alex, please get the
hint and don't reopen it. This rule is working the way we want it to and you
have been given a workaround to configure SpamAssassin to work the way you want
it to. 

If I understand things properly, SPF_FAIL only fires when:
  
  (1)the from domain publishes SPF records
  AND
  (2)the delivering relay is not listed in them.

Is that true?  If so, why would you ever classify such a message as ham. 
Shouldn't obviously forged mail always be classified as spam (regardless of
ostensible whitelist status)?

There are two problems with simply treating SPF_FAIL as an infallible spam
indicator (and perhaps rejecting the mail at the MTA without even involving
SpamAssassin?):

1. SPF_FAIL means that the mail does not match what the administrator of the
domain specified in the DNS record. Does that mean that the mail is spam, or
that it is a forgery for some other reason, or that the administrator of the DNS
record made a mistake, that the sender misconfigured their mail client, or that
there is a rarely used way for the sender to send mail that the DNS
administrator didn't take into account? You can block mail based on SPF_FAIL but
is that always correct?

2. SPF is not perfect. See "SPF: Ready for Prime Time?"
http://infocenter.guardiandigital.com/documentation/spf.html for example,
especially item 3.1 there on problems with mail forwarding.

whitelist_from_spf seems like a convenient way of whitelisting people that you
know have set up SPF records properly when you aren't sure what sending domain
mailservers they are going to use, and you expect them to update their SPF
recirds to reflect a change in use of outgoing servers faster than you will
notice them having changed outgoing servers. Personally, I use
whitelist_from_rcvd for everyone on my whitelist, which does mean that I have to
do the work of determining what mail servers I expect them to be sending from.
But I'm not depending on them setting up SPF records correctly.