GrayHat wrote: >> I'm not sure why everyone is making this so complicated. >> > [...] > > >> Internet - smtp -> ASSP - smtp-> MTA - smtp -> Client - pop/imap/etc >> > > >> Client - smtp -> ASSP - smtp -> MTA - smtp -> Internet >> > > first of all, this config ass-u-mes that the internal clients are > talking to > the MTA using SMTP, which isn't always the case (e.g. in some > cases there may be proprietary protocols involved); next, while the > above config works, using it means that each and every email from > a local user to a local user will pass through ASSP and poses an > additional (and in general unneeded) load on ASSP; also, in case > the MTA, for whatever reason will be "offline" the incoming mail > flow will be broken... on the other hand, a config like this one > > internet -> ASSP -> postfix -> internal MTA -> client > > client -> internal MTA -> ASSP relayport -> postfix -> internet > > will let the local mail flow only on the internal MTA, while all the > external email will be handled by ASSP, more, since the incoming > email is relayed to the internal MTA using the postfix sitting on the > ASSP box, in case the internal MTA is unreachable, the postfix > will handle the mail queue and despool the waiting messages to > the internal MTA as soon as it gets back on; if you consider that > such a config just requires two boxes as your one you'll see that > it isn't so complex at all; also, and to conclude, I usually prefer > putting the ASSP+postfix box inside a DMZ to gain an additional > insulation layer; in my config I usually have a box running ASSP, > postfix and BIND (or, in case of a windows box, ASSP, the IIS > SMTP and the MS DNS) this also allows me to manage DNS > zone "routing" as needed; the only ports which will then need > to be opened between the DMZ and the internal MTA will be > the 25 and the one used for LDAP queries (to validate addrs) > the second being optional in case you use VRFY for this task > Mostly valid points I suppose, except for the bit about assuming internal mail on smtp. The same config can handle it with submission, etc., without any additional bits required, just add the appropriate ports to the config. I do see two negatives however.
First, internal mail being processed should have only minimal impact and since it is normally safe it helps populate and define the HAM corpus. If even 10% of the volume is legitimate then doing the internal mail as well should have little enough impact that if your servers can't handle the increase they're probable due for replacement anyway. Not a big deal, but a benefit which should be considered before dismissing it entirely. Second, is the level of complexity. For those who prefer to use the KISS principle it seems to add an extra layer of complexity which should always be weighed against the perceived benefits. In your case you've hopefully done so and feel that the extra complexity is a viable trade off for the gains you get. In that case I applaud the appropriate use of the tools at hand. That may not be the case for everyone, including the OP. If it is then by all means your choice is a better solution. But if you don't know about the alternative then you can't make an informed decision. I like options, and I love making lots of pieces fit together to provide a smoothly functioning process. Unfortunately I also realize that sometimes my passion for doing so isn't the best choice. As they say in the QA world, 'Better is the enemy of Good'. :) Sometimes the simplest solution is the best choice, not because it does everything, but precisely because it doesn't. As long as it provides the pieces you do need, the rest is of no, or at least less, value. Melvin ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Assp-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-user
