left header graphic
The Network People Banner
right header graphic
   
hi
Previous:
set up a secondary MX
home : internet : mail : toaster : FAQ :
All about relaying
next:
migrating to Mail::Toaster

Relaying email messages is a primary purpose of a mail server. Thus, it is necessary to provide users with a mechanism for sending out their messages.

Historical overview of SMTP relaying

When the internet was born, there were no spammers. Thus, all the early mail servers allowed what is today known as "open relaying". This basically means that any internet connected user could use any email server to send a message to any other. That worked just fine, for a while...

As the internet grew, micreants abused the anonymous nature of these SMTP servers and soon it was common practice to only relay for IP space within your bailiwick. This worked quite well for a time. As commercial ISP's sprouted up across the country, they ended up with traveling or "roaming users". These users would connect to the internet at various locations. However, when they were connected with an IP outside the bailiwick of their email server, it would refuse to relay for them. Rather than require roaming users to constantly alter their email settings, service providers adopted the practice of employing POP before SMTP authentication.

POP before SMTP works by temporarily allowing SMTP relaying for an IP address that has successfully authenticated. This worked quite well for some number of years, but there were a few notable problems. Some email clients didn't check email before trying to send, which meant that initial attempts to send would fail, and subsequent attempts would work. There is also the remote possibility that an opened IP could be abused by a spammer after the legit user disconnected and before the IP expired. I've never had this happen to anyone I know.

The last major problem with POP before SMTP is the growth and popularity of IMAP. IMAP is a fantastic email protocol well suited to modern email usage. However, IMAP will stay connected to the server after it authenticates. Thus, it's quite common to connect to an email server via IMAP and remain connected for a number of hours or even days. During that time, the relaying ability will expire and any attempt to relay a message will fail until the user disconnects (quits their email client) and reconnects.

Because of these and other shortcoming of POP before SMTP, the current "best practice" is to provide SMTP AUTH (RFC 2554) support. SMTP AUTH allows a user to authenticate themselves to the SMTP server using their username and password credentials. SMTP AUTH is made secure through the use of TLS extensions to SMTP, allowing the email client to connect to the mail server using strong encryption.

Is my Mail::Toaster an open relay?

Most likely not. By default, the Mail::Toaster goes out of it's way to make sure that your mail server is not an open relay. This includes refusing to start SMTP daemons if any common misconfigurations are detected. The only known way to make your Mail::Toaster into an open relay is to severely misconfigure your ~vpopmail/etc/tcp.smtp file. To avoid doing this, never set RELAYCLIENT="" for any default rule.

Why can't users on blacklists use SMTP AUTH?

  • Chris writes: One thing I did not expect was for valid authenticated users to have their email rejected because the[ir IP was] on the sorbs list of dynamic IP addresses. I had assumed that authentication would bypass the RBL lists. Is that a bad assumption?

What follows is a sample qmail-smtpd invocation syntax just like what you'd find in your /service/smtp/run file. This run file is used for your smtp listener on port 25.

  • exec softlimit -m 15360000
  • tcpserver -S -H -R -c20 -x tcp.smtp.cdb -u 89 -g 89 0 smtp
  • rblsmtpd -c -r dnsbl.sorbs.net -r korea.services.net
  • -r dsn.rfc-ignorant.org -r abuse.rfc-ignorant.org -r list.dsbl.org
  • -r whois.rfc-ignorant.org -r postmaster.rfc-ignorant.org
  • -r bogusmx.rfc-ignorant.org -r relays.ordb.org
  • -r sbl-xbl.spamhaus.org -r bl.spamcop.net
  • qmail-smtpd /usr/home/vpopmail/bin/vchkpw /usr/bin/true 2>&1

Authenticated SMTP is handled by qmail-smtpd, due to the very nifty and helpful qmail patches included with Mail::Toaster. Notice exactly where in the SMTP invocation syntax the call to qmail-smtpd is. It's last. All the RBL tests are performed first, well before the SMTP daemon ever gets the connection. The reason SMTP-AUTH may not work on port 25 is because the connection is denied before the client is given the chance to authenticate. This is the design of rblsmtpd, which is used to block connections from blacklisted mail servers.

Thus, all connections to the SMTP server on port 25 from blacklisted IPs will fail, unless the user has first authenticated via POP or IMAP and roaming ips is enabled.

If I have users coming from dynamic IP addresses, do I need to disable the dynamic ip RBL?

No. You should be configuring your roaming clients to use port 587 for outgoing (smtp) email.

SMTP submission (port 587) is the modern way to allow roaming users to send email. This is good practice for several reasons. The first is that we don't run any RBLs on port 587, so you don't have to worry about whether their IP is blacklisted or not. Another reason port 587 is recommended is that many service providers block outbound connections on port 25. Also, we don't use POP before SMTP auth on port 587 as the client is required to authenticate for relaying priviliges. Other than these three differences, the SMTP daemon on port 587 is exactly the same as the one on port 25.

How exactly does roaming user support work?

If you have roaming users support enabled, after the user authenticates via POP3, their IP address is added to the vpopmail.relay table. This MySQL table is consulted for every SMTP connection by tcpserver via the MySQL patch (-S option). If their IP is in the table and hasn't expired (default entries are for 180 minutes), then tcpserver sets the RBLSMTPD and RELAYCLIENT env variable to an empty string (""). This effectively bypasses any rbl tests and allows them to relay the message.


Previous:
set up a secondary MX
home : internet : mail : toaster : FAQ :
All about relaying
next:
migrating to Mail::Toaster

Last modified on 7/11/05.