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

Top Page
Delete this message
Reply to this message
Author: Cyborg
Date:  
To: exim-users
Subject: Re: [exim] lots of "string_sprintf expansion was longer than 32768"
Am 09.05.2014 11:58, schrieb Dave Restall - System Administrator,,,:
> Hi,
>
>> Am 09.05.2014 11:04, schrieb Dave Restall - System Administrator,,,:
>>> Hi,
>>>
>>>> Like i said, all headers are gone, and the message body looks quite
>>>> right to me.
>>>> there are a lot of attachments in the mail, but thats it.
>>> I noticed that all the spool files you listed were of the same size though
>>> you said there were lost of them. Do the files contain the same payload ?
>>>
>> with variates, yes.
> Probably a problem with the content then.
>
> What version of exim are you using ? On 4.82 the error message appears
> in string.c and acl.c, I'm not familiar enough with exim source code to
> be able to pronounce further but it could be an ACL that's failing and
> its being run early in the process - before the log file write.

Exim version 4.80.1 #2

there are no other loglines, except those string_sprintf messages .
Thats the whole point.

Why are there no other loglines where it came from, where it wanted to
be sent to ?


I have log messages in my config to see the who send it to whom:

acl_check_auth:
   ...
   warn  log_message     = send for $authenticated_id



acl_check_data:
  warn     set acl_m_fromaddress = $header_to
  log_message     = send for $acl_m_fromaddress



but none of them triggered. So it has happend before they got invoked.
Thats the only clue i can give you.



>
> Going back to the files, I'd get the content from the spool file and
> see if the error can be duplicated using the content, if it can, start
>


Before you all put too much effort in it, i can't rebuild those messages
and i can't reveal them to you,
as those messages are from a customer of mine.