Billy Harvey wrote:

> Bogdan, a technique I've used in the past may work for you.
> When someone wants to upload something, I have them request a cookie by
> sending a blank email to a specific address.  This automatically
> generated cookie is good for some limited time (whatever works for you),
> and will only be sent to appropriate return addresses (I use a web form
> to allow the proper registration of those addresses).
> This cookie then needs to be used in the subject-line of the email - a
> reply to the message would work for example.
> So, if your system gets an email with a specially formatted, and
> short-lived (randomly generated) cookie in the subject, it knows what to
> do with it.
> Billy

Thanks for taking the time to reply!

That's the proper (and definitely secure) way to do it. However I'm looking
for something not necessarily that secure, because the servers won't be
public, but with a more "on-the-fly" approach for the user.

You see, this feature is the alternative to uploading data by logging in the
system. Logging in is no big deal - just type your username and password and
you're there. Two clicks away and you can upload. This, however, would be a
simple way to send an e-mail on a project you're working on to another user
and simply CC the system so there's a copy there for everybody to see
without spamming all the people involved. The same can be accomplished by
sending the e-mail to the user, logging in and pasting the message and
upload the document via HTTP. But isn't this too complicated for the average
user? :-)

I have two vague directions to accomplish the results I'm looking for, but I
don't know if any of them is reliable/possible.

The first method involves taking a better look at those headers. I noticed
there are a bunch of originating information headers in the e-mail. How
secure would it be to use them? Should I expect them to be there or is it
that the mail servers I tested this on are nice enough to include that

The second approach is based on the fact that the environment this system
will work in is known - it's made of people who trust the company which
installed the system. As such, they can easily be persuaded to perform
action "X" which would result in adding a certain "secret" header to their
e-mail messages. This secret header would be an all-time cookie for the
respective user - the system would recognize the user by it and allow the
e-mail to get posted.

The second approach is rather poor even if someone can suggest some
practical directions for action "X" because the whole idea behind the system
is mobility and I wouldn't want users not to be able to send e-mail messages
to it just because they're not using the computer in the office. I jotted it
down however, so you can get an idea of where my thoughts are going... :-)


PHP General Mailing List (
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to