> > While trying to the p0f passive OS fingerprinting integration to work > > in amavisd-new 2.4.1, I realized it depended on the Postfix XFORWARD > > feature (see http://www.postfix.org/XFORWARD_README.html). > > XFORWARD NAME=spike.porcupine.org ADDR=168.100.189.2 > PROTO=ESMTP > 250 Ok > XFORWARD HELO=spike.porcupine.org > 250 Ok > > How strange. Normally this information would just be put into a > Received: header.
Yes, the same information is indeed available in a Received-header, but it felt more complicated to hack amavisd to dig it out of the headers, because it tries to use the information at such an early stage that the headers haven't been parsed yet. > Reading the HOWTO, where it speaks about "Internet->MTA1->filter->MTA2 > style content filter applications", it sounds like this is just a hack > to work around the kind of problem we had with older versions of Exim -- > that a message would need to pass through Exim _twice_, because the > first would pass it to an external filter, which then passed it back > into Exim for actual delivery. > > That problem is fixed in Exim -- I don't really see much need for > anything like XFORWARD. > > What exactly does amavisd use this for? It sounds like there should be a > better answer. Well, it is actually the "Internet->MTA1->filter->MTA2" scenario that I am using, because in a more high-volume environment I think it is better for Exim to receive the mails (queue them) and then deliver them to the external filter (amavisd), which gives them back to Exim again for actual delivery. I am not quite sure what your remark "That problem is fixed in Exim" actually means. Are you talking about sa-exim? I have been running amavisd for such a long time already, that I probably am just unwilling to make monumental changes in the overall architecture I am used to work with. :) When amavisd get the client address via the XFORWARD extension, it can select an appropriate policy bank based on the client address (e.g. use different settings for outgoing emails than incoming, see http://www.ijs.si/software/amavisd/amavisd-new-docs.html#pbanks), and it can collaborate with p0f to identify the client OS and do stuff with that (mostly spam scoring, but also suppress bounces if needed). Actually the approach mentioned by Johannes, to put p0f information in mail headers would have been fine enough to me, but I went with the easiest solution and just gave amavisd the information in a format it could immediately use. The end result is that I want to give spam scores based on client OS, and the technical details are not that terrible important. If someone would have published a small tool to generate the extra headers Johannes showed an example of, I would have grabbed that and not disturbed you with this seemingly controversial patch! :) -- [EMAIL PROTECTED] GSM +358-40-767 8282 Oy Arrak Software Ab http://www.arrak.fi -- ## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
