** Description changed:
+ [ Impact ]
+
+ Setting a variable with the stdin pipe action fails. Instead of using
+ the email as an input, it tries to pipe the contents of a possibly
+ undefined variable.
+
+ Users updating from 20.04 can no longer rely on their original scripts.
Having variables not set cause unexpected/unintended behavior (that can go
potentially unnoticed). This bug is already fixed in Ubuntu Stonking, so an SRU
offers a consistent experience for the users. This fix aligns with the man
pages as pointed out in the comments.
+
+ The upload would fix the issue by backporting the patch from the current
development version (stonking). It is a small patch.
+
+ [ Test Plan ]
+
+ 0. Create and use a test container.
+
+ lxc launch ubuntu:24.04 procmail-bug
+ lxc shell procmail-bug
+
+ The following steps must be performed within the test container.
+
+ 1. Install procmail.
+
+ apt update && apt install -y procmail
+
+ When asked, choose "Local only" and accept the proposed system mail name
+ ("procmail-bug.lxd").
+
+ 2. Create a test configuration called "test.procmailrc" using the buggy
+ feature:
+
+ ```
+ LOGFILE=procmail.log
+ VERBOSE=yes
+ DEFAULT=/dev/null
+
+ # Assign output of 'cat' to MY_VAR
+ :0
+ MY_VAR=| grep content
+
+ :0
+ /tmp/output_$MY_VAR
+ "
+ ```
+
+ 3. Create an example email file called "sample.eml" with the following
+ contents:
+
+ ```
+ From: "Tester"
+ To: local@localhost
+ Subject: Procmail Bug Test
+
+ good_content
+ ```
+
+ 4. Run procmail:
+
+ procmail -m test.procmailrc < sample.eml
+
+ 5. Observe the outcome
+ Unpatched outcome:
+
+ root@procmail-bug:~# cat procmail.log
+ procmail: [3010] Fri Aug 21 11:21:52 2026
+ procmail: Assigning "DEFAULT=/dev/null"
+ procmail: Assigning "MY_VAR="
+ procmail: Executing "grep,content"
+ procmail: Assigning "LASTFOLDER=/tmp/output_"
+ procmail: Opening "/tmp/output_"
+ procmail: Acquiring kernel-lock
+ Subject: Procmail Bug Test
+ Folder: /tmp/output_
79
+ root@procmail-bug:~# ls /tmp/output_*
+ /tmp/output_
+
+ Expected outcome:
+
+ root@procmail-bug:~# cat procmail.log
+ procmail: [1461] Fri Aug 21 11:41:24 2026
+ procmail: Assigning "DEFAULT=/dev/null"
+ procmail: Assigning "MY_VAR="
+ procmail: Executing "grep,content"
+ procmail: Assigning "LASTFOLDER=/tmp/output_good_content"
+ procmail: Opening "/tmp/output_good_content"
+ procmail: Acquiring kernel-lock
+ Subject: Procmail Bug Test
+ Folder: /tmp/output_good_content
78
+ root@procmail-bug:~# ls /tmp/output_*
+ /tmp/output_good_content
+
+ [ Where problems could occur ]
+
+ 1. The origin of the patch is a third party repository, and it wasn't
+ neither accepted nor rejected upstream yet.
+
+ 2. Problems could occur if someone used the current behavior as a feature.
Consider the slight modification of the example from the test plan:
+
+ The updated config:
+ ```
+ LOGFILE=procmail.log
+ VERBOSE=yes
+ DEFAULT=/dev/null
+ MY_VAR=bad_content
+
+ # Assign the output of 'grep' to MY_VAR
+ :0
+ MY_VAR=| grep content
+
+ # Write to a file depending on MY_VAR
+ :0
+ /tmp/output_$MY_VAR
+ "
+ ```
+
+ The outcome:
+ root@procmail-bug:~# procmail -m test.procmailrc < sample.eml
+ root@procmail-bug:~# cat procmail.log
+ procmail: [3093] Fri Aug 21 11:26:24 2026
+ procmail: Assigning "DEFAULT=/dev/null"
+ procmail: Assigning "MY_VAR=bad_content"
+ procmail: Assigning "MY_VAR="
+ procmail: Executing "grep,content"
+ procmail: Assigning "LASTFOLDER=/tmp/output_bad_content"
+ procmail: Opening "/tmp/output_bad_content"
+ procmail: Acquiring kernel-lock
+ Subject: Procmail Bug Test
+ Folder: /tmp/output_bad_content
+
+ Notice that /tmp/output_bad_content was used.
+
+ Since the fix is basically about the interpretation of a code, it is
+ hard to put a limit on what logic depends on this behavior and what
+ could go wrong if someone relied on this specific behavior.
+
+ [ Other Info ]
+
+ The patch is already present in the current version of Ubuntu Stonking.
+
+ [ Original Description ]
+
This procmail recipe was working in ubuntu 20.04 (procmail package
3.22-26 amd64)
:0
* ^X-Google-DKIM-Signature:
SENDER=| formail -cXFrom: | head -1 | formail -rtzxTo:
:0 af
| /usr/bin/formail -I "Message-ID:" -I "X-Gm-message-State:" -I
"X-Google-DKIM-Signature:"
:0 a
! $SENDER
It sends the incoming email back to a gmail sender stripped of certain
gmail headers.
It broke when we upgraded to ubuntu 24.04 (procmail package
3.24-1ubuntu2 amd64) sending email to foo@bar rather than the sender
which of course bounced
When failing, procmail logs messages like this: (set a LOGFILE,
VERBOSE=yes, LOGABSTRACT=yes )
procmail: Match on "^X-Google-DKIM-Signature:"
procmail: Assigning "SENDER="
procmail: Executing " formail -cXFrom: | head -1 | formail -rtzxTo:"
procmail: Executing
"/usr/bin/formail,-I,Message-ID:,-I,X-Gm-message-State:,-I,X-Google-DKIM-Signature:"
procmail: Assigning "LASTFOLDER=/usr/sbin/sendmail -oi foo@bar"
procmail: Notified comsat: "reflect@:/usr/sbin/sendmail -oi foo@bar"
From [email protected] Fri Jan 24 15:13:33 2025
- Subject: test4
- Folder: /usr/sbin/sendmail -oi foo@bar 2789
+ Subject: test4
+ Folder: /usr/sbin/sendmail -oi foo@bar 2789
procmail: Executing "/usr/sbin/sendmail,-oi,foo@bar"
(note foo and bar and certainly foo@bar do not occur anywhere in our
config and the assign SENDER= is not assigning anything to sender. My
assumption is that the foo@bar is a result of SENDER being an empty
variable.
- piping a sample email through
- formail -cXFrom: | head -1 | formail -rtzxTo:
+ piping a sample email through
+ formail -cXFrom: | head -1 | formail -rtzxTo:
on the command line correctly extracted the sender [email protected] in this
case.
I have a workaround (rewrote recipe to this:)
SENDER=`formail -cXFrom: | head -1 | formail -rtzxTo:`
:0 f
* ^X-Google-DKIM-Signature:
| /usr/bin/formail -I "Message-ID:" -I "X-Gm-message-State:" -I
"X-Google-DKIM-Signature:"
:0 a
! $SENDER
and that works.
lsb_release -rd
No LSB modules are available.
Description: Ubuntu 24.04.1 LTS
Release: 24.04
apt-cache policy procmail
procmail:
- Installed: 3.24-1ubuntu2
- Candidate: 3.24-1ubuntu2
- Version table:
- *** 3.24-1ubuntu2 500
- 500 http://us.archive.ubuntu.com/ubuntu noble/main amd64 Packages
- 100 /var/lib/dpkg/status
+ Installed: 3.24-1ubuntu2
+ Candidate: 3.24-1ubuntu2
+ Version table:
+ *** 3.24-1ubuntu2 500
+ 500 http://us.archive.ubuntu.com/ubuntu noble/main amd64 Packages
+ 100 /var/lib/dpkg/status
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2096676
Title:
procmail =| action assignment not working
To manage notifications about this bug go to:
https://bugs.launchpad.net/procmail/+bug/2096676/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
