Fully functional email client

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Hi all,

Newbie alert. I'm new to this newsgroup so please be nice to me. I'm not co=
mpletely new to Perl but not exactly a Guru and not exactly much more than =
a complete novice so please bear with me.

My name is James Christian and I am PhD research student at the University =
of Essex in the UK. You can see a picture of me with my little daughter on =
my very basic webpage privatewww.essex.ac.uk/~jcread

Anyway, apart from machine tranlation research in my spare time I have deve=
loped a conversational agent that dialogues with users to find out what the=
y are really looking for (gone are the days of simple keyword search). I ha=
ve a growing base of experimental users for my alpha release who currently =
need to come into my office to use the system as it is not web borne. The s=
ystem can take some time to answer questions because of the comlexity of th=
e task (the system is still learning). It asks the user questions to figure=
 out what they want and then sends them off to the right website or busines=
s that has the products, services, information or free downloads that they =


Hi, how can I help you?
Where can I download music?
Erm, lots of different places what were you looking for exactly?
A song by U2?
Which song exactly?

This goes on until the system has completely matched the user's requirement=
s. It can take some time for the inference engine to figure out a satisfyin=
g answer and if the answer turns out not to be satisfying then the system h=
as to go into dialogue to make new suggestions and learn from user feedback=
. As the system is slow at decision making my growing user base has asked i=
f they can play with the system by email instead of having to sit in my off=
ice and wait for a long time for the system to generate responses.

So what I basically need is a solution I can drop my conversational agent i=
nto. Some kind of fully functional email client that already absracts away =
the details of receiving and sending messages. Generating message ids for t=
hreading. Extracting the new text which is the response to the last email e=
tc. I need something I can just drop my agent into with minimal parameter s=
etting such as configuring the SMTP and POP servers to be used, user name a=
nd password and port numbers etc. Something my system can just automaticall=
y hit the reply button to and respond to a question. Something my can easil=
y extract the relevant text from without having to worry about implementati=
on details of designing a full email client from first principals.

Basically, I need a command line version of Thunderbird but that already ex=
tracts the new line of text as input to my agent. Surely, there must be som=
ething like that out there already done in Perl. Can anyone point me to any=
thing? Or is it noses to the grindstone time?

Thanks for any advice you can give me guys.

James Christian

Re: Fully functional email client

"iaoua iaoua"  wrote in message=20

Quoted text here. Click to load it

I'm not sure I understand what you need, but I have recently developed =
simple Perl and PHP scripts that take user input, add it to a database, =
then put together HTML that is echoed to the user. It also generates=20
formatted HTML files for use by another HTML page, and it emails the=20
submitted content to me along with information about the user. It is=20
password protected and designed to thwart DoS attacks by incorporating a =

file lock and delay which will bounce repeated accesses. And it also =
uses an=20
HTML purifier to clean up any possibly malicious HTML submitted by the =

So, if you could use a website that allows user input, rather than =
users send emails, the rest of the project should be just a matter of=20
providing the feedback to the user until the desired resource is =
and then the user could click the URL that is recommended to see if it =
was needed.

I've become more comfortable with PHP than Perl, but I'm a novice at =
However, I've been able to do what I needed to do, and now I'm just =
it up and adding features.

I am not really familiar with Thunderbird, but there are simple mailer=20
functions in Perl and PHP that are easy to implement. And I'm not really =

sure if email is even needed for your application. You just need a =
with hooks to your main application. For any client-side email, the user =

would use his own default sendmail application (as with an href=20
"sendto:emailaddy"), and your server-side script can use the mail =
supplied by the host. There may be other considerations depending on =
your application resides and what form of I/O it requires.


Re: Fully functional email client

[Please format your postings to reasonable line length (about 70
characters/line). News clients do not generally wrap long lines and long
lines are hard to read. I have reformatted your posting.]

Quoted text here. Click to load it

In general I agree with Paul: Email seems to be an awkward choice for
what seems to be a dialog consisting of one-line messages. However, if
the response times are very long (several minutes or more) the
asynchronous nature of email is an advantage. As an alternative you
might consider an instant messaging system like XMPP (also known as

Perl has a number of modules for accessing mail at various places (local
folders, POP, IMAP, ...), parsing it, and sending it by various means
(local sendmail process, SMTP/Submission, ...). Look on

What works for you depends very much on your system (Windows, Linux,
MacOS?), how you access and send mail (can you receive and send mail
locally or do you need IMAP/POP/SMTP?), your users (can you teach them
to send only plain text or do they use HTML mails? How about quoting?)

Quoted text here. Click to load it

I'm not aware of an out of the box solution for this. Most of it can be
cobbled together from existing modules with a few lines of code. The
hardest part is probably "extracting the new text which is the response
to the last email" since users are notoriously bad at following
conventions in email.

I think I would use XMPP instead of mail for this. The Net::XMPP module
seems to rather easy to use (although so far I have only used it to send
messages, not to receive them) and IM fits the dialog structure better.


Site Timeline