I was troubleshooting a strange problem recently. A brand new Nokia E61i smartphone could receive but not send any e-mail. The server configuration has not changed and other mail clients are working fine, so it must be the server.

It is very basic and straightforward configuration – a FreeBSD server running Qmail with SPAMCONTROL patch as SMTP server and BincIMAP as IMAP4 server. This configuration worked perfectly until the client asked to add this shiny new Nokia phone to the mix.

Receiving e-mail via IMAP4 did not pose any problems – it just worked (sans the self-signed SSL certificate which I figured out later) but sending mail via SMTP protocol just did not work at all.

The server requires SSL-encrypted connection and successful SMTP authentication before allowing relaying mail to non-local recipients. My initial thought was that perhaps it was due some mismatch in supported encryption algorithms (SHA vs DES vs 3DES, that type of thing). After tweaking the settings a lot on the server side, and even completely disabling SSL encryption altogether I realized it is not the culprit here.

So I have enabled verbose SMTP protocol logging and this is what I saw:

2007-08-16_12:04:16.53449 53365 > 220 server.example.com ESMTP
2007-08-16_12:04:16.55913 53365 < EHLO [xx.xx.xx.198]
2007-08-16_12:04:16.55935 53365 > 250-server.example.com
2007-08-16_12:04:16.55940 53365 > 250-PIPELINING
2007-08-16_12:04:16.55949 53365 > 250-8BITMIME
2007-08-16_12:04:16.55957 53365 > 250-SIZE 0
2007-08-16_12:04:16.55966 53365 > 250 AUTH LOGIN PLAIN
2007-08-16_12:04:16.58764 53365 < AUTH LOGIN
[SMTP authentication details snipped]
2007-08-16_12:04:16.60694 Accept::ORIG::Valid_Auth: P:EMSTPA
     S:xx.xx.xx.198:unknown H:[xx.xx.xx.198] 'login' ?= 'valid_user'
2007-08-16_12:04:16.60707 53365 > 235 ok, go ahead (#2.0.0)

As you see from this log excerpt, an SMTP session has been successfully established, SMTP client has successfully authenticated to the server and the server now ready start accepting e-mails from this client.

Everything looks perfect up to this point – see what happens next:

2007-08-16_12:04:16.76834 53365 < RSET
2007-08-16_12:04:16.76857 53365 > 250 flushed

What on Earth the developers have been smoking? Why reset an SMTP connection right after the authentication? Have they read RFC-822 yet?

So, let us continue with our example:

2007-08-16_12:04:16.77749 53365 < MAIL FROM:<valid_user@example.com>
2007-08-16_12:04:16.77787 53365 > 250 ok
2007-08-16_12:04:16.82899 53365 < RCPT TO:<someone@example.org> 
2007-08-16_12:04:16.82908 Reject::ORIG::Missing_Auth: P:ESMTPA
     S:xx.xx.xx.198:unknown H:[xx.xx.xx.198]
     F:valid_user@example.com T:someone@example.org
2007-08-16_12:04:16.82922 53365 > 535 authentication required (#5.7.1)

Of course – authentication is indeed required to send e-mail to external recipients (otherwise it would simply be an open relay). No wonder the SMTP server (rightfully!) rejects the attempt and closes the connection:

2007-08-16_12:04:16.85379 53365 < QUIT
2007-08-16_12:04:16.85433 53365 > 221 server.example.com
2007-08-16_12:04:16.85445 53365 > [EOF] 

Luckily, Qmail is an open-source software, so I was able to make a trivial modification in the qmail-smtpd.c sources:

--- qmail-smtpd.c.bak   Fri Aug 24 20:32:39 2007
+++ qmail-smtpd.c       Thu Aug 16 16:18:50 2007
@@ -784,7 +784,7 @@
 }
 void smtp_rset()
 {
-  seenmail = 0; rcptcount = 0; seenauth = 0; seenttls = 0;
+  seenmail = 0; rcptcount = 0; /* seenauth = 0; seenttls = 0; */
   mailfrom.len = 0; rcptto.len = 0; tlsinfo.len = 0;
   out("250 flushed\r\n");
 }

This is essentially makes RSET command a no-op when it comes to SMTP authentication.This solved the problem for me – my client is now able to send e-mail messages in addition to just receiving them.

Still – bad developer, no cookie…