[exim] Re: smtp_accept_max & DDoS

[Cyborg via Exim-users]

Am 12.05.23 um 17:23 schrieb Slavko via Exim-users:

Dňa 12. mája 2023 14:36:23 UTC používateľ Jeremy Harris via Exim-users 
 napísal:


Your short setting for smtp_receive_timeout is probably the best
way (despite violating standards).

IMO that standars violating is not true, RFC 6409 allows shorting
SMTP timeouts for MSA, it doesn't strictly defines them, only
suggests 2-5 mins...

Anyway, thanks for suggestions ;-)

regards




It's easy to detect if someone if blocking your exim:

Loop over :

1. Getting all ID-Tripples

netstat -lnap | grep exim | grep HERE>   | awk '{print $5":"$7;}' | sed -e "s/\/exim//g"


87.123.20.215:36858:1127858
87.123.20.215:36834:1127839
87.123.20.215:36844:1127849

You now have the identifing tripple, it's highly unlikely, next to 
impossible to get the same tripple of ip:port:processid again.


2. Check them against a HASH with the tripple as key and a timestamp as 
value


3. if tripple is not in hash , put in with now() as timestamp
    if tripple is in hash, check if timestamp is xxx seconds old, end 
exim with "kill $pid" and "iptables -A smtpattacker -s $IP -j DROP"


4. if you find tripples in the hash, that are not in the actual set of 
tripples from step 1 , remove them from hash.


5. Sleep 10s

End Loop

I suggest to choose your timeout for the kill wisely, as some servers 
send a big chunk of data slow as hell, but a reasonable amount would be 30s.
In addition, the netstat output could give out, if any data is in the 
connection buffer as an indicator that the host as send real data as an 
indication for a valid connection attempt.



best regards,
Marius

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

[exim] Re: smtp_accept_max & DDoS

[Andrew C Aitchison via Exim-users]

7On Sat, 13 May 2023, Cyborg via Exim-users wrote:


It's easy to detect if someone if blocking your exim:

Loop over :

1. Getting all ID-Tripples

netstat -lnap | grep exim | grep HERE>   | awk '{print $5":"$7;}' | sed -e "s/\/exim//g"


87.123.20.215:36858:1127858
87.123.20.215:36834:1127839
87.123.20.215:36844:1127849

You now have the identifing tripple, it's highly unlikely, next to 
impossible to get the same tripple of ip:port:processid again.


I think those three values are all available within exim.
Since the issue is after a failed auth, can you do something
with them after an appropriate test in the auth acl ?
Possibilities include:
1. logging, and having a reaper daemon watching the logs
  and killing any of these processes that survive a delay.
2. using ${run} or exim's perl process to start a script
  which delays snd then kills the pid.

2. Check them against a HASH with the tripple as key and a timestamp as 
value


3. if tripple is not in hash , put in with now() as timestamp
    if tripple is in hash, check if timestamp is xxx seconds old, end exim 
with "kill $pid" and "iptables -A smtpattacker -s $IP -j DROP"


4. if you find tripples in the hash, that are not in the actual set of 
tripples from step 1 , remove them from hash.


5. Sleep 10s

End Loop

I suggest to choose your timeout for the kill wisely, as some servers send 
a big chunk of data slow as hell, but a reasonable amount would be 30s.
In addition, the netstat output could give out, if any data is in the 
connection buffer as an indicator that the host as send real data as an 
indication for a valid connection attempt.


By logging or triggering this in an ACL and only when the problem occurs
we avoid the case of slow but valid incoming connections.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk

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

[exim] Re: smtp_accept_max & DDoS

[Cyborg via Exim-users]

Am 13.05.23 um 11:41 schrieb Andrew C Aitchison:


I suggest to choose your timeout for the kill wisely, as some servers 
send a big chunk of data slow as hell, but a reasonable amount would 
be 30s.
In addition, the netstat output could give out, if any data is in the 
connection buffer as an indicator that the host as send real data as 
an indication for a valid connection attempt.


By logging or triggering this in an ACL and only when the problem occurs
we avoid the case of slow but valid incoming connections.




I'm afraid, you can only test things in an acl, IF new connections are 
coming in, which the DDOS open-connection-attack would deny.


This needs to be external, or it's useless when you need it :)

Best regards,
Marius

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

[exim] Re: smtp_accept_max & DDoS

[Slavko via Exim-users]

Dňa 13. mája 2023 8:50:26 UTC používateľ Cyborg via Exim-users 
 napísal:

>I suggest to choose your timeout for the kill wisely, as some servers send a 
>big chunk of data slow as hell, but a reasonable amount would be 30s.

As i have separate MSA, would not be more easy to setup
that timeout right in exim? Will not this have the same effect?...

As there is AuthPolicy daemon in action, filling FW is done
by fail2ban parsing its logs. That allow me distinguish
auth rejection reason in more precise way than simple
success/fail in exim, beside the fact, that fail2ban
provides repeat counting, ban persistance -- and unban
of course (as many of them seems to be end users, from
time to time cleaned infection and/or changed IP).

regards


-- 
Slavko
https://www.slavino.sk/

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

[exim] Re: smtp_accept_max & DDoS

[Andrew C Aitchison via Exim-users]

On Sat, 13 May 2023, Slavko via Exim-users wrote:


Dňa 13. mája 2023 8:50:26 UTC používateľ Cyborg via Exim-users 
 napísal:


I suggest to choose your timeout for the kill wisely, as some servers send a 
big chunk of data slow as hell, but a reasonable amount would be 30s.


As i have separate MSA, would not be more easy to setup
that timeout right in exim? Will not this have the same effect?...


I don't think we can do the kill from within exim.
We may be able to get exim to fork a process that waits and then kills the 
stuck process, but once it it stuck a process cannot kill itself.


If we can reduce
smtp_receive_timeout
in the auth acl and increase it again in the data acl,
will that stop the process getting stuck ?

I would still like to know where the delay is actually happening;
currently I guess it is somewhere in the authentication.
In the simplest case the username and credentials (password)
are included in the request and the data is local, so there is no
potential for delay and hence no timeout option for authentication
(that I can find), but challenge-response and using the dovecot 
authenticator both introduce conversations which could cause delays

and require timeouts.
Are you using the dovecot authenticator ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk

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

[exim] Re: smtp_accept_max & DDoS

[Slavko via Exim-users]

Dňa 12. mája 2023 14:36:23 UTC používateľ Jeremy Harris via Exim-users 
 napísal:

>Indeed, with the dovecot authenticator and that version of Exim
>I don't think there's anything special you can do if you can't
>fingerprint these connections in some way.

I did simplifíed adaption of python dovecot's SASL client
(available on PyPi) to do auth over unix socket and when
AuthPolicy rejects authentication, dovecot returns reason
from it in "reason" arg. If authentication fails (i tested
nonexistent user), the reason is not in response at all.

Thus exim can get it, but does it that? I guess that it doesn't
do that, perhaps because its AuthPolicy is relative new and
not widely used...

regards


-- 
Slavko
https://www.slavino.sk/

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

[exim] Re: smtp_accept_max & DDoS

[Jeremy Harris via Exim-users]

On 13/05/2023 12:55, Andrew C Aitchison via Exim-users wrote:

I would still like to know where the delay is actually happening;
currently I guess it is somewhere in the authentication.


No, the client has tried an auth command which we responded "fail"
to, and then the client abandoned the TCP connection without
bothering to close it (let alone QUIT the SMTP layer session,
or (I expect) properly terminate the TLS session).
Because that's the cheap thing for an attacher to do.
Meantime, we're waiting for the next SMTP connand from the
client, because per SMTP standards the ball is in their court.

The delay is our SMTP command timeout.  It is currently our
way of detecting this behaviour.

We could
- manipulate the SMTP command timeout, as you suggest
- run a shorter TCP keepalive probe delay.   When it fires,
  we hope to get a RST back from our first probe, assuming
  a normal TCP stack at their end.  But they could be running
  a custom, so also reduce the number of probe tries before
  we declare the TCP connection dead.
- Unilaterally send some probe data, again to try to elicit
  a RST.  This would be violating the SMTP protocol.
  Perhaps a 421 SMTP response?
- Somehow exempt cnnection in this state from the
  smtp_accept_max counting
--
Cheers,
  Jeremy

I wish there was an IOCTL to send a keepalive probe.


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

[exim] Re: smtp_accept_max & DDoS

[Slavko via Exim-users]

Dňa 13. mája 2023 11:55:36 UTC používateľ Andrew C Aitchison via Exim-users 
 napísal:

>I don't think we can do the kill from within exim.

But is that needed? When timeout happens, socket is closed
and process ends.

>We may be able to get exim to fork a process that waits and then kills the 
>stuck process, but once it it stuck a process cannot kill itself.

IMO when process stucks, that must be bug, the timeouts are
generally supposed to prevent processes to remain running
forever. Othervise we will have serious problem, as
connections can be lost in normal conditions too, especially
with nowadays as common mobile devices...

>I would still like to know where the delay is actually happening;

In my case, for "suspicious" connections i apply small delay
on every command. In case of normal auth it is in connect
ACL, HELO ACL and AUTH ACL (conditionaly based on
connections count).

Then delay happens on dovecot side, first is not explicit
delay, but AuthPolicy processing, where eg. DNS queries
can delay result, i have configured 6 sec timeout for response,
but almost all are finished under 4 secs, with 95 percentil
in hundreds milisecs. Then dovecot penalty happens if no
nopenalty (or so) arg was passed (which seems to be exim's
case, as i see 2 sec delay betveen lines in dovecot & exim
log lines). These dovecot's delays are always here if auth
fails...

Of course, AuthPolicy deamon can return reply with
explicit delay, but i don't use that.

As most of discussed connections are recognized as
"suspicious" and its count is not too high yet, the connection
tooks at least 8 sec until it gets failed auth response...

If connection is not suspicious and auth was success,
that tooks only some hundreds msecs in most cases,
including DNS queries and password hashing.

regards


-- 
Slavko
https://www.slavino.sk/

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

[exim] Re: smtp_accept_max & DDoS

[Lena--- via Exim-users]

Please create DNS records instead of CNAME:

lists.exim.org. 300 IN MX 10 lists.exim.org.
lists.exim.org. 300 IN A 37.120.190.30

Or accept emails to lists sent to  .

Else some people trying to post to lists get "unknown user"
because sendmail "canonicalises" hostnames.

> From: Andrew C Aitchison

> If we can reduce
>   smtp_receive_timeout
> in the auth acl and increase it again in the data acl,
> will that stop the process getting stuck ?

smtp_receive_timeout is expanded in smtp_setup_msg function in smtp_in.c
at the start of a SMTP session.

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

[exim] Re: smtp_accept_max & DDoS

[Jeremy Harris via Exim-users]

On 13/05/2023 14:03, Jeremy Harris via Exim-users wrote:

We could
- manipulate the SMTP command timeout, as you suggest


It turns out to be not much code to add an ACL control
which modifies the timeout.  Would that be of use for
this case, and is it worth the feature-creep?

The docs entry goes:

 This control changes the current values for receive timeout,
 originally set by the &%smtp_receive_timeout%& or &%receive_timeout%&
 main config option (or commandline equivalents).
 Both values are changed, for the current receive process
 (which could handle multiple messages off a single connection, if SMTP).

--
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-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] Re: failure to transfer data from subprocess

[Robert Nicholson via Exim-users]

Here is some feedback I received from support for the host I’m using.

I’m not quite sure I follow the significant of what they are pointing out and 
also it doesn’t look like I have the ability to debug exim myself

The claim below is that it’s my pipe to the perlscript that causes the issues.

Sure, but what does the whole tainted thing have to do with it?

02:19:39 13517  Condition is false: $header_from: matches r...@mydomain.com 

02:19:39 13517   ╭considering: $tod_full running with sa $header_from: to 
$header_to:
02:19:39 13517   
02:19:39 13517   ├considering:  running with sa $header_from: to $header_to:
02:19:39 13517   
02:19:39 13517   ├───text:  running with sa 
02:19:39 13517   ├considering: $header_from: to $header_to:
02:19:39 13517   
02:19:39 13517   ├considering:  to $header_to:
02:19:39 13517   
02:19:39 13517   ├───text:  to 
02:19:39 13517   ├considering: $header_to:
02:19:39 13517   
02:19:39 13517   ├considering: 
02:19:39 13517   
02:19:39 13517   ├───text: 
02:19:39 13517   
02:19:39 13517   ├──expanding: $tod_full running with sa $header_from: to 
$header_to:
02:19:39 13517   
02:19:39 13517   ╰─result: Fri, 12 May 2023 02:19:39 -0700 running with sa 
Firstname Lastname mailto:bbar...@matlensilver.com>> to 
m...@mydomain.com 
02:19:39 13517   
02:19:39 13517  ╰──(tainted)
02:19:39 13517  writing filter log as euid 1043
02:19:39 13517  Filter: pipe message to: nice -10 $home/perlscripts/filter.pl
02:19:39 13517 LOG: MAIN PANIC
02:19:39 13517   SIGSEGV (fault address: (nil))


as it's basically pipe tu custom extension which is not provided by DA it's not 
considered as direct exim issue, as it plain simply not parsing correctly.
 
You can debug variables passed and hot it's processed and guess where it's 
failing using debug devilry of failing message using etc.:
exim -d+all -M 1pwiuk-0008E9-06

Just a hint:
39 13517   ╰─result: sending message 1pwiuk-0008E9-06 from Firstname 
Lastname mailto:bbar...@matlensilver.com>> to 
m...@mydomain.com  to pipe
02:19:39 13517   
02:19:39 13517  ╰──(tainted)
02:19:39 13517  writing filter log as euid 1043
02:19:39 13517   ╭considering: $header_from:
02:19:39 13517   ├──expanding: $header_from:
02:19:39 13517   ╰─result: Firstname Lastname mailto:bbar...@matlensilver.com>>
02:19:39 13517  ╰──(tainted)

which can be a new thing for custom filter in relation to exim changes and how 
client provided input is treated(basically less/no trust is given):
 
https://github.com/Exim/exim/blob/master/doc/doc-txt/ChangeLog
"JH/25 Taint-check exec arguments for transport-initiated external processes.
  Previously, tainted values could be used.  This affects "pipe", "lmtp" and
  "queryprogram" transport, transport-filter, and ETRN commands.
  The ${run} expansion is also affected: in "preexpand" mode no part of
  the command line may be tainted, in default mode the executable name
  may not be tainted.”

exim -bV
Exim version 4.96-58-g4e9ed49f8 #2 built 07-Jan-2023 06:47:04
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2022
Berkeley DB: Berkeley DB 5.3.21: (May 11, 2012)
Support for: crypteq IPv6 Perl OpenSSL TLS_resume move_frozen_messages 
Content_Scanning DKIM DNSSEC Event OCSP PIPECONNECT PRDR Queue_Ramp SPF SRS 
TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb
Authenticators: cram_md5 dovecot plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb aveserver fsecure kavdaemon sophie clamd mksd 
avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
2023-05-12 02:30:58 cwd=/var/log/exim 2 args: exim -bV
Configuration file is /etc/exim.conf

-

> On May 10, 2023, at 5:31 PM, Robert Nicholson via Exim-users 
>  wrote:
> 
> To answer this question my ISP uses DirectAdmin and I believe exim is 
> packaged with that.
> 
>> On May 10, 2023, at 6:52 AM, Jeremy Harris via Exim-users 
>>  wrote:
>> 
>> 
>> On 10/05/2023 12:02, Robert Nicholson via Exim-users wrote:
>>> Exim version 4.96-58-g4e9ed49f8 #2 built 07-Jan-2023 06:47:04
>> 
>> Who built it?  What is the provenance of the sourcecode?
>> 
>>> mainlog:2023-05-09 13:49:51 1pwUHO-0005xx-1O SIGSEGV (null pointer 
>>> indirection)
>> 
>> Definitely a bug; you should not be able to induce this by doing
>> something odd in a .forward.
>> 
>> For debugging it, it'd help if you could provide the matching .forward
>> rule (if there is indeed one), and even more if you could get a coredump.
>> 
>> The "failure to transfer data" log is a follow-on resulting from
>> the transport process dying (and not providing data) not ignore that.
>> 
>> Is the message successfully deli

[exim] Re: smtp_accept_max & DDoS

[Slavko via Exim-users]

Dňa 13. mája 2023 18:01:43 UTC používateľ Jeremy Harris via Exim-users 
 napísal:
>On 13/05/2023 14:03, Jeremy Harris via Exim-users wrote:
>> We could
>> - manipulate the SMTP command timeout, as you suggest
>
>It turns out to be not much code to add an ACL control
>which modifies the timeout.  Would that be of use for
>this case, and is it worth the feature-creep?

I can imagine how one can use it, eg. i would add it into
ACL where i disable pipeline on MX in some conditions.
I can imagine, that control as useful in some reject
conditions too.

But in the case of failed auth we are back in problem
processing of that failed auth in dovecot autenticator.
When i will know, that host is bad (and sometime i know
that) i will reject/drop it before it reach aurh. I am not
sure if i want to set it on suspicious connections, as these
can be not bad in real and be on bad connection/link.

IMO great can be, if something as this would be
autenticator option, in mean of set timeout in
failed auth case, ideally expandable...

Or can this control be set from failed auth event
named ACL?

regards


-- 
Slavko
https://www.slavino.sk/

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

[exim] Re: failure to transfer data from subprocess

[Jeremy Harris via Exim-users]

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 mailto:bbar...@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-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] Re: smtp_accept_max & DDoS

[Jeremy Harris via Exim-users]

On 13/05/2023 20:24, Slavko via Exim-users wrote:

Or can this control be set from failed auth event
named ACL?

Yes.
--
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-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] Re: smtp_accept_max & DDoS

[Slavko via Exim-users]

Dňa 13. mája 2023 19:59:24 UTC používateľ Jeremy Harris via Exim-users 
 napísal:
>On 13/05/2023 20:24, Slavko via Exim-users wrote:
>> Or can this control be set from failed auth event
>> named ACL?
>Yes.

nice ;-)



-- 
Slavko
https://www.slavino.sk/

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

[exim] Re: failure to transfer data from subprocess

[Robert Nicholson via Exim-users]

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 
>  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 > >
>> 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-unsubscr...@lists.exim.org
> ## 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-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] Re: failure to transfer data from subprocess

[Jeremy Harris via Exim-users]

On 13/05/2023 21:42, Robert Nicholson via Exim-users wrote:

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 "save" command only sets up another delivery to be done for the message
(to file) - it's doesn't perform that delivery.  The crash is before
we get to that delivery being actioned.


[  Exim version 4.96 will be doing it's best to give a stackdump
   of itself, on a SIGSEGV, to the logfiles.  I assume you're
   running something a bit earlier.
]

--
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-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/