Give some thought to potentially unexpected side-effects of configuring off-site "local networks".
The users at 93.zzz.zzz.0 may now be able to access some of your SME services in ways that expose unencrypted passwords to intermediate ISPs.
The most obvious example I can think of is POP3 mailbox access - which will allow any ISP between 93.zzz.zzz.0 and your SME server to "snoop" your usernames and passwords.
FTP and HTTP access to ibays may also allow plain-text passwords on the "local" network.
As I see it, you have three basic options:
- Examine your specific situation and decide that the security exposure is bearable.
- Determine which services may expose plain text usernames & passwords, and address each service individually.
- Figure out how to customize or modify qpsmtpd to allow relay without using the "local network" trick, which I think you can do using something like this:
cd /var/service/qpsmtpd/config/peers/
ln -s 93.zzz.zzz local
Notes:
* The qpsmtpd trick shown above will disappear whenever you run "signal-event email-update", so you'd need to figure out how to make it more permanent.
* I think that leaving off the final ".0" from the symlink causes it to affect all network addresses that begin with "93.zzz.zzz", based on
When connection arrives from client a.b.c.d, it searches in config/peers/ for a secondary plugin config file called "a.b.c.d", then "a.b.c" then "a.b" then "a" and finally "0". If none is found, the plugin returns 'DENY'. Otherwise, the plugin configuration specified is loaded, and 'DECLINED' is returned.
3 Replies
1142 Views