Jonathan GF wrote: > Hi Bill, > > thanks for our explanation. Let's explain a bit more: > > Current implementation is composed of: > > - 1 server acting as smarthost, adquiring incoming email and sending out > email forwarded from the internal mail server. > - 1 internal mail server, the one that hold user's inbox. >
First impression is that you've added complexity and CAPEX - but may have actually *reduced* real-world security - even reliability - and do not look to be saving any money on operating expense, either. Your 'smarthost' is also onpassing the incoming mail to get it into those user inboxen.. e.g. - it is a full-house MTA, relaying both ways, not just an outbound 'smarthost'. >>From LAN: > Users can connect directly to internal MTA, send mail, and this will be sent > out to internet thru the smarthost. > >>From Internet: > Users connect to secure ports 465 and 995 of Internal MTA and send mail. As > from LAN, the mail will be forwarded to the smarthost for delivery. > Not sure I see the logic of exposing the MTA on the internal LAN to the outside when you have a 'smart' host that is already accepting both their incoming AND outgoing traffic.... but.. let's have a look... > Smarthost: > Only processes incoming email from anyone and outgoing email mail for my > domains only. > > I decided to use this architecture for some reasons: > > 1) i wanted the smarthost to hold the direct and reverse dns so it behaves > as the RFC depicts > 2) the smarthost only do this task, forward mail and store if it cannot > contact the internal servers > 3) internal server, right now is behind a firewall that connects to internet > using a DSL line (to cut monthly expenses). Only the smarthost can connec to > port 25. Users have to connect using secure ports 465(smtps) ..should be port 587. Port 465 was long-since assigned to a Cisco protocol that ISTR has to do with internet TV and such.. > and 993(imaps) > 4) i want to expand this model to accept processing for other domains that > works exactly the same, behind DSL lines to cut monthly expenses OK - one 'presumes' that the smarthost is NOT on DSL, e.g. is located where it has a fixed-IP, is not in a dynamic IP block, has proper PTR and MX RR et al. So - once you have that expense *at all*, where is the cost-saving from not using it for the whole task? > 6) i need a temporal storage in case i cannot connect a peer server > Rather than over-engineer for that particular sort of failure - I'd try to find a better environment (upstream). Or not - if it is not a known issue. > Internal Server is doing smtp auth against Smarthost using plain > authenticator over TLS as shown in the configuration examples and works > really fine. As smarthost only put messages to my domain to the Internal > Server there's no need to authenticate this part of the connection. > I wouldn't assume 'no need' unless you have some other stuff in place. A point-to-point roll-cable and non-IP protocol, for example. ;-) Otherwise, BCP says one *authenticates* (and as securely as can be). > I've published a picture showing the model i'm following and my configs, for > both the smarthost and the internal server @ > http://www.surestorm.com/MAIL/Smarthost+InternalServer/ > > Any help will be welcomed. You have two servers and a firewall any one of which is a blocking point of failure, and none of which (presently) can really cover failure of any other. More admin pain that gain, is it not? > > Cheers, > > Jonathan GF As to the DSL and/or roaming ... it isn't important to either smtp or POP/IMAP, *so long as* you accept auth based on UID:GID and protocol, not arriving IP, AND use the 'submission' port (587) not 25. An https Webmail can cover the rare airport/hotel/client site that blocks 587/993 - which nothing you are doing at present covers anyway. JM2CW Bill *prior posting history trimmed* -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
