Workarounds for blocked port 25 on outgoing e-mail

[Cody Baker]

What Logan wrote was mostly true, port 587 is the recommended way of 
doing it, and SSL (TLS) is a recommended option for just about 
everything.  Another, albeit far less popular, and much less supported 
option is to use IMAP to send mail.  Courier-IMAP (I'm not sure about 
the others) has an option where messages placed in a special Outbox 
folder are automatically send by sendmail running locally on that 
server.  This eliminates the issue of SMTP relaying entirely.

The other challenge Logan touched on is verifying that your users are in 
fact allowed to be sending mail through your server.  It may seem like 
common sense that you can't relay email through company xyz.net's SMTP 
server, but there's a couple things enforcing that.

The most common way of authenticating customers is based upon their IP.  
If company xyz.net owns 111.222.333.x/24 then they simply allow relaying 
for any client inside that subnet.  By this logic you could send a 
message from MyPersonalDomainHostedElsewhereOnTheNet.com through your 
broadband/dialup ISP's (xyz.net) email server and it would work. This is 
what Logan was suggesting in his last line there. UNFORTUNATELY there's 
a new kink in that plan.  Sender Policy Framework (SPF) is designed 
specifically to detect and stop this kind of "forgery".  It's a good 
standard and it's starting to become popular.  Because of SPF there's 
rapidly increasing likelihood that your messages would be marked as spam 
and deleted if you followed this advice.  Also some MTA's notably qmail, 
won't allow you to relay a message through if the From: field is not 
listed as an address local to that server. 

To send a message from MyPersonalDomainHostedElsewhereOnTheNet.com using 
MyPersonalDomainHostedElsewhereOnTheNet.com's SMTP Relay server you 
could authenticate the client in several ways:

The easiest is mentioned above, if you're always at a particular IP then 
add it to the allow list and be done with it.

Logan mentioned SASL ( http://asg.web.cmu.edu/sasl/ ), which while it 
would seem like a possibility is by no means the most popular method.

SMTP-Auth is supported by all major email clients, (Outlook, Outlook 
Express, Mac Mail, Thunderbird, etc..), most MTA's (qmail, sendmail, 
etc.) and is the standard way of coping with this problem.

The forth option, commonly called "SMTP after POP/IMAP" is a bit more of 
a hack in my opinion, but requires no additional configuration on the 
users end (excluding your change of port for users blocked by this 
nonsense).  The idea with SMTP after POP is that most mail clients check 
for messages before sending a message.  When a user successfully 
authenticates with your POP3 server, their IP is added to a database 
which lists valid email sources.  The IP typically stays in the database 
for 24 hours or so.  This is somewhat popular in the qmail/vpopmail 
world, although I believe there was a few sendmail folk doing it as well. 

We use defined subnets, SMTP-AUTH, and a variation of option four which 
couples the auth database with our Radius server.  All 3 co-exist 
peacefully on the same SMTP relay server.  If you have any questions 
about that specific implemention write back to cody at wilkshire.net and 
I'd be happy to help.  It was my experience that sendmail built in to 
the base of FreeBSD isn't exactly ideal for these situations as it 
generally means coupling a few programs/scripts together and sendmail 
doesn't always play nice with this in its role as part of base.  Also 
said, the ports system really shows its limits when you try to add 
options like SMTP-AUTH because matching an auth database, a qmail-smtpd 
patch, and a mess changes to startup scripts, etc.. isn't something 
ports will likely ever be able to just configure turn key, out of the box. 

Thank You,

Cody Baker
cody at wilkshire.net


Logan wrote:

>On 8/19/05, Jay Banks <jay.quest4 at gmail.com> wrote:
>  
>
>>I have sendmail and popa3d up and running. Is there any way a person could
>>offer mail service to people on ISPs that block port 25 outbound from their
>>networks?
>>    
>>
>
>Many people do.  Most use the mail submission port, 587.  Typically,
>authentication (to ensure that only their customers are relaying
>through their servers), is handled via SASL, with SSL usually thrown
>in the mix to keep from passing the auth info in plaintext.
>
>  
>
>> I have seen solutions that use different ports, but I'm not sure
>>about doing this with what I have setup on FreeBSD.
>>    
>>
>
>All the software you should need is in ports.
>
>  
>
>>I bet everyone starting to block port 25 outside of their own networks
>>really put the hurt on people offering POP3 accounts. 
>>    
>>
>
>POP3 access is a totally seperate issue.  You can send mail through a
>completey different server and/or ISP than the one you use to download
>your mail.  Your access provider should be able to handle outbound
>email for you with very little trouble. It's probably as easy as
>asking what they recommend as the outbound/smtp mailserver for you.
>
>  
>
>>I know I can't send e-mail from my own mail server or the POP3 accounts that I pay
>>money for, 
>>    
>>
>
>If your email provider isn't offering some type of authenticated
>outbound service for you, I would seriously consider changing
>providers.   It's quite simple, really.  If you want to do it with a
>mail server that you host, configure it to smarthost through your
>provider's (email OR access) server.
>_______________________________________________
>freebsd-isp at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-isp
>To unsubscribe, send any mail to "freebsd-isp-unsubscribe at freebsd.org"
>  
>