Adding DKIM and DomainKeys would also be a big plus for protecting good e-mail.

Put all three under a tool called "Sender Verification" and treat them like the Origin of Spam tool where they are checked in a user selected order and only checked until one hits and then the rest could be skipped.

I'm not sure I understand this requirement. As I understand it, SPF is an authentication protocol between two mail servers. MailWasher is not a server, it is an email client. By the time MailWasher sees a POP3 or IMAP email message, it has already gone through authentication from the sending server to the receiving server.

I just did some searching, and couldn't find any references to implementing SPF in an email client. So how would this be implemented in MailWasher?

It's not as easy in a client - it has to interpret received headers and avoid picking headers that are internal to the sender or the receiver. Maybe if NONE of the forwarding servers in the received headers match the sender's policy the message could be considered more suspicious.

Look at the SPF extension for Thunderbird for an example. While SPF can be done by a receiving server it is often not done. There is no reason why it can not be done by a client since what is being checked is simply that the address in question is authorized to send mail for that domain.

There is a lot of discussion on forwarding servers and SPF, plenty for a workable solution to be arrived at and coded. I haven't been following it so I can't say if all the possible problems have been worked out or not but last time I looked there was progress being made. With the way the spam tools work you'd want to avoid false positives and negatives but tossing an unknown status would not be a provblem for any questionable messages.

What's being checked is whether the IP address of the server that just transferred the message to the server doing the checking is authorized to relay for the domain that the message is "from". For a client to check SPF, it has to pick a point in the received headers where it thinks the message is being passed from an originating server to a receiving server, then check the SPF policy to see if that IP is authorized. Since Received headers can be spoofed, and the path a message takes to get to the user's home server can be convoluted once it passes the company periphery (i.e. it may get relayed through multiple internal servers for various purposes), the client may need some sophisticated configuration in order to be able to properly emulate SPF checking as it should be done by the server that receives the message from outside the periphery. Even my private email is "fronted" by an external service contracted by my ISP - so my home server can't check SPF - it has to be done by the 3rd-party virus-filtering server (could be any one of dozens of different boxes). My client add-on has never yet managed to figure it out correctly - a real frustration. Not that it's impossible, but it is a significant challenge.

Bill, Take a look at the Thunderbird extension, it does a decent job and has some nice logic to deal with many messages. Sure it is better done at the server but if your server doesn't do it you are left doing it locally.

https://addons.mozilla.org/en-US/thunderbird/addon/345

If MW could run multiple filters you could do a set to identify the X-Header lines set by your server from its SPF checks which would be the ideal way to deal with this.