Follow-up Comment #7, sr #106712 (project administration):
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?
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/support/?106712>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
