Wietse Venema:
> Noel Jones:
> > Trying out the new \c feature of smtpd_reject_footer and getting
> > unexpected behavior. While everything looks normal in the logs, the
> > sending client gets a timeout/lost connection.
> >
> > Oh, found a workaround. Add \n at the end of smtpd_reject_footer.
>
> When I tested this I needed no "extra" \n in the reply footer.
>
> All the initial \c does is to prevent *prepending* \r\n before the
> footer text; this is obvious from the code.
>
> The \c has no effect on appending the final \r\n. That decision is
> made independently, also obvious from the code.
All that is correct, but there was one more interaction between \c
and existing code, that wasn't accounted for.
Namely, don't replace the last "<reply-code> <space>" in the original
reply by "<reply-code> <hyphen>", when the reply footer starts with
\c and contains no \n.
Wietse
*** /var/tmp/postfix-2.10-20120404/src/global/smtp_reply_footer.c Fri Mar
30 20:09:02 2012
--- src/global/smtp_reply_footer.c Sat Apr 7 18:56:10 2012
***************
*** 97,102 ****
--- 97,103 ----
char *end;
ssize_t dsn_len;
int crlf_at_end = 0;
+ int last_reply_patch_offs = -1;
/*
* Sanity check.
***************
*** 115,120 ****
--- 116,122 ----
|| (cp[3] != ' ' && cp[3] != '-'))
return (-1);
cp[3] = '-';
+ last_reply_patch_offs = cp + 3 - STR(buffer);
if ((next = strstr(cp, "\r\n")) == 0) {
next = end;
break;
***************
*** 159,164 ****
--- 161,167 ----
vstring_strncat(buffer, STR(buffer) + start + 4, (int) dsn_len);
vstring_strcat(buffer, " ");
}
+ last_reply_patch_offs = -1;
}
/* Append one line of footer text. */
mac_expand(buffer, cp, MAC_EXP_FLAG_APPEND, filter, lookup, context);
***************
*** 168,173 ****
--- 171,178 ----
} else
break;
}
+ if (last_reply_patch_offs > 0)
+ STR(buffer)[last_reply_patch_offs] = ' ';
if (crlf_at_end)
vstring_strcat(buffer, "\r\n");
return (0);
