[exim] Re: exim 4.97.1 exiqgrep - line mismatch => broke mun…

Top Page
Delete this message
Reply to this message
Author: Jeremy Harris
Date:  
To: exim-users
Subject: [exim] Re: exim 4.97.1 exiqgrep - line mismatch => broke munin
On 1/12/24 08:14, Cyborg via Exim-users wrote:
> [~]# mailq
>  9h  2.2K 1rO3sE-005JbF-1D-H <> *** frozen ***
> xxxxxx@???


They need to pick up commit 1d19531abc45 at the very least:

Date:   Sun Nov 19 11:31:45 2023 +0000
     Support old-format message_id spoolfiles for mailq / -bp.  Bug 3050
     Broken-by: 46a36afae41f


If they're not willing to do that, and reissue the exim binary, a hack in the perl
of exiqgrep is feasible...

\s*(?<msgid>(?:\w{6}-\w{6}-\w{2}|\w{6}-\w{11}-\w{4}))     # old, 2023 msgid formats
becomes
\s*(?<msgid>(?:\w{6}-\w{6}-\w{2}|\w{6}-\w{11}-\w{4}))(?:-H)?     # old, 2023 msgid formats

(I've not tested this)




  9h  2.2K 1rO3sE-005JbF-1D-H <> *** frozen ***
           xxxxxx@???

> a) if the exim mailqueue is read line by line, <FROM> will be in a different line, as the rest of the issue.


If you're talking about "xxxxxx@???", that is a recipient.  The sender was <>.

b) "<> *** frozen ***" is not handled, but i'm no expert in perl regexp magic foo ;)

\s+(?<from><.*?>)     matches the <>  (though the ? is pointless, given the *)
and then " *** frozen ***" is just ignored, by this RE.  There's a specific RE
for that a few lines later.
-- 
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/