It looks like this is the line that makes the difference
I’ve not tried to simplify this yet but if you have the permissions to test you may be able to reproduce my issue
if foranyaddress $header_to:,$header_cc: ( $thisaddress matches ^robert\@elastica.com\$ )
and foranyaddress $header_from: ( $thisaddress does not match ^rss\@elastica.com\$ )
and
(
$rheader_subject: does not match \N[^\x00-\x7f]{5,}\N and
$rheader_from: does not match "\\s*=\\?(ks_c_5601-|big5|euc-|shift[-_]jis|(iso.\{0,4\}639-)|hkscs|sil|koi[78]|iscii|guobiao|gb2312|gb18030|(iso.\{0,4\}2022)|(iso.\{0,4\}8859-[57])|(windows-1251)|(windows-1255)|(windows-1256))" and
$rheader_content-type: does not match "\\s*=\\?(ks_c_5601-|big5|euc-|shift[-_]jis|(iso.\{0,4\}639-)|hkscs|sil|koi[78]|iscii|guobiao|gb2312|gb18030|(iso.\{0,4\}2022)|(iso.\{0,4\}8859-[57])|(windows-1251)|(windows-1255)|(windows-1256))" and
$rheader_subject: does not match "\\s*=\\?(ks_c_5601-|big5|euc-|shift[-_]jis|(iso.\{0,4\}639-)|hkscs|sil|koi[78]|iscii|guobiao|gb2312|gb18030|(iso.\{0,4\}2022)|(iso.\{0,4\}8859-[57])|(windows-1251)|(windows-1255)|(windows-1256))" and
$message_body: does not match ".*charset=3D(ks_c_5601-|big5|euc-|shift[-_]jis|(iso.\{0,4\}639-)|hkscs|sil|koi[78]|iscii|guobiao|gb2312|gb18030|(iso.\{0,4\}202)|(iso.\{0,4\}8859-[57])|(windows-1251)|(windows-1255)|(windows-1256))"
)
then
# logwrite "saving backup header_from $header_from: header_to $header_to:"
save $home/Maildir/.INBOX.intray.backup/
endif
This is an attempt to keep what’s put in backup limited based on the charsets etc so that backup doesn’t grow too quickly.
right now what works is just when I have
save $home/Maildir/.INBOX.intray.backup/
however an earlier rule like this one keeps complete garbage from reaching backup.
if foranyaddress $header_to: ( $thisaddress does not match ^robert\@elastica.com\$ )
and foranyaddress $header_from: ( $thisaddress does not match ^robert\@elastica.com|robert\@audrey.local\$ )
and ${domain:$header_to:} matches ^elastica.com\$
then
logwrite "junk header_from $header_from: header_to $header_to:"
seen finish
endif
> On Jun 3, 2023, at 5:50 AM, Andrew C Aitchison via Exim-users <exim-users@???> wrote:
>
> On Fri, 2 Jun 2023, Robert Nicholson via Exim-users wrote:
>
>> I’ve shrunk the .forward now and some of the problematic emails
>> started getting delivered.
>>
>> Still I don’t have root cause.
>>
>> But I’m told that the backup that you see me saving things into it’s
>> immediate but rather delayed hence the messages don’t end up there
>> either.
>>
>> The biggest contributor making this difficult to resolve is largely
>> the inability to push test data thru it without involving Admins
>> (takes time) because I don’t have the actual messages nor can I push
>> it thru end to end thru userforward etc myself as I don’t have the
>> permissions.
>
> I am a bit confused. You say that some of the problematic messages have been delivered but you don't have actual messages.
>
> Does `exim -bf ~/.forward < ... ` work in your circumstances ?
>
> --
> Andrew C. Aitchison Kendal, UK
> andrew@???
>
> --
> ## 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/
