> > 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! :)
--
Kai.Risku@??? GSM +358-40-767 8282
Oy Arrak Software Ab http://www.arrak.fi
