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.
Thanks,
Karl
|
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?
|
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 ...
|
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).
|
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.
|
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.
|
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?
|
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.
|
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 ...
|
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).
|
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.
|
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 :).
|
Thu 09 Apr 2009 08:31:43 AM UTC, comment #1:
Hi,
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?
Cheers,
Federico
|
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.
|