Author: Steven Chamberlain Date: To: Exim-dev Subject: [exim-dev] Delivering message to Exim via SMTPS with LF instead of
CRLF, breaks DK validator
Hi,
I originally thought this was a bug in libdomainkeys but I now believe
Exim's DK validator may be at fault. The text below is mostly copied
from my libdomainkeys bug report.
The attached file is a transcript of a SMTPS (TLS) session, initiated
using 'openssl s_client -connect smtp.pyro.eu.org:smtps'. Without the
'-crlf' option, the message is received by Exim with LF (\n) instead of
CRLF (\r\n) line endings, triggering the bug. I've not yet been able to
reproduce this via standard (plain-text) SMTP.
The result of the attached TLS session, is that the message is delivered
as normal by Exim and appears normal in my MUA (Mozilla Thunderbird).
However, the DK validator (invoked by my Exim ACL) consistently appends
dk_sender with the last three characters of the message body and then a
dot (that must be the dot which terminates the SMTP 'DATA' command).
The message in the attachment was crafted to trick the DK validator into
appending '.uk.' to dk->sender. A query is made for the DomainKeys
record at 'pyro.eu.org.uk.' instead of 'pyro.eu.org', thus defeating the
'signsall' policy of 'pyro.eu.org'. Additionally, if a valid DK public
key had existed for 'pyro.eu.org.uk', then using a specially crafted
signature, the message may have wrongly passed validation.
I looked at libdomainkeys and it seems to be happy with plain LF line
endings. It's now occurred to me that it could just be the Exim DK
validator corrupting dk_sender somehow.
Regards,
--
Steven Chamberlain
steven@???
220 smtp.pyro.eu.org ESMTP Exim 4.69 Fri, 11 Jul 2008 13:12:44 +0100
mail from: <steven@???>
250 OK
rcpt to: <steven@???>
250 Accepted
data
354 Enter message, ending with "." on a line by itself
From: steven@???
To: steven@???
Subject: libdomainkeys dk->sender bug
This message will appear to the MTA and MUA to be from 'steven@???'.
However, it is delivered to the MTA with line endings of LF rather than CRLF.
When libdomainkeys parses the message headers, it wrongly appends dk->sender
with the last three characters of the message body, followed by a dot.
In this case the DK validator is tricked into thinking the email sender was
'steven@???.' and performs a DNS query for that domain's public key.
It is conceivable that the DK validator could be tricked into wrongly validating
the message.
.uk
.
250 OK id=1KHHUk-0000Rn-VN
quit
221 smtp.pyro.eu.org closing connection
