[quote user="GordonM"]
- I have to put a hole in my router firewall to allow forwarding to the server machine on my home network.[/quote]The "hole" will only be allowing traffic to the specified port on the specified machine. This is not a security risk, as long as you can trust the app that is listening on said port [:)] [quote]
- I will need to have MercuryS connection control largely wide open to allow connections from arbitrary external hosts. I am not sure how important blacklist management may be.[/quote]You can block IP ranges you have no need to get mail from (i.e Russia, Korea etc.) depending on your preference. There are a lot of DNS Blocklist services, some are better than others. (I use SPAMCOP, reasonable hit rate and very low (nil in my experience) False Positives. YMMV and experimenting is recommended.[quote]
- I presume that I should check the option for preventing SMTP forwarding of non-local mail.[/quote]YES! Also "Use strict ..." & "AUTH can relay"[quote]
- Although all local users will be just my family, it may be prudent to use Authenticated SMTP connections. I am not sure whether this is really necessary but, as it is easy to implement, I suppose the question would be "why not".[/quote]This can be relaxed for the local lan under the Connection Control entry "...can relay" but definately recommended for anyone 'outside'.[quote]
- I am not sure whether there is advantage in checking some of the "Compliance" restrictions. Some may be fairly obvious but, as all the local users are known to me (and are non-technical other than myself), it may not be an issue.[/quote]Newsletters, automailers etc. hit these quite often, I don't refuse on any of these. Transaction filtering, however, gets rid of a lot of crap (as long as you are careful with it [:)])[quote]
- I don't see much advantage in using SSL from the point of view of protecting the server from attacks, though it would obviously protect data transmisson.[/quote]Once it goes to the next SMTP server in the delivery chain, you have no control over whether it is SSL'd or plain text, so if it will give you a warm fuzzy feeling (or if connections are via a wireless link) turn it on. YMMV with some (notably MS) clients.[quote]
Although most of my concern relates to security, there are probably some other practical issues to think about, e.g.
- Should I be concerned about reverse DNS, to faciliate delivery?[/quote]You should have a rDNS entry, some servers refuse connections if there is none, some (very few really) refuse if it does not match the HELO hostname (mine does not and I have had no issues with this yet)[quote]
- I am currently using a dynamic IP address, with ZoneEdit installed to monitor changes. My ISP very rarely changes my IP address and I could get a static address for a fairly minimal cost ($4 per month), if needed. I am not sure whether it is worth doing this,[/quote]Some servers refuse connections from "dynamic" IP ranges, a static IP will probably avoid this (depending on the reputation of your ISP and what lists the said servers are looking up)[quote]
- I use OpenVPN for making remote connections to Mercury when I am travelling. I can't imagine that there is any issue with this, as it's on the client-side of Mecury.[/quote]Mercury doesn't care. It just sees a local connection from the VPN endpoint.[quote]
Any comments about what I am proposing, particularly from current users of MercuryS, would be much appreciated .... together with any things that I may not have thougt about!
Thank you
GordonM
[/quote]The DNS & dynamic IP issues go away if you use MercC to relay through your ISP smarthost (rather than MercE direct SMTP), but then you are still subject to any ISP imposed restrictions.
[quote user="GordonM"]
<ol>
<li>I have to put a hole in my router firewall to allow forwarding to the server machine on my home network.[/quote]The "hole" will only be allowing traffic to the specified port on the specified machine. This is not a security risk, as long as you can trust the app that is listening on said port [:)] [quote]</li>
<li>I will need to have MercuryS connection control largely wide open to allow connections from arbitrary external hosts.&nbsp; I am not sure how important blacklist management may be.[/quote]You can block IP ranges you have no need to get mail from (i.e Russia, Korea etc.) depending on your preference. There are a lot of DNS Blocklist services, some are better than others. (I use SPAMCOP, reasonable hit rate and very low (nil in my experience) False Positives. YMMV and experimenting is recommended.[quote]</li>
<li>I presume that I should check the option for preventing SMTP forwarding of non-local mail.[/quote]YES! Also "Use strict ..." &amp; "AUTH can relay"[quote]</li>
<li>Although all local users will be just my family, it may be prudent to use Authenticated SMTP connections.&nbsp; I am not sure whether this is really necessary but, as it is easy to implement, I suppose the question would be "why not".[/quote]This can be relaxed for the local lan under the Connection Control entry "...can relay" but definately recommended for anyone 'outside'.[quote]</li>
<li>I am not sure whether there is advantage in checking some of the "Compliance" restrictions.&nbsp; Some may be fairly obvious but, as all the local users are known to me (and are non-technical other than myself), it may not be an issue.[/quote]Newsletters, automailers etc. hit these quite often, I don't refuse on any of these. Transaction filtering, however, gets rid of a lot of crap (as long as you are careful with it [:)])[quote]</li>
<li>I don't see much advantage in using SSL from the point of view of protecting the server from attacks, though it would obviously protect data transmisson.[/quote]Once it goes to the next SMTP server in the delivery chain, you have no control over whether it is SSL'd or plain text, so if it will give you a warm fuzzy feeling (or if connections are via a wireless link) turn it on. YMMV with some (notably MS) clients.[quote]</li></ol>
<p>Although most of my concern relates to security, there are probably some other practical issues to think about, e.g.</p>
<ol>
<li>Should I be concerned about reverse DNS, to faciliate delivery?[/quote]You should have a rDNS entry, some servers refuse connections if there is none, some (very few really) refuse if it does not match the HELO hostname (mine does not and I have had no issues with this yet)[quote]</li>
<li>I am currently using a dynamic IP address, with ZoneEdit installed to monitor changes.&nbsp; My ISP very rarely changes my IP address and I could get a static address for a fairly minimal cost ($4 per month), if needed.&nbsp; I am not sure whether it is worth doing this,[/quote]Some servers refuse connections from "dynamic" IP ranges, a static IP will probably avoid this (depending on the reputation of your ISP and what lists the said servers are looking up)[quote]</li>
<li>I use OpenVPN for making remote connections to Mercury when I am travelling.&nbsp; I can't imagine that there is any issue with this, as it's on the client-side of Mecury.[/quote]Mercury doesn't care. It just sees a local connection from the VPN endpoint.[quote]</li></ol>
<p>Any comments about what I am proposing, particularly from current users of MercuryS,&nbsp;would be much appreciated .... together with any things that I may not have thougt about!</p>
<p>Thank you</p>
<p>GordonM</p>[/quote]The DNS &amp; dynamic IP issues go away if you use MercC to relay through your ISP smarthost (rather than MercE direct SMTP), but then you are still subject to any ISP imposed restrictions.