Thanks Noel. I hadn't considered the STARTTLS issue (and probably many others).
Not what I wanted to hear, but better that I hear it now than later mike On 9/25/07, Noel Jones <[EMAIL PROTECTED]> wrote: > > At 01:25 AM 9/25/2007, Mike Kenny wrote: > >We are in the unfortunate position of supporting an ISP environment where > >our users either connect to our SMTP servers and their mail gets filtered > by > >our defenses or they can connect to an smtp server of their choice (i.e. > we > >don't block port 25). In the latter case the spam defenses may not be as > >effective as we would like. This results in mail leaving our network > >containing some spam. This obviously won't do. > > > >Since many of our users are corporates who insist on using their own > servers > >for reasons of legalese insertion, signatures, corporate image, etc. we > need > >to place a proxy on port 25 traffic to apply our own rules to mail, > before > >it reaches the target server. Postix, it seems, is not designed for this > >purpose and introduces all sorts of header re-writing issues in order to > >maintain the appearance of passing directly through the target smtp. I > have > >been wondering what would be the impact of bypassing the MTA and using > >amavisd-new as the proxy. > > > >I have run some minimal tests with amavisd listening on port 25 and > postfix > >on a second machine. In so far as I have been able to test this > >configuration it appears to be doing what I want. Spam gets blocked by > the > >amavis server, mails that pass through appear to never have touched our > >servers, bounce messages from the target server are passed directly to > the > >real sender, bypassing our servers. > > > >Because of the nature of the usage of our service most connections to > this > >environment will be from MUAs rather than MTAs. > > > >I feel that I must be missing something, that it can't be as easy as it > >appears to be. I just am not sure where I should be looking. I know that > I > >may have issues with bounce notifications from amavisd (I have been > unable > >to test this properly yet) and that there be timing issues while a > sending > >MTA waits for an OK from amavisd. Also, I am not sure about the message > >integrity. If amavisd was to die during processing, where would the > message > >be? Or would this be any different than normal usage of amavis? > > > >I know that the above is not the way things should be done but, in my > >defense, a) I have no choice due to the way my employers operate and b) > it > >will only be short term solution pending implementation of a more > permanent > >solution. > > > >Any comments, warnings, pointers, etc. greatly appreciated. > > > >mike > > Amavisd-new is not designed as a transparent proxy, and is unlikely > to perform very well when used in that manner. The two biggest > problems I can think of are a) amavisd-new is designed to connect to > a specified endpoint, not to an arbitrary server on the internet and > b) will not propagate STARTTLS sessions, preventing MUA submitters > from logging on to servers that require TLS before they will do AUTH > - a common configuration. I expect there are other practical reasons > this isn't a very good idea, such as simply throughput limitations. > What about privacy issues? Do you have the right to intercept mail > from paying customers in this manner? > > I think you and your customers are better off if you simply block > outbound port 25 by default and then unblock for static IP customers > on request - maybe just let them send an email or fill out a web form > rather than calling tech support. Then an automated check of the > more widely used RBLs for IPs listed in your customer range every so > often. You may already have a pretty good idea of who is running > their own mail server and can proactively unblock them. > > For customers that use an MUA to submit mail to some "foreign" > server, nearly all servers offer service on the "submission" port > just for this purpose; most shouldn't need access to port 25. I > understand this will require some customers to change settings on > their mail software, so may be rather distasteful to your > organization. Presented as a method to increase customer security > and improve service may make it more palatable. > > Anyway, HTH. > > -- > Noel Jones > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
