Bug#240256: Consistent error in sending SMTP mail in 8-bit mode
Package: kmail
Version: 4:3.2.1-1
I have spent a large amount of time debugging the problem mentioned
in bug 240256. In fact, I have looked through the kmail (kdepim)
and kio_smtp (kdebase) source code.
The problem is not with KMail. It is not technically even with
kio_slave. The real problem lies somewhere between the server and
kio_slave. Allow me to explain.
Version 3.2.1 of kio_smtp now checks the EHLO capabilities of the
SMTP server. If you "telnet your-smtp-server smtp" and type in
something like "EHLO your-machine-name", you should get a whole list
of capabilities back, each starting with the string "250".
The problem is that kio_smtp now checks for the capability
"8BITMIME" to determine whether the server supports this facility or
not. The real problem is that many servers DO sort-of support this
facility, but do not advertise it. Hence, kio_smtp does not see
"8BITMIME" and thinks that the e-mail server cannot handle it.
The solution is to either:
1. Hack kio_smtp to send 8-bit e-mails, whether or not the server
advertises this clause, or
2. Change your e-mail server.
Point 1 is not really a viable option. Point 2 is not much easier!
I run the Exim server (v3, as it happens, on a Debian stable box).
The appropriate option to modify in /etc/exim/exim.conf is:
accept_8bitmime = true
Please read the warning associated with this option, right there in
the config file. The Exim 4 documentation states:
This option causes Exim to send 8BITMIME in its response to an
SMTP EHLO command, and to accept the BODY= parameter on MAIL
commands. However, though Exim is 8-bit clean, it is not a
protocol converter, and it takes no steps to do anything special
with messages received by this route. Consequently, this option
is turned off by default.
You have a problem if you (a) don't control the SMTP server and (b)
need to send 8-bit non-quoted-printable e-mails. In that case, you
may want to add the following (not recommended!) patch to the file
kioslave/smtp/smtp.cc in the kdebase package:
--- smtp.cc.orig 2004-02-08 23:28:03.000000000 +1100
+++ smtp.cc 2004-04-16 20:18:16.000000000 +1000
@@ -230,6 +230,8 @@
return;
}
+/* Always assume the SMTP server has 8-bit capabilities. This is a hack!
+
if ( request.is8BitBody()
&& !haveCapability("8BITMIME") && metaData("8bitmime") != "on" ) {
error( KIO::ERR_SERVICE_NOT_AVAILABLE,
@@ -237,6 +239,7 @@
"Please use base64 or quoted-printable encoding.") );
return;
}
+*/
queueCommand( new MailFromCommand( this, request.fromAddress().latin1(),
request.is8BitBody(), request.size() ) );
Finally, I have also notified KDE bug 77058. Someone there DID have
a brief one-line comment that would have suggested the solution, if
I had but looked at it a little more closely!
PS: I (and others) made the assertion that KMail never even
connected to the server. This was wrong: it DOES connect, issues an
EHLO command, then gives up. It is just that Exim does not log this
by default.
Yours truly,
John Zaitseff
--
John Zaitseff ,--_|\ The ZAP Group
Phone: +61 2 9643 7737 / \ Sydney, Australia
E-mail: J.Zaitseff@zap.org.au \_,--._* http://www.zap.org.au/
Finger: john@zap.org.au v
GnuPG fingerprint: 8FD2 8962 7768 2546 FE07 DE7C 61A8 4486 C9A6 69B0
Reply to: