Re: [exim] lots of "string_sprintf expansion was longer than…

I wasn't able to reproduce your particular scenario, however I have
added some extra output to the error message. It will print out the
format string that was passed to it. The intention is to provide
better debugging info so future occurrences of this error will
somewhat more clearly indicate the calling code. After the release of
4.83, it should be easier to track down where this is coming from.

...Todd


On Fri, May 9, 2014 at 10:13 AM, Todd Lyons <tlyons@???> wrote:
> On Fri, May 9, 2014 at 8:17 AM, Cyborg <cyborg2@???> wrote:
>>
>>> Can you convert the "log_message" to "logwrite" and see if it gives
>>> out more information? This will only be useful if this is in fact an
>>> authenticated sender. Do you also have a connect ACL? If yes, do you
>>> have any log_message statements there? If yes, can you convert those
>>> to logwrite statements? If no, can you add that connect ACL and add
>>> some logging? Try log_message first, falling back to logwrite if
>>> necessary.
>> I could, i don't think that will help. Those problems happend 2 weeks ago
>> and did not happen again.
>
> Ah that's an important detail that I must have overlooked in your
> original message.
>
>> It must be a problem with those specific messages.
>> What i can tell from the spool file, it was written completly, before the
>> error occured.
>
> Right, and it's just the message body spool file. The header spool
> file is not present, so that suggests that the error was somewhere in
> the vicinity of generating the header spool file contents. But I
> can't be more specific than that just yet.
>
> I think the best solution at this point is to at least print out what
> the format string that got passed to the string_sprintf() function
> was, and maybe the number of args. In the future, that would at least
> help narrow the search.
>
>>> By the way, do you have cut-through routing enabled? I don't know if
>>> that even makes a difference, but am trying to understand your
>>> configuration and thus its behavior.
>> What you mean with "cut-through routing" ?
>
> Ok, that means no.
>
> Thanks!
>
> ...Todd
> --
> The total budget at all receivers for solving senders' problems is $0.
> If you want them to accept your mail and manage it the way you want,
> send it the way the spec says to. --John Levine



--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine