A few days ago I setup email2trac on our hosted1 system to allow for using emails to create Trac tickets for select hosted projects. At this was all working, and the setup was such that the aliases file and aliases.db for Trac projects that accept tickets were owned by apache so that the mail command /in/ the alias would be ran as apache. This was necessary because it's the apache user who has write access to the trac databases.
Sometime in the last few days this has stopped working. Mail is getting through the alias path and delivered to the email2trac command but that command is dropping it somewhere.
I could really use a second set of eyes looking at the setup with me that has more experience with postfix and aliases. Please find me on #fedora-admin as "f13". Thanks!
On Wed, 2008-05-28 at 13:00 -0400, Jesse Keating wrote:
A few days ago I setup email2trac on our hosted1 system to allow for using emails to create Trac tickets for select hosted projects. At this was all working, and the setup was such that the aliases file and aliases.db for Trac projects that accept tickets were owned by apache so that the mail command /in/ the alias would be ran as apache. This was necessary because it's the apache user who has write access to the trac databases.
Sometime in the last few days this has stopped working. Mail is getting through the alias path and delivered to the email2trac command but that command is dropping it somewhere.
I could really use a second set of eyes looking at the setup with me that has more experience with postfix and aliases. Please find me on #fedora-admin as "f13". Thanks!
And of course I just found the problem. email2trac's spam detection code is... sub par. It was seeing a 'X-Spam-Level:' header with no content and trying to split that line. Whoops. It seems to me it really needs to grok the X-Spam-Status line and find the score within. I don't necessarily have time to do that today so I've hand patched email2trac to just catch on 'X-Spam-Flag'. If any of you would like to work on a better patch please shoot it my way, I'll hold off on building email2trac for a few days.
Jesse Keating wrote:
And of course I just found the problem. email2trac's spam detection code is... sub par. It was seeing a 'X-Spam-Level:' header with no content and trying to split that line. Whoops. It seems to me it really needs to grok the X-Spam-Status line and find the score within.
Why is parsing X-Spam-Status better than counting the '*' in X-Spam-Level though? As long as the code doesn't try to split an empty field, I think it should be fine. (Unless there are cases where Spamassassin inserts X-Spam-Status and no X-Spam-Level.)
I don't necessarily have time to do that today so I've hand patched email2trac to just catch on 'X-Spam-Flag'. If any of you would like to work on a better patch please shoot it my way, I'll hold off on building email2trac for a few days.
Here[1] is something only lightly tested (outside of trac, as I have no trac install handy to test with). It might be something worth adding along with the check you've added to catch X-Spam-Flag: Yes.
[1] http://tmz.fedorapeople.org/tmp/email2trac-0.13-spamcheck.patch
infrastructure@lists.fedoraproject.org
-
Jesse Keating -
Todd Zullinger