1

I am looking to do the following:

  1. User sends an email to 1234@domain
  2. Procmail recognizes 1234@domain as an email sent to ticket+1234@domain
  3. Procmail recipe handles ticket number and forwards email to the bug tracker

Where bold is my current obstacle.

Here is a proof of concept. At this point, the user still has to send the ticket to ticket+1234@domain for the email to forward correctly:

SUBJECT=`/usr/bin/formail -zx "Subject:"` :0fhw * To.*\/([0-9]+)@domain * MATCH ?? ^\/[0-9]+ |/usr/bin/formail -I "Subject: $SUBJECT (Case $MATCH)" :0 !tickets@bugtracker

Some context:

There is one address created, ticket@domain, for ticket handling. Currently, a user sends to ticket+####@domain, and the Procmail recipe uses $MATCH to grab the ticket number that correlates to the bug tracker entry and forwards accordingly. This works.

What I want to do:

Prevent auto-completion errors (a user will enter ticket+ in the recipient field, and the wrong ticket # is auto-completed). To prevent these mistakes, a user needs to send an email to ####@domain instead of ticket+####@domain.

The Big Question:

Can I use Procmail to filter emails from ####@domain to be treated as emails from ticket+####@domain?..

Improve this question
6
  • 1
    What exactly is your question? Your logic looks like it should work but perhaps I'm reading too much between the lines. Can you show the Subject: line you are trying to parse? Commented Sep 30, 2021 at 15:24
  • @tripleee My question is how do I keep users from sending tickets to ticket+####@domain and instead send to ####@domain and handle that within the procmail recipe? One thing I have been experimenting with is modifying the To: field, but I could use some direction. The Subject: line is being parsed because the bug tracker needs the Subject field to follow the format, (Case ####) for the email to forward to the correct entry in the bug tracker. Commented Sep 30, 2021 at 15:30
  • I'm not sure I understand what you mean. Procmail doesn't do any address parsing on its own, it simply processes messages which have been routed to this address by your MTA. This sounds vaguely like your actual problem is how to route these messages to Procmail in the first place ...? (Also, tangentially, relying on the To: header is not robust; think Bcc:.) Commented Sep 30, 2021 at 15:34
  • Thank you for the pointer on the To: header. I am not experiencing trouble routing these messages to Procmail; I have an address (ticket@domain) that successfully forwards emails sent as ticket+####@domain to our bug tracker for a related entry where ticket = ####. My big question: Is it possible to use Procmail to alter the name of an address format (####@domain) to an existing address (ticket@domain)? The domain host has a Procmail integration which is where I am writing these rules. If this is outside the bounds of what Procmail can do, then that will help me redirect myself. Commented Sep 30, 2021 at 15:48
  • Do you mean send to 987543@domain instead of ticket@domain? You don't need to rewrite any headers to do that; just forward to $MATCH@domain (or maybe ticket+$MATCH@domain if that's what you actually want). Commented Sep 30, 2021 at 15:49

1 Answer 1

Reset to default
0

Your question seems rather confusing, but what you are asking should be possible simply by changing the last line to !ticket+$MATCH@domain.

You should probably also use ^TO_ instead of ^To:.*.

:0 * ^TO_\/[0-9]+@domain * MATCH ?? ^\/[0-9]+ { SUBJECT=`/usr/bin/formail -zx "Subject:"` :0fhw |/usr/bin/formail -I "Subject: $SUBJECT (Case $MATCH)" :0 !ticket+$MATCH@domain }

I added braces to put the assignment and both actions under the condition, so that you don't do unnecessary work to extract the Subject: or forward anything if MATCH is not set.

(The parentheses around [0-9]+ were not doing anything useful, so I took them out. Perhaps also make sure you have a sane PATH instead of hard-coding the path to formail.)

Parsing the headers for the recipient information is not entirely robust, as the message could be sent as a Bcc:. Similarly, this assumes that the recipient system correctly examines the envelope recipient information instead of the headers (though also replacing the recipient headers before forwarding would not be very challenging to add, either).

Improve this answer
1
  • Thank you for your help. I can't upvote your answer yet. I wanted to comment to let it be known that the specific solution to my problem ended up being a separate configuration with the host. I changed the address from ticket@domain to *@domain where the asterisk acts as a wildcard allowing those ticket numbers to be entered. Perhaps this clears up some of my problem as there was a bit of a disconnect in understanding. Regardless, there was helpful information in this answer sorting out what I had in my script that was unnecessary. Commented Sep 30, 2021 at 18:37

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.