------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=744
Summary: EXPN doesn't work under TLS
Product: Exim
Version: 4.69
Platform: Other
OS/Version: All
Status: NEW
Keywords: work:tiny
Severity: bug
Priority: medium
Component: TLS
AssignedTo: nigel@???
ReportedBy: exim-dev@???
CC: exim-dev@???
Created an attachment (id=252)
--> (
http://bugs.exim.org/attachment.cgi?id=252)
Patch against CVS HEAD to fix EXPN under TLS
The EXPN command does not work under TLS because the results of the expansion
are written directly to the output stream instead of passing through the
SSL/TLS layer.
Fixing this expanded the work scope slightly, as there's an smtp_printf()
function available but there's no guarantee that the file-descriptor for the
fprintf() in verify.c is smtp_out (and if smtp_out is even defined there, then
that's a fragile dependency). Since C doesn't let a vararg function directly
call another vararg function, I ended up turning smtp_printf() into a shim
around smtp_vprintf() which takes an ap_list parameter.
The old smtp_printf() called va_start()/va_end() twice on the same ap. Clearly
this isn't as unportable as some suggest, since nobody has complained until
now, but since I was losing the va_start() from the relevant function anyway, I
needed to use va_copy(). Alas, that's C99 and not so portable; I've made an
attempt to define an va_copy to exist as portably as I know how, but perhaps
someone has a better way to do this.
Within verify.c, the new respond_printf() is called in a couple of places where
fprintf() would do, but I decided to be consistent per line of output instead
of "this branch is only non-expn" within a line. Between major branches of
logic within the function though, I did not do this.
I also made PRINTF_FUNCTION a little more generic.
Tested on FreeBSD 6.x/amd64 with OpenSSL.
Patch is against CVS HEAD.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
