Wow. I never expected it to be that easy!
Really, you are. Warned, that is.
By convention, TCP destination port 25 is used for SMTP, Simple Mail Transport Protocol, the Internet application protocol for delivering email to a recipient's mailbox. Unlike some other protocols beginning with the letter "S", SMTP really is simple. The sending computer opens a SMTP session to the recipient, identifies the sender and the recipient(s), sends the body of the message, and closes the connection. That's it. Simple.
So despite the huge growth in the volume of Internet email and major changes in how it is handled, SMTP is still one of the oldest Internet protocols still in widespread use. Before the personal computer, Internet email was often directly transferred from the sender's to the recipient's computer in a single SMTP hop. Both were usually large mini- or mainframes owned by a company or government, ran 24 hours per day, were always online, and were accessed directly by users from hardwired or dialup "dumb" terminals.
As the dumb terminal was displaced by desktop and portable personal computers able to execute the Internet protocols and participate as full-fledged Internet hosts, the mail proxy server was introduced to accept SMTP connections on behalf of end users whose personal computers were not always up and connected to the network.
New application protocols, first POP (Post Office Protocol) and later IMAP (Interactive Mail Access Protocol), were introduced to allow a personal computer to retrieve a user's incoming mail from his mail proxy server.
The early email clients running on personal computers, such as Qualcomm's Eudora (e-mail client), still used (and use) SMTP to send outbound email. But for some reason the SMTP session generally wasn't opened directly to the recipient's mailbox but to a predefined "mail relay". It was usually operated by the sender's organization, and often it was the same physical machine that stored his incoming mail. In turn, the relay initiated a SMTP session to the remote recipient.
This practice may or may not have originated with Eudora to simplify that email client. However it started, it has since become common practice even though it would be trivial for today's email clients to resolve the appropriate MX and A DNS records and deliver outbound email directly to its ultimate destination. Only in the very special case of an unreachable destination and a sender that's in a hurry to go offline, then and only then would the client transfer the mail to an intermediate relay to continue delivery attempts on its behalf.
For reasons still not at all clear, somehow the misperception became widespread that one could magically stop spam by blocking direct SMTP deliveries from computers run by mere mortals and forcing all outbound email through intermediaries. Such blocks are generally implemented in one or both of two ways. Many large operators of incoming email servers refuse to accept (blacklist) SMTP sessions from IP addresses known to be dynamically assigned to dialup or residential broadband customers. And some ISPs -- like AT&T -- block outbound connections from their dialup and residential customers to TCP port 25 (SMTP), except to their own relays. (Many email relays also accept SMTP on TCP port 587, so some ISPs block all outbound connections to port 25.)
It should be obvious by now that I don't like being forced to use my ISP's outbound mail relays. I'm quite capable of delivering my own outbound email, thankyouverymuch, and I strongly prefer to do so. So I need 1) an IP address that isn't on the dialup/dynamic blacklists and 2) the ability to make outbound TCP connections to port 25. This was one of my main reasons for leasing an optional static IP address block from AT&T with my Uverse service, so I was quite dismayed to discover that they blocked my outbound connections to port 25!
I read on a Uverse forum that one could ask AT&T to remove this block, but I was skeptical. I steeled myself for a long argument. I knew I would have to explain repeatedly why I wanted to make my own outbound SMTP connections. I would have to explain why I didn't want to use their email relays, and no, I'm not a spammer! For one, I don't like having my mail disappear into a heavily loaded server that I don't control, without any way to tell when my mail actually makes it to its destination, if in fact it ever does. Also, I regularly send mail from several different email addresses, which many ISP-provided email relays do not permit; they only allow you to use the email addresses that they provide -- yet another ill-conceived anti-spam measure.
After all, AT&T, if you catch me spamming, you can still cut me off. Right?
So I opened a chat with an AT&T customer service person. "Hi. I'm a new Uverse customer, and I would like to have the block on outbound port 25 removed."
Just as I was about to start explaining what "port 25" was, she offered to remove the block for me while I waited. Several minutes later, she told me to try it. Sure enough, it worked! I could deliver my own email. I never expected it to be that easy.
So I have to hand it to AT&T for this one. I didn't like the fact that they didn't openly document their policy regarding port 25, but I can't say it was difficult to get the block lifted once I learned that I could just ask them. I'm sure that the block remains in effect for the large majority of residential users who don't even know what a "port 25 block" is and who don't have any serious problems with using AT&T's mail relay. Who knows, maybe this policy actually does block a fair amount of spam that might otherwise be directly delivered from computers that have been compromised and harnessed into underground botnets. But I still can't see how it blocks those same compromised computers from simply hammering AT&T's mail relays with spam. At least I don't have to use them...