Incoming mail on port 587

[magicman]

I'm searched the forums and I couldn't find anything related to this.

My ISP blocked port 25 in and out thus rendering my Scalix server useless. I've managed to get SmartHost working so now I can send mail outbound through my ISP via port 587. However, I still can't receive email. I'm not sure how to make Scalix accept inbound email on port 587.

Thanks.

Abe

[jaime.pinto]

Add the following to /e/tc/rc.local

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 587 -j REDIRECT --to-port 25
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 10025 -j REDIRECT --to-port 25

The above also shows how you could assign some "special" port to specific clients in order to let then use your server for SMTP connections (10025 for example)

[magicman]

I'll give it a try.

That's really the way to do it? There's no way to tie Scalix to port 587?

[magicman]

Well, the mapping worked (i.e. I can telnet into 587), but external email is still not getting through.

[dkelly]

How does external mail know to use port 587 to your server ?

Cheers

Dave

[magicman]

Ultimately I guess that's the question.

When I send an email from say a GMail account to a Comcast account. What port does it go over? Is it always port 25 from mail server to mail server? And 587 internally? Or does GMail know that Comcast only supports SMTP over port 587?

[jaime.pinto]

When I send an email from say a GMail account to a Comcast account. What port does it go over? Is it always port 25 from mail server to mail server? And 587 internally? Or does GMail know that Comcast only supports SMTP over port 587?

Gmail sends on port 25 (or 527)/465. Comcast receives on port 143/993


In general, only ISP's or "private" SMTP operators "capture" port 25. For example, Rogers, the largest ISP in Canada, blocks port 25 beyond *their* SMTP servers. The University of Toronto also does. What that means is that any mail client (OL, thunderbird, Eudora, Evolution, etc) can only use *their* SMTP servers to send emails out. That's the only way they would ever assume responsibility for any email being sent from under their "umbrella", and guarantee they will be free of virus, spam, etc, therefore protecting their reputation.

So, what about "corporate" mail servers under those umbrellas? Well, they get blocked as well, unless an exception rule is applied individually.

But this doesn't happen over any port. Usually it's only on port 25, because this is the one most commonly hard coded on the viruses on Trojan horses. Hence port 25 being deprecated in favor of port 587. But that doesn't mean 587 will automatically be utilized by clients or "internal" mail servers. They have to be set like that.

It's also important to understand the *direction* in which communication takes place. Port 25 only comes in place TO SEND EMAILS OUT, not to receive.

In your case, you found the trick to send emails out, by relying on *your ISP* to proxy the sending out task on behalf of your server via port 587. You could also instruct end-users outside *your network* to change the default port on the SMTP/outgoing mail server to 527, so that they use *your* server directly to send emails for them, rather than their IPS's.


What about the INCOMING email? Well, that has nothing to do with port 25 (or 527). You receive emails via port 143. IPS's in general do not block this port, basically they have no reason for it. They can just filter emails passing through their firewalls so that YOU don't get any spam. Often times they do too good of a job, and discard a lot of legitimate emails from your perspective.

But again, maybe they are indeed blocking port 143, to keep you from receiving emails directly, and force you to use their server to receive emails for you (and you use fetchmail for retrieval). Well, depending on your contract with them this could be illegal on their part, so you have to complain, and ask them to apply an exception rule. Otherwise there is absolutely nothing that you can do regarding gmail or any other IPS's out there. It's not up to them or you, only your ISP.

On the other hand, it may just be the case that they are blocking "unsecured ports" (25/143). In this case, enable SSL and/or TLS on your server as well (ports 465 outbound and 993 inbound). It is still no guaranty you will receive emails from every ISP out there. Only those that are configured to resend over 465 when 25 fails.