Michael, > I tried. That was my first suggestion. That would fix graylisting > (which I don't do), fix SPF an SPF HELO, and SENDER ID, blacklisting, > tarpitting, etc.
SPF, sid, blacklisting etc. work just fine on an internal host as long as the proxy is preserving the information about the client connection in a Received header field, and (trusted/internal/msa)_networks is configured correctly. > MIGHT fix p0f, but don't know. The p0f itself MUST see the original raw TCP session in order to be able to analyze it. This means that p0f needs to be on the first-contact machine where TCP session is terminated (e.g. on a mail proxy). As a clumsy workaround, the mail proxy could capture a tcpdump of the start of a session (first few packets) and pass it to a remote p0f for analysis, but this is even more cumbersome. Or perhaps a L2 port mirroring could be used as another clumsy workaround. As long as the p0f daemon itself can be located on a mail proxy host, the actual mail content filtering (e.g. MTA+amavisd+SpamAssassin) may be running on a different host, it just needs to be able to obtain information from the p0f daemon from the external host. Either through a p0f-analyzer.pl running along with p0f on an external host (this is simplest), or perhaps by feeding the streaming output of 'p0f -l' to the internal host. Mark
