Better handling of invalid inline properties

[anonymous]

We have a few cases where the text in the body of the message matches an inline property request and email2trac exits with a non-zero exit status and the MTA bounces the email with the most unhelpful message:

<trac@trac>: Command died with status 1:
"/usr/bin/run_email2trac". Command output: saving email to
/tmp/tmpa6SfOO.email2trac writing body to /tmp/tmpbJnIAS.email2trac

If you look in the logs, you can see the python traceback from the unhandled exception:

Emailtrac: ProgrammingError:
column "dev02" of relation "ticket" does not exist
LINE 1: UPDATE ticket SET dev02='~$' WHERE id=2161

This was generated by the line:

@dev02:~$ time curl -s -

which was meant to explain the shell command being run but inadvertently attempts to set the (non-existent) dev property to '~$'.

I can think of a few ways to handle this:

1) restrict where the properties setting syntax is valid. E.G.

a few ticketing systems allow the property setting only in first set of lines of the email. As soon as a blank line is encountered, scanning for property setting is turned off. The inline_properties setting could take the values: "on", "off", "top" .... Where top means only the first blank space separated paragraph would have property parsing enabled.

2) return a better error message from the interface. IIRC

anything emitted by the delivery program to stdout will be returned in the bounce message. So catching the error and generating output like:

      line #13 of your message:

         @dev:~$ ....
      attempted to set the property dev and failed. If you
      didn't mean to set a property indent the
      line or use a character other than @ to start the line.

from email2trac (assuming an indented line can not set a property) would be most helpful.

[rouilj-trac@…]

Oops forgot to add myself as the author.