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*
