On Sat, May 9, 2009 at 3:56 AM, Robson Caetano <inet1...@myself.com> wrote: > The problem is that I do not have access to the > real MTA, because it is managed by another group.
Umm, why isn't that group being asked to do this sort of logging? I know, it's a crazy thought, asking the email specialists to do email-specific things... > So, somehow I need to do this in the firewall/bridge. > > One way I thought of was patching the ipfreely TCP > proxy to exract these fields (from, to, subject) of > the SMTP dialogue. You should look at using a real application-layer proxy to do this, as it has to understand the SMTP state transitions. I have a vague memory of there being such a proxy in the (ancient) "Firewall Toolkit", but I never had a need for such a thing. Having that act as a transparent proxy (i.e., letting the internal MTA see the external host's IP address and TCP port) would probably require additional hacking, but maybe they don't care about that, given that they're unwilling or unable to assist in this project. (If your requirements are that this be done without the mail group being able to tell, then you *really* should have mentioned that to begin with, because it places significant bounds on the solution and we could have gotten to the "haha, good luck!" point much sooner) > But I was hoping that relayd could be used as an SMTP > proxy and had some logging facilities that allowed me > to get this info. Something like: > > check send ... expect.... And what, just log the contents of all lines that begin with From: or Subject: or MAIL FROM: and thus have false matches for all of the above lines? Or were you going to try to build an SMTP state machine in expect-style rules? Philip Guenther
