On Sat, 9 Apr 2005, Alan J. Flavell wrote:
> 550-Rejected after DATA: malformed address:
> 550-'>\n may not follow <'flavell@???:
> 550-failing address in "to" header is: <'flavell@???'>
> 550-Sorry, this is done as an anti-spam measure.
> [...and so on...]
>
> It seems that only the first line of the response is getting reported
> to the (would-be) sender
I've come to the conclusion that somewhere in the exim code (I'm not
sufficiently familiar with it to locate the spot), exim is folding
this message at white-space.
This is a dirty kludge, but if I modify the message as follows:
message = ${sg {$acl_verify_message}{ }{\xa0}}\n\
SORRYTEXT
replacing white space by no-break space, then the text of the
acl_verify_message is kept together on the first line of the
multi-line response, where there would be some prospect of the other
MTA reporting it to its benighted user, while the "sorrytext"
continues (as planned) on subsequent lines of the response, like this:
550-Rejected after DATA: malformed address: '> may not follow <'flavell@???: failing address in "to" header is: <'flavell@???'>
550-Sorry, this is done as an anti-spam measure.
[...and so on...]
Unfortunately, I don't have a tame partner who would report whether
this is any improvement from their point of view. But if I'm not
mistaken, the RFC requires that response lines which are up to 512
characters long must be supported, and this is nowhere near that
limit.
> Exim version is 4.34, I'm afraid, for reasons which aren't germane to
> this problem.
I noticed the subsequent introduction of a no_multiline_responses
control, but if I've understood its documentation, it wouldn't help
here, since I'm trying to stuff all this data into the response, but
no_multiline_responses works by throwing text away.
