mainSavannah Administration - Support: sr #106712, accepting follow-ups by email


sr #106712: accepting follow-ups by email

Submitter:  Karl Berry <karl>
Submitted:  Mon 06 Apr 2009 08:58:46 PM UTC
Votes: 2
Category:  Savannah trackers - bugs, tasks, etc. Priority:  7 - High
Severity:  1 - Wish Status:  None
Privacy:  Public Assigned to:  None
Operating System:  None Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Sat 16 Mar 2024 08:35:45 PM UTC, comment #25: 

> If I'm correct, yours is in addition to the +1s in comment #3, comment #6, comment #19, and comment #23 here, and the duplicate sr #107431.

You are entirely correct; please record me as +1 for this request and thanks for pointing out that the phrasing was unclear.

Corwin Brust <carlc>
Site Administrator
Sat 16 Mar 2024 08:26:50 PM UTC, comment #24: 

comment #21:

> At a minimum the rationale for closing should be documented and
> a final status set.  In fact, I think we not only need to do
> this but that's it is a fairly high priority (for a wish-list
> item), so I've made that change also.

The wording here makes it unclear whether "do this" refers to documenting a reason for the sr's closure, or implementing the requested feature.  From the priority change of the sr, I infer you're adding another vote for the feature.

If I'm correct, yours is in addition to the +1s in comment #3, comment #6, comment #19, and comment #23 here, and the duplicate sr #107431.

Dave <barx>
Sat 16 Mar 2024 10:40:27 AM UTC, comment #23: 


+1 from me.  It's the least comfortable bug tracker I have to deal with, as I get new comments by email, but then I have to log in to reply.

And I like the idea of using PGP signatures to authenticate the sender (while possibly allowing unsigned email as anonymous senders) very much.

Dave and I were discussing about it here:

Have a lovely day!

Alejandro Colomar <alx>
Sat 16 Mar 2024 05:29:18 AM UTC, comment #22: 

Oops.  Dave is not Karl.  Sorry about that.

Corwin Brust <carlc>
Site Administrator
Sat 16 Mar 2024 05:17:04 AM UTC, comment #21: 

Reopening; as Karl has pointed out there is neither history nor comments explaining when/why this was closed.  At a minimum the rationale for closing should be documented and a final status set.  In fact, I think we not only need to do this but that's it is a fairly high priority (for a wish-list item), so I've made that change also.

Corwin Brust <carlc>
Site Administrator
Sat 16 Mar 2024 05:04:27 AM UTC, comment #20: 

Why was this closed?  (Less importantly, but curiously missing from the record: when was it closed?  Neither the bug's history at the bottom of the page, nor any of the savannah-generated emails associated with it,* shows any changes to any of the bug's main fields.)


Dave <barx>
Sun 25 Oct 2015 01:03:24 PM UTC, comment #19: 

May I add my voice to those desiring such a feature? It's much easier to reply by writing an email than to use the Savannah web interface.

Gavin D. Smith <gavin>
Thu 22 Jul 2010 08:18:15 AM UTC, comment #18: 

Dropping the Savane trackers means migrating all the data and recreate other features such as integrated authentication.

We're moving towards distributed bug tracking, which could replace the need for a mail interface (without the spam).

Sylvain Beucler <Beuc>
Wed 21 Jul 2010 04:38:35 PM UTC, comment #17: 

Forgot to add: My personal impression is that dropping the Savane trackers should be completely out of the question, and it was never considered, IIRC.  Sylvain can tell for sure.

Some projects (e.g. GNUstep) actually like them.

Implementing this feature requires someone with sufficient PHP skills and willingness to dive into Savannah's internals.  Integration with external bug trackers might be even more difficult, I suspect, although it's worth considering since it would be a very nice feature.

Yavor Doganov <yavor>
Wed 21 Jul 2010 04:06:49 PM UTC, comment #16: 

There is an official debbugs instance (; all GNU projects are welcome to use it, TTBOMK.  It has nothing to do with Savannah, though, and there's no integration at all.

Yavor Doganov <yavor>
Wed 21 Jul 2010 03:46:29 PM UTC, comment #15: 

there is a dupe for this: sr #107431
any chance this will be implemented?
actually, it would seen that dropping the integrated savanna bug tracker in favor of a specially designed external tool (bugzilla or debbugs) which would allow both web forms and email seems to be the best approach.
why reinvent the wheel? just outsource!

Sam Steingold <sds>
  Spam posted by anonymous
Sat 18 Apr 2009 11:33:53 PM UTC, comment #13: 

> Do you think that the instant handling of messages is a mandatory feature?

I think every few minutes would be ok, though not ideal.

At any rate, I'm afraid I have no clue how to implement anything like this in php.  So if we can't separate the mail receiving from the savannah injection, I guess it just remains on the wishlist.


Karl Berry <karl>
Site Administrator
Sat 18 Apr 2009 06:31:26 AM UTC, comment #12: 

Karl, i have no idea of how the cgi call could be done to perform the instant handling of messages. The only solution that comes to my mind is the deferred message handling mentioned earlier, a php script running on the website every x minutes that retrieves the messages (perhaps using a protocol more secure than plain pop3) and makes the self post with the extracted data. In my opinion, one of the advantages of this approach is that it is flexible enough to allow to be used in more installations than savannah itself: you could install the application in your site and configure it to have one external email account for receiving the follow-up emails, given the access information you wouldn't have to make any modifications on the mail server for this to work. Of course it would require to slightly modify the configuration script.

Do you think that the instant handling of messages is a mandatory feature?

Federico Gimenez Nieto <fgimenez>
Sun 12 Apr 2009 10:10:11 PM UTC, comment #11: 

I realized last night that savannah doesn't handle incoming mail locally, as far as I know.  So I don't see how the mail handling and web application can run on the same host?

If we can do the separation, we could make an alias on fencepost, where mail does get processed.  Handle the mail there and invoke a cgi on savannah with the info.

I can write the mail handling script, but not in php ...

Karl Berry <karl>
Site Administrator
Sun 12 Apr 2009 09:48:05 AM UTC, comment #10: 

Karl -- i think that if both the program that handles the messages and the web application run in the same host there wouldn't be any problem in creating an adhoc php session and deleting it after the fake post. For this to be done easily the handling backend program should be written in php and should use the same php.ini configuration file as the web frontend (or at least the same session settings).

Federico Gimenez Nieto <fgimenez>
Sat 11 Apr 2009 09:24:50 PM UTC, comment #9: 

Thomas -- I don't see a problem with requiring logged-in users to post or follow up.  In fact, I think that should be the default.

There is no requirement in GNU that projects use a tracker at all, and lots don't.  OTOH, there is a requirement that projects accept bugs through email (although not everyone follows it, sadly enough).  So if a user wants to submit a report without registering anywhere, they can (should be able to).

Allowing all anonymous posts would be like allowing unfiltered email.  Not feasible ...

I have no objection to the idea of allowing anonymous posts if they are filtered as rigorously as we do with email, but I also don't think it's necessary, or especially beneficial, actually.
Anyone who wants to post through a tracker is going to expect to create an account.

Karl Berry <karl>
Site Administrator
Sat 11 Apr 2009 09:14:10 PM UTC, comment #8: 

Federico -- the idea of doing a POST as if it were done through the web site sounds good.  If we can somehow fake the session information it presumably is going to be looking for.

I'm not sure it needs to be a cron job and deal with pop.  Some address could just pipe directly to the mail-handling program (and an archive). That seems simpler to me.

Thanks for continuing to think about this.

Karl Berry <karl>
Site Administrator
Sat 11 Apr 2009 05:51:48 PM UTC, comment #7: 

For the the server-side part i believe that one possible implementation could be the following:
1.- Set up a cronjob, following the structure of the ones currently running, that connects to the receiving email account using a regular perl's/php's (depending on the language used for the cronjob) pop3 library.
For each message found there:
2.- Retrieve the message and delete it from the account
3.- Check if it is correctly composed (including authentication)
4.- If it passes the previous test, check some kind of antispam rules
5.- If it passes the previous test, insert the information in the database
After processing all the messages maybe write a log.

For point 5, and trying to reuse the current scripts without repeating code, i think that the most straight path is to create a http post request equivalent to the one created by the form and feed it to "/task/index.php" (the 'action' of the tracker's form). In my opinion, other option could be to factorize the controller and model layer code at "frontend/php/include/trackers/index.php" and "frontend/php/include/trackers_run/index.php" to be used by both the script code of the cronjob (in this case perhaps the cronjob could be written in php instead of perl) and by "frontend/php/task/index.php" (that is actually using it).

In order to allow a stronger spam control, the inserted data could be somehow marked, so that it could be easily retrieved and managed.

What do you think?

Federico Gimenez Nieto <fgimenez>
Sat 11 Apr 2009 09:54:10 AM UTC, comment #6: 

Karl: But only allowing logged-in users to post follow-ups, wouldn't that be contradictionary to allowing non-subscribers post to GNU mailing lists -- or could we perhaps draw the analogy there, and send unauthenticated posts (stemming not from logged-in users) through some moderation system à la GNU listmanager?

Certain is, that the spam problem has to be considered, as there are already people only registering account on Savannah for submitting spam messages.

The technical difficulties aside, I completely support this request, but also have no idea how to implement it, and no time to investigate.

Thomas Schwinge <tschwinge>
Fri 10 Apr 2009 11:04:10 PM UTC, comment #5: 

To the best of my knowledge, it is possible to configure trackers such that only logged-in users can post or follow-up.   At least I sure remember doing this for my projects.  I hope that is even the default now.

Perhaps an X-Savane-User: karl
header would be enough authentication :).

It's the "inject it somehow" that stymies me, I'm afraid ...

Karl Berry <karl>
Site Administrator
Fri 10 Apr 2009 06:06:36 AM UTC, comment #4: 

On second thought, why there is a need for authentication at all?  As it stands now, anonymous users can open bugs/tasks and can follow-up.

The "only" thing that needs to be done is to craft all mail from the trackers to have a Reply-To: some_bot set (all others are in the CC list, so Savannah will send them a copy), and have some_bot process the message and inject it somehow on the basis of the existing X-Savane-* headers (which should be manually filled by the poster).

Yavor Doganov <yavor>
Fri 10 Apr 2009 05:11:39 AM UTC, comment #3: 

I second this wishlist request -- the web-based trackers is something I dislike in Savannah.  I have the feeling that the implementation would be far from trivial.

FTR, debbugs has no authentication.  Everyone can send messages and can manipulate the control bot.  Although scary at first glance, this has worked well for many years.  There is spam, of course, and spam mesages are manually deleted from the database when users report them.  Bugs are archived in 28 days after they are fixed, and then all mail to the bug is rejected (everyone can "unarchive" a bug with a control message, though).

If doable, GPG-signed messages would be less of a nuisance than filling the web forms.  I guess that it won't be automatically usable for most of the users (as they'll have to register their GPG key), but that's OK.

Yavor Doganov <yavor>
Thu 09 Apr 2009 10:51:24 PM UTC, comment #2: 

Right, we could devise some reasonable format for the messages and I guess that would exclude the spam.  We don't need nearly all the bells and whistles that debbugs has -- it would be very useful just to be able to send a reply, like "Post a Comment" in the web interface.

I'm not worried about difficulty of composition.  If people want to do it (like me :), they'll make it easy for themselves anyway.

The problem that comes to my mind is about authenticating the sender.  The web interface automatically knows what user is doing the posting.  An email interface wouldn't have a clue.  I don't know how debbugs handles this or if they just accept mail from anyone for anything.

So here's my idea on that front -- we could require the messages to be gpg-signed, and also to provide the savannah username.  Then the processor could gpg-decode them according to that user's gpg key.  If it works, good, if not, too bad.

FWIW, I've written many programs for autoprocessing email.  That's the easy part.  But I remain totally stuck on how it could be integrated into savannah.

Thanks for thinking about it with me :).

Karl Berry <karl>
Site Administrator
Thu 09 Apr 2009 08:31:43 AM UTC, comment #1: 


I have always found this very interesting (sending a mail with instructions to one machine), but probably i don't have the required skills to accomplish it either ;)

Anyway we could think about the requirements of the application. For the mail message to be understood, i think that it must have a well defined, and therefore recognizable, structure. That is, only well-formed messages could be parsed and understood. In my opinion this leads to the rejection of most kinds of spam, if the rules avoid tokens like 'viagra' or 'enlarge' :). But has the side effect of make more dificult the creation of messages: the sender has to be aware of the rules, and must compose the message following them. I don't know if it could be possible to develop a kind of mode in emacs for this to be done.

This reminds me of the debian's 'reportbug' utility, i'm not very familiar with it but as far as i know it asks you some questions about the request and finally sends a well-formed mail message with the required structure to be understood by the receiving system, please correct me if i'm wrong.

What do you think?


Federico Gimenez Nieto <fgimenez>
Mon 06 Apr 2009 08:58:46 PM UTC, original submission:  

It would be wonderful if Savannah could accept follow-ups by email, instead of requiring posting through the web.  I'd much rather compose in Emacs than a web form.  Not to mention speed.

I have only vague ideas on how to avoid spam getting through, but it seems like it could be done.

I wonder if any other forges have already done this.

Sorry that I don't have the wherewithal to do it myself.

Karl Berry <karl>
Site Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by alx (Posted a comment)
  • -email is unavailable- added by alx (Voted in favor of this item)
  • -email is unavailable- added by carlc (Posted a comment)
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by gavin (Posted a comment)
  • -email is unavailable- added by sds (Posted a comment)
  • -email is unavailable- added by tschwinge (Posted a comment)
  • -email is unavailable- added by yavor (Posted a comment)
  • -email is unavailable- added by fgimenez (Posted a comment)
  • -email is unavailable- added by tschwinge (Voted in favor of this item)
  • -email is unavailable- added by karl (Submitted the item)

    There are 2 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-03-16 alx Carbon-Copy- Added alx
    2024-03-16 Beuc Carbon-CopyRemoved 20998 -
    2024-03-16 carlc Priority5 - Normal 7 - High
        Open/ClosedClosed Open
    2009-04-07 tschwinge Carbon-Copy- Added tschwinge

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code