ISP blocked port 25

I have tried and failed to figure this out. First off, I use 3.35-1woody2.

Eastlink (Canada) has blocked all outgoing port 25 requests in an effort to stop the spread of spam and other email issues for home users. This means that we can't use our work email to send emails anymore, unless our work runs email on another port. Anyway, what I need to do is find out how to make exim send all email through local port 26 not 25(which I have tunneled to another server). The reason I need exim to send mail through port 26 is because when I use stuff like mailx or other email tools like it, exim just sends it using port 25 and the emails don't make it.

Does this make sense?

You really have two problems here. The first is user's being able to connect to your server to send email. and then exim's outbound connection to send/receive email.

I'm going to make a few assumptions here.

1. You are using a SMART host that will listen to port 26
2. ALL of your users have configured there clients to talk to port 26 not port 25
3. You are recieving your internet mail via a MX host that knows to talk to you via port 26.

I personally use both on a few of my servers because I force authentication, and when you travel many hotels are now inteceprting SMTP port 25 traffic and sending it to there server ( and there is not auth there ) so clients can not send mail, So for those users I have port 26 open.

in the main config section add

Code:

---

local_interfaces = 0.0.0.0.25:0.0.0.0.26

---

that will listen on both 25 and 26

Yes, except you should consider using the Mail Submission Port (587, IIRC), which already exists for this purpose.
Why not just route the email through the ISP's mail relays? Its fairly easy to do with exim.

I think there are three obstacles in doing that:

1. Not every DHCP server publicize mx server, and exim [as well every other MTA/MUA] does not recognize them, so if you are on the move you have to change it every time
   
   
2. If you use authentication (for example here you can send to internal distribution list only if you authenticate ...)
   
   
3. You lose the control on delivery (for example here if someone send a message can ask the net admin to check if it has been delivered, or if not where is the problem)

Why add an extra step to try to debug unless needed? Why pass work mail through a third party which you don't control and could be snooped? Why play into their laziness?

There are many reasons why someone would not want to do this, including the need to reconfigure your laptop every time you are at home, on the road, at the office, etc.

There is also the fact that many ISP's mail servers suck (Verizon is a very good example of this.)

Using RFC2487 over port 587 also give remote office users the ability to send messages that may be confidential to others in their organization securely - things you may not want to send over the public internet.

Of course he can also use a VPN, but this may be overkill. Sometimes you don't want random remote machines fully connecting to your network (think blaster.)