There are several choices of minimal, relay-only mail transfer agents (MTAs, or "mail servers"), some of which have been mentioned in other answers:
For either of those to work, you need a full fledged MTA somewhere that will further relay your messages (known as "mail hub") and it is strongly recommended that you control this mail hub. Bad Things™ can happen otherwise.
You have a rule to let the traffic out, but you don't have a rule to let the return traffic in.
I'm guessing you meant for these 2 rules to be -A INPUT instead:
iptables -A OUTPUT -p tcp --sport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 587 -j ACCEPT
However using the source port as a method of allowing return traffic in is a bad way to secure the system. All someone has to do is use one of these source ports and your firewall ruleset becomes useless.
A much better idea would be to remove all the -A INPUT ... --sport rules and use just this single rule instead:
iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
The way this rule works is that when your system makes an outbound connection, the kernel records the connection in a tracking table. Then when packets from the remote system come back in, it looks to see if those packets are associated with any connections in the tracking table.
The ESTABLISHED bit is the one that allows traffic directly related to the session. This will be TCP packets coming back on the stream.
The RELATED bit lets traffic that's related to the connection, but isn't part of the connection itself, through. This can be things like ICMP packets, such as "ICMP can't fragment". These packets aren't part of the TCP stream, but are vitally important to keeping the stream alive (which is also another thing your ruleset doesn't cover, and without which you will see odd connection issues and loss).
This rule also works for UDP traffic, but because UDP is stateless, it's not quite the same. Instead the kernel has to keep track of UDP packets that go out, and just assumes that when UDP packets come back on the same host/port combination, and it's within a short time frame, that they're related.
Best Answer
If your ISP is blocking traffic that you send destined for another host's TCP port 25, you will not be able to set up an outbound mail server.
Conversely, if they are blocking inbound connections to your TCP port 25, other mail servers would not be able to deliver messages to you.
Additionally, it is typically not very effective sending mail directly from dynamic IP space because commonly these netblocks are abused by malware and viruses to send spam and, as a consequence, many mail servers ignore them outright.
Port 25 is the only port used between MTAs for delivery. Other ports you might read about are only used by MUAs (clients) for relay purposes.
You could configure your local MTA to use your ISP's mail relay as a smart host (outbound).