On Sat, Apr 16, 2011 at 8:06 AM, <dar...@chaosreigns.com> wrote: > But it can only add headers beginning with X-Spam-. So you might be able > to add a header with that, and then use procmail or something to add your > Received-SPF header based on a X-Spam-Received-SPF header. But you would > probably still need to write a SA plugin to do it. > > The better option is probably to add the Received-SPF header at your MTA. > With postfix, I use https://launchpad.net/postfix-policyd-spf-perl/
I use postfix too. Pretty simple setup right now, but I'm looking to add better checking. I read about that postfix-policyd-spf-perl. And it looks like there's a python version too. I just learned that you can use postfix procyfilterss and milters together, and that the proxyfilter runs before the milters. So I'm thinking about thiis. Run SA in a prequeue proxy filter, and set SPF checking priority very negative to do an early check for SPF Fails. If there is no Fail, then run the rest of SA tests, then handoff to the policyd-spf to RE-do the SPF checks, like you said using the local DNS cache for not too much extra overhead, and get the Received-SPF header added. If there IS a FAIL in that early check, then use a Shortcircuit rule to stop SA tests, and just handoff to the policyd-spf to RE-do the SPF checks and apply any REJECT policy right there. I think that should work. Does it look like it to you? SA can check for and use Received-SPF headers that already exist. So it's already aware of them and how they're constructed. Seems silly not to be able to add the header too right in Spamassassin and have to use a 2nd program to re-do stuff that's already been done. I've never written a plugin like that. I'll see if I can figure out how. I would've thought somebody, somewhere had already done this, by now. --Bob
