On Wed, Aug 09, 2006 at 04:52:21PM +0200, openbsd misc wrote:
> > > openbsd misc schrieb:
> > > Hello,
> > >
> > > I'm looking for a smtp proxy. The idea is, that the proxy checks the
> > > smtp session (if everything is valid and forward the information
> > > to an exchange-server). The forwards should happen step-by-step
> > > (the smtp proxy should be able to drop to be able to deny the
> > > recipient). The mail itself should be streamed (because the proxy
> > > should run in memory only).
> > use a standard smtp daemon (sendmail, postfix or whatever) and put the
> > spooling directory in a ramdisk :-)
> the problem is, that the smtp proxy should not be allowed to queue a
> message, else the size of the ramdisk would set the maximum message
> size. To avoid that, I need a solution that streams the mail after
> checking the envelope (smtp session) informations. It should also drop
> the connection if the exchange server is down.
> Without that problem I would take qmail.
As always, what's the problem you are trying to solve? You've been told
to use a standard MTA on a standard disk, but apparently that doesn't
cut it.
Using a ramdisk is not a very good alternative as it can easily lead to
mail loss; however, your comment about maximum message sizes makes me
wonder what you intend to do. Since very, very few mail servers on the
internet will accept anything over 50 MB (and only a small number accept
anything over 10 MB), this need not be a problem on a machine with a
generous amount of RAM.
What are you trying to do, send your backups over SMTP? In a typical
mail load, this wouldn't be much of a problem. (The reliability issue
stands, though.)
Queuing mail when the Exchange server is down is a good thing, I'd say;
but a simple cron script or somesuch would suffice to shut down the
proxy server, and I'm fairly certain all competent MTAs can be
configured to deliver to a secondary destination if the first is
unavailable, especially given the aforementioned cron job.
However, there may be valid reasons for your unusual request - please
tell us, and we can be more useful.
Joachim
