On Wed, 2004-11-03 at 16:38, Paul Howarth wrote:On Wed, 2004-11-03 at 02:13, Ow Mun Heng wrote:
If however, the original poster only wanted to open up a MTA/MSA for his user that has port 25 blocked by the ISP, port-forward the default port 25 to another server running a MTA on say port 2525. That way, there's only 1 listening MTA.
Let's compare the two solutions:
Port forward port 2525 to port 25: * Only one daemon running, listening on two ports (plus separate MSP instance). * Port 2525 accepts mail from any client without requiring authentication for local delivery (though of course it's needed for relaying, just as it is on port 25). * Does not necessarily fix up mis-formatted mail submissions, e.g. with non-fully-qualified hostnames/addresses etc. (depends on whether you're using the `always_add_domain' feature, masquerade settings etc.).
Separate MSA on port 587 and MTA on port 25: * Only one daemon running, as MSA on port 587 and MTA on port 25 (plus separate MSP instance). Check the output of ps to verify this for yourself.
799 ? Ss 0:00 sendmail: accepting connections 802 ? Ss 0:00 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue
There are 2 instances.
The first is the MTA/MSA (configured by sendmail.cf), the second is the queue runner for the MSP (configured by submit.mc). If you turn off the MSA you'll still have two instances.
* Port 587 can *require* authentication for all clients, preventing unauthorised use for local delivery
I'm on a laptop. I'm the only pre-configured user. So, for mine, the MSA does not need authentication. Firewall walls up the MSA(and the MTA)
But if you are roaming, you may not be able to send mail directly from your laptop due to outbound port 25 blocking. The idea is to have the MSA running "back home" so that you can use that wherever you are. This doesn't apply in your case though because you don't have a "back home" with a static IP to run your MTA/MSA.
Paul.
