From the behaviour you describe, your design takes an effort at
tearing down just about the nicest part of SMTP: its resilience against network outages.
On 8/9/06, openbsd misc <[EMAIL PROTECTED]> wrote:
the smtp proxy should not be allowed to queue a message, else the size of the ramdisk would set the maximum message size.
I wonder what your rationale is behind your intention to have the proxy function from RAM. It seems to cause more problems than it solves.
[...] I need a solution that streams the mail after checking the envelope (smtp session) informations.
From a functional point of view, you need a proxy that kills off
unwanted messages and reliably delivers them to your Exchange device. Shielding an Exchange server from the big bad Internet is good practice. I can heartily second Rod Whitworth's suggestion and assure you it works quite well. Your streaming wish seems to come from your wish not to store data on a ramdisk. Once again: why have the ramdisk at all?
It should also drop the connection if the exchange server is down.
You could do that and perhaps there are several good reasons for dropping connectivity. Keep in mind that you're actively shutting down SMTP-availability for your site with such a measure. What do you specifically need your Exchange server for that you must shut down your site in case it is unavailable? Allowing for your proxy to have an up-to-date table of valid users can be achieved quite simply without having to sacrifice SMTP-availability (once again, see the Book of Postfix example for pointers, p. 174 and onwards)
Without that problem I would take qmail.
Qmail (SMTP) stores its work in progress in /var/qmail/queue. I'll admit not having checked the QMTP/QMQP sources, but I suspect qmail-qmtpd or qmail-qmqpd store their work there as well. It's been a while since I actively administered qmail (and I'm reluctant to touch our last few remaining qmail setups to find out more). Cheers, Rogier -- If you don't know where you're going, any road will get you there.
