Feb 102006
Is your ISP blocking port 25? Here’s a Postfix solution.
My ISP started blocking incoming port 25. It’s already blocking outgoing port 25 and I’m handling that. Now it’s time to start accepting incoming mail on the submission port, 587. They aren’t blocking my incoming port 25. But we went through this process for another guy on our computer, so I figured that this is a good thing for which it will pay to be pro active. This solution assumes you have a mail server at home and at least one other mail server out there on the Internet, one which does not have port 25 blocked. That part is crucial to this solution. It is the external server[s] that will accept incoming mail and forward it to you. In DNS terms, your MX records will not point to your home server, but to your public server.Your home mail server
I started by adding the following line to/usr/local/etc/postfix/master.cf
on my Postfix mail server at home:
where10.34.0.1:587 inet n - n - - smtpd
10.34.0.1
is the public IP address of my mail server [no, that’s not
really my IP address]. This instructs
Postfix to listen on that IP address on port 587. This is known as the submission
port:
$ grep 587 /etc/services submission 587/tcp submission 587/udp
Your public mail server
Then I added this to/usr/local/etc/postfix/main.cf
on my public mail server:
This tells Postfix to observe the transport directives in the above mentioned file. You can put the file whereever you want. I like to keep it in that directory, which you’ll probably have to create because it’s not part of the standard system. Intransport_maps = hash:/usr/local/etc/postfix-config/transport
/usr/local/etc/postfix-config/transport
I have:
Wheremyserver.example.org smtp:[myserver.example.org]:587
myserver.example.org
is the hostname of my mail server at home. You need to create a .db
file to go with that. I issued these commands:
cd /usr/local/etc/postfix-config postmap transport
You should now see a transport.db
file.
After making these changes you should restart postfix:
postix restart
Testing
Then I sent a test message from the public mail serverI confirmed that it was coming in on port 587 with this command on my mail server at home:$ echo 'test' | mail me@myserver.example.org
Where fxp0 is the outside NIC on my firewall (the one with IP 10.34.0.1) as shown above. Then, on the public mail server, I requeued all the messages, so they’d use the right transport:tcpdump -i fxp0 port 587
It’s magic! All the messages were delivered to the right spot.postsuper -r ALL
My provider also blocks outgoing port 25, as does the corporate LAN I’m on. Port 625 (the standard SMTPS port), however, is rarely (if ever) blocked when you have access through a NAT or ISP. The added bonus: secure transport (and perhaps authorization!) to your MTA.
A lot of ISPs (including me) use port 2525 to allow users to relay email.
In postfix, all I had to do was add;
2525 inet n – n – – smtpd
right after the smtp line in the master.cf.
I have also setup several Sendmail servers to listen on port 2525 as well. Yuo cna lock down these to require SMTP AUTH on those ports to do anything. In the sendmail.mc file I changed so many things it is hard to remomber where I started. But this is right from a working sendmail box;
DAEMON_OPTIONS(`Port=25, Name=MTA, M=E’)
DAEMON_OPTIONS(`Port=2525, Name=MTA, M=Ea’)
The "E" is for ESTMP, and the "a" is for the SMTP AUTH.
-Kahn
Unless I misread your article, you recommend to set up port 587 just like port 25, ie. no authentication is required to submit mail for local delivery.
This seems to be rather unwise. You’re abusing the submission port for point to point mail transport, something it was not designed for. By doing so, you risk that ISPs will begin to block port 587 too, because it is being (ab)used for transport. The whole point of the submission port is the separation of transport and submission, which allows to block transport from end user address ranges without blocking submission.
I think you really should mandate SMTP AUTH on the submission port, even in such a point to point scenario.
[%sig%]
roe wrote:
> Unless I misread your article, you recommend to set up port 587
> just like port 25, ie. no authentication is required to submit
> mail for local delivery.
Correct.
> This seems to be rather unwise. You’re abusing the submission
> port for point to point mail transport, something it was not
> designed for. By doing so, you risk that ISPs will begin to
> block port 587 too, because it is being (ab)used for transport.
> The whole point of the submission port is the separation of
> transport and submission, which allows to block transport from
> end user address ranges without blocking submission.
>
> I think you really should mandate SMTP AUTH on the submission
> port, even in such a point to point scenario.
Would restricting connections to port 587 suffice?
—
The Man Behind The Curtain
Dan wrote:
> roe wrote:
>
> > I think you really should mandate SMTP AUTH on the submission
> > port, even in such a point to point scenario.
>
> Would restricting connections to port 587 suffice?
Sure. But on second thought, since you’d technically still be using port 587 for (static, non-public) transport, I’d rather use some random high port instead.
Typically ISPs like comcast block port 25 access by default. If you can give them a business justification, they will remove these restrictions. If they don’t, speak to someone else when you call support. Eventually you will get an engineer who actually understands your needs (rather than just using the blanket excuse "we don’t allow port 25 access") and will lift the restrictions.
[%sig%]
I tried to tell this to Sympatico, but it was wasted breath. However, Istop/Cybersurf does not block 25 in either direction.
[%sig%]