[exim] Re: failure to transfer data from subprocess

Top Page
Delete this message
Reply to this message
Author: Robert Nicholson
Date:  
To: Jeremy Harris
CC: exim-users
Subject: [exim] Re: failure to transfer data from subprocess
Another thing I don’t quite understand with this is my .forward has something like this before the pipe

save $home/Maildir/.INBOX.intray.backup/

this is catch all to save all mail.

However when I see these errors with the SIGSEGV it’s as if the above step never completed either.

The one characteristic that’s known is that it seems the same email (when it comes back around again) consistently fails over and over whilst many others do not. I still haven’t found what the pattern is yet.

> On May 13, 2023, at 2:29 PM, Jeremy Harris via Exim-users <exim-users@???> wrote:
> 
> On 13/05/2023 19:51, Robert Nicholson via Exim-users wrote:
>> 02:19:39 13517  writing filter log as euid 1043
> 
> That tells us it came after handling a "logwrite" in a filter file...
> 
>> 02:19:39 13517   ╭considering: $header_from:
>> 02:19:39 13517   ├──expanding: $header_from:
>> 02:19:39 13517   ╰─────result: Firstname Lastname <user@???  <mailto:bbarlow@matlensilver.com>>
>> 02:19:39 13517              ╰──(tainted)
> 
> This (in fact, expanding anything the results in a tainted value)
> isn't necessarily a problem.  Using that tainted value in
> certain other contexts (basically, expanding *it* or the moral
> equivalent, such as using it for a filename) would be a problem.
> But even if you tried to do that it should *not* result in
> a null-pointer-follow.  It's a bug in Exim, even if you've managed
> to trigger it with something in your config.
> 
> The first debug snippet you showed doesn't have that expansion,
> so I'm slightly confused as to the time-sequence.
> It has
> 
>> 02:19:39 13517  writing filter log as euid 1043
> (as above)
>> 02:19:39 13517  Filter: pipe message to: nice -10 $home/perlscripts/filter.pl
> 
> That was dealing with a "pipe" command in a filter file, after
> the "logwrite" above.
> 
> Again, we don't really have a location for the null-pointer-follow.
> A coredump would be the best way of debugging.  If you want to
> avoid leaking info, then the stacktrace from a coredump ("bt" in gdb)
> would be useful (though, admittedly, a binary with debug-info would be
> best - "-ggdb" in CFLAGS).
> 
> -- 
> Cheers,
>  Jeremy
> 
> 
> -- 
> ## subscription configuration (requires account):
> ##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
> ## unsubscribe (doesn't require an account):
> ##   exim-users-unsubscribe@???
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/



--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/