On Fri, May 9, 2014 at 3:25 AM, Cyborg <cyborg2@???> wrote:
> 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 ?
Because it aborted before it got to that point (obvious), now to track
down where it's blowing up.
> 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
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.
For those watching from the outside, remember that no log lines have a
message queue id until the data phase when it actually decides to
write out the file to the spool directory. He can't simply find log
messages by grepping for the queue id because if there is a data file
but not a header file, it's obviously in the middle of writing them
out (i.e. receiving the message headers and body from whomever is
sending it). The error _appears_ to be occurring in the middle of
writing out the files, but I've not yet found the right spot where
that happens.
> 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.
We may ask for more, thanks for debugging.
...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
