smtpd_sasl_auth_enable = yes
SASL is an authentication method. It is used to allow users to authenticate themselves on your server so that it will permit mail to be transmitted to domains other than your recipients. When a message comes in, Postfix asks itself, "Is this for my user (domain, aliais, etc)?" and if the answer is no, it then relays the message to the next hop. Normally, this is prohibited (relay access denied) to avoid being an open relay. SASL allows you to authenticate so that it will allow you to relay and send mail to others.
I think the traceroute points us to the problem location. Traceroute does a ping to the final destination and sets the TTL (time to live value) +1 on each hop. As the packet traverses the router, the TTL is decremented so that it "fails" at each router stop. This way you can see where the packet was routed on its way to the destination. In your case, it tells us what was the last stop that we were able to get a response from - hence where did the traffic stop. The limitation to this is that it uses ICMP messaging which doesn't tell us much about which ports are open.
In this case, we can see that the last node to respond was at IP 220.127.116.11. If this is not your public IP, then you need to contact the network admin of this network because it is where the stoppage is occuring. You can find out the contact information by doing a whois 18.104.22.168. In this case it is globenet.com.ph.
It is also interesting that that you are passing through a couple of 10.x.x.x routes which are typically non-routable addresses, but this may be part of their internal processing. You can see that between the start and the destination it is passing through Alter.net as a provider. I notice the addresses in (), which I haven't seen before and I am not sure what this means. A nslookup of the address returns SERVFAIL, suggesting that something may be wrong with their DNS configuration, but I don't think this is the problem.
In anycase, you now have a list of the networks in the middle of the chain. By doing a whois against each of the IP addresses you can find out who owns the networks and then contact them to see if they are blocking port 25. The fact that you can't telnet in from outside your LAN when inside your lan works, and you aren't running a firewall says that someone is blocking the traffic. Start at the end of the list, globenet.com.ph, and see if you can get some results.
Off hand, I am not sure how to go around port 25 as I have never had to deal with this. I am sure there is a way, but I don't know how complicated it would be. I would google for "SMTP on non standard ports" or something similar.