Add support for ticket-specific email addresses via wildcards

[eu@…]

Currently, there is one e-mail address and bug # (and other information) is parsed from the subject field. It would be nice also to support the configuration of wildcard e-mail addresses, one address per issue, like bug243-trac@domain or 243@bugs.domain and such (configured via format string, and via wildcards in the MTA config). (The subject field would be perhaps added on the top of the comment, or discarded)

It would be easier to cc bug mails (to someone not on trac, and to trac itself), without requiring some particular subject text, and the conversation could seamlessly happen over e-mail and web combined.

Notification about ticket changes could be sent with the sender's address Diplayed User Name <234@bugs.domain> (this is what launchpad does), or with the reply-to field modified accordingly.

[bas]

Interesting idea.

[bas]

Do you know how to setup the MTA for this kind of setup?

[eu@…]

For exim at least, the router would accept some wildcard address (see e.g. ​http://www.datadisk.co.uk/html_docs/exim/generic_router_options.htm).

I thought, as a quick hack before this would be handled at email2trac level, that the message would be consumed by an intermediate script, which would parse the To: part, rewrite the subject line (e.g. prepend #123:) and the pipe it further down to email2trac, which would get the ticket number from the subject field as usual.

The notification part could be (probably) handled by ​AnnouncerPlugin, so notification for each ticket/wiki page etc would have the From: set to that special address.

[bas]

I just found the settings for postfix and have set the:

• recipient_delimiter = +

Now i can receive emails has email2trac+123@…. As you said i can parse this a ticket number: 123. Thanks for the suggestion. I have to find out how to set the reply-to/From address. I will take a lookk at the AnnouncerPlugin?.

[anonymous]

The most flexible would be to have email2trac accept options like --ticket=... and so on, which would switch off subject parsing, and provide in the disitrbution some sample scripts for doing the parse and calling email2trac which admins would only adjust for their needs.

I added ​ticket to AnnouncerPlugin to support generated sender's address.

[bas]

I can easily add an option --ticket. Do you want to parse the email address and then call email2trac with this option? I also like the email_adress+ticket_id approach.

With example scripts you mean how to setup your MTA, eg postfix, exim.

[eu@…]

Example scripts: I meant parsing the From: address and calling email2trac with appropriate options afterwards. It is unlikely there will be a one size fits all solution: you like address+number@..., I would prefer number@... for instance, and other sites might need still something else.

Such a script, possibly locally adapted, would call email2trac and pipe it the rest of its input. I will try to cook something up.

[bas]

Replying to eu@…:

Example scripts: I meant parsing the From: address and calling email2trac with appropriate options afterwards. It is unlikely there will be a one size fits all solution: you like address+number@..., I would prefer number@... for instance, and other sites might need still something else.

Such a script, possibly locally adapted, would call email2trac and pipe it the rest of its input. I will try to cook something up.

Did you succeed?

For the address + id i am using this code:

      ## Some code for email + ticket id
      #
      try:
          print self.parameters.project_name
          print 'Delivered To', m['Delivered-To']
          print self.parameters.to_parse_address_delimiter
          id = m['Delivered-To'].split(self.parameters.to_parse_address_delimiter)[1]
          print id
          id = id.split('@')[0]
          print id

       except KeyError, detail:
           pass

[bas]

Replying to eu@…:

Example scripts: I meant parsing the From: address and calling email2trac with appropriate options afterwards. It is unlikely there will be a one size fits all solution: you like address+number@..., I would prefer number@... for instance, and other sites might need still something else.

Such a script, possibly locally adapted, would call email2trac and pipe it the rest of its input. I will try to cook something up.

any progress?

[bas]

In 631:

We can now support name+id@… addresses:

• recipient_delimiter: +

wrote a simple notication function that sets the reply to field of a mail to: name+id@…

• notification_replyto_rewrite: 1

For each bug there will be an uniqye address

Still some work to be done:

see #297

[bas]

In 633:

rewrote notification system for email2trac: see #266, #297

I have defined my own TicketNotifyEmail? class: Email2TracNotifyEmail. Now it easy to implemenent:

• notify_reporter
• notify_replyto_rewrite

notify_replyto_rewrite can handle 2 formats for email2trac.conf

• use_mail_domain:email2trac.surfsara.nl
  • the replyto field will be set to <ticket_id>@email2trac.surfsara.nl
• use_trac_smtp_replyto:+
  • Will use the setting in trac.ini for smtp_replto and use '+' as recipient delimiter eg: smtp_replyto: email2trac@… then reply_to will be: email2trac+<ticket_id>@surfsara.nl

[bas]

Can you test it? Both formats are supported.

[bas]

Thanks to Peter Suter for the announcer code example. I just rewrote it and it can sets the reply_to address. see:

• ​https://trac-hacks.org/ticket/10044#comment:5

[szybalski@…]

I've being able to setup procmail to forward subdomain 12345@… to incoming@… and subject line #12345:

​http://lucasmanual.com/mywiki/procmail

This allows you to use existing email2trac functionality just by including the bug # in the subject line. The only thing left is setting up the incoming@… using existing email2trac documentation.

[bas]

Replying to szybalski@…:

I've being able to setup procmail to forward subdomain 12345@… to incoming@… and subject line #12345:

​http://lucasmanual.com/mywiki/procmail

This allows you to use existing email2trac functionality just by including the bug # in the subject line. The only thing left is setting up the incoming@… using existing email2trac documentation.

Thanks for your documentation on this subject!!

[bas]

Did some optimization for email2trac wildcard support see:

• Change [671]