Besides the obvious typo in your attempt, your example works if I put the recipe in my personal .procmailrc
.
Here's a quick demo on Ubuntu in a fresh Docker container where I installed Postfix, Procmail, and Netcat, and created a user account for myself:
tripleee@0934b6a257c9:~$ cat >.procmailrc
LOGFILE=/tmp/procmail.log
:0
* ^(X-Original-To): [email protected]
{ EXITCODE=67 HOST= }
^D
tripleee@0934b6a257c9:~$ nc localhost 25
220 0934b6a257c9 ESMTP Postfix (Ubuntu)
ehlo localhost
250-0934b6a257c9
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
mail from:<tripleee>
250 2.1.0 Ok
rcpt to:<tripleee>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
X-Original-To: [email protected]
Subject: first
who's on first
.
250 2.0.0 Ok: queued as 608C329A304
quit
221 2.0.0 Bye
^C
tripleee@0934b6a257c9:~$ cat /tmp/procmail.log
From tripleee@0934b6a257c9 Fri Mar 4 11:50:59 2022
Subject: first
Folder: 0
From MAILER-DAEMON Fri Mar 4 11:50:59 2022
Subject: Undelivered Mail Returned to Sender
Folder: /var/mail/tripleee 2267
However, the same recipe in /etc/procmailrc
causes the message to be delivered anyway; basically, HOST=
says skip the current recipe file, but in /etc/procmailrc
, that means stop reading this file and proceed to deliver to the user.
I can only speculate that that is the actual problem you are experiencing. If you have more details, please edit your question to provide them.
As an aside, the parentheses are superfluous, and the dot should be escaped.
:0
* ^X-Original-To: username@example\.com
{ EXITCODE=67 HOST= }
If you enable verbose logging with VERBOSE=yes
you'll see that Procmail actually assigns HOST=}
which is not really what I would expect, but it works (as long as your HOST
isn't really named }
!)
Notice also how the log file shows the incoming message being discarded, and then a bounce message being delivered to me (as I was the sender as well as the recipient). However, the generated bounce message includes text which (obscurely) reveals that the recipient address actually does exist after all:
<tripleee@0934b6a257c9> (expanded from <tripleee>): user unknown
You probably have to be fairly intimately familiar with Postfix bounce messages to understand exactly what this means; it basically says that it expanded tripleee
to a fully expanded email address with the domain name included, and then delivering to that produced the error message to the right of the colon. (For better or for worse, Sendmail's bounce messages are more obscure still; but the real pro of unintelligible error messages, as always, is Microsoft.)