I need to modify Postfix to listen to port 587

Question

Mountain Lion Server OS X 10.8.4
Running Mail service with Postfix and Dovecot. In production with several mailboxes.
I need to modify Postfix to listen to port 587. I should be able to telnet to port 587, and finally send mail via 587.
587 already redirects to 25 via the firewall, but external devices need to visit the internal subnet without modifications to the mail app.
At this stage I just want to get it working with password authentication.   SSL is a project for another day.
Here's my understanding of the OS X Postfix config:
/etc/services file:
Maps service names to port numbers.  Port 25 is  "smtp" and port 587 is "submission".
/etc/postfix/master.cf file:
Loads Postfix preferences. Service configurations for "smtp" and "submission" are listed at the top of the file. Each service configuration can be modified with parameters (-o variable_name_here=value_here).
I found many discussion boards with instructions for enabling 587. They suggest removing the comment syntax for the existing "submission" line:
# submission inet n - - n - smtpd
My server didn't have a comment, the line was already enabled:
submission inet n - - n - smtpd
I restarted services and 587 didn't work.
Then I tried a more direct approach:
587 inet n - - n - smtpd
This had no effect.
After each attempt to enable 587 I test with:
telnet 127.0.0.1 587
And I get: Connection Refused
I used the Server app and turned Mail off and on. This stops and starts Postfix.
I also used commands to restart Postfix:
postfix stop
postfix start
sudo postfix stop
sudo postfix start
postfix reload
sudo postfix reload
Nothing opens 587.  Any ideas? Thanks in advance for your insights.
-SE30Emulation

Answer 1

@Kraftwerk: You cannot change the TCP port used for SMTP.  Well, technically, you can, but then no other mail servers on the Internet will find and communicate with your mail server.  So... forget that.
The ISP controls the terms and conditions for the network connection, and particularly controls the network and network access.  There's just no way 'round that either, as the ISP has the network position to implement port blocks and firewalls, and usually the contractual authority to allow or deny access.
With the proper (static) network connection and proper DNS, there is nothing to struggle with; this stuff works. 
Which implies your ISP does not offer static connections, or there's an ISP error, or you're attempting to operate a mail server on a dynamic address.  None of this works.
You might try mailhop service — if that's permitted within the limits of the terms of service — but it'll be easier and cheaper to host your mail elsewhere.  Or to get a static IP address and proper public DNS, if your ISP offers that. 
SMTP services are also tied to DNS, as well; other mail servers use DNS checks to detect rogue (spam) servers, and a mail server erroneously configured on a dynamic IP address will have mismatched DNS, and other mail servers will detect that and drop mail from and often to that mail server; that server is indistinguishable from a spam engine.
There's rather more the ISP can do as part of best-practices networking, too.  TCP port 25 connections both inbound and outbound are usually spam engines operating on malware-infested, so it's common to block that traffic to reduce the volume of spam.  Various ISPs will further blacklist dynamic IP address blocks, which means other SMTP servers using these blacklist services will ignore servers in these address ranges.
Get static IP.  Or host elsewhere.  Or (if permitted) mail hop.