** 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.
+ 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:
-
- ```
+ 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
+ :0
/tmp/output_$MY_VAR
"
- ```
-
- 3. Create an example email file called "sample.eml" with the following
- contents:
-
- ```
- From: "Tester"
+ ```
+
+ 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
-
+ ```
+
+ 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
+ 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:
- ```
+ 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
+ :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
+ "
+ ```
+
+ 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.
+ The patch is already present in the current version of Ubuntu Stonking.
+ PPA for testing: ppa:gycsaba96/procmail-sru-lp2096676
[ 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
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:
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
--
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
