php-general Digest 22 Sep 2010 02:58:54 -0000 Issue 6953
Topics (messages 308242 through 308249):
Re: Sending Encrypted Email
308242 by: Floyd Resler
308244 by: Erik L. Arneson
308245 by: Floyd Resler
308246 by: Erik L. Arneson
Re: Auto-generating HTML
308243 by: Bob McConnell
308247 by: tedd
Re: Database Administration
308248 by: tedd
Re: PHP Email Question
308249 by: J Ravi Menon
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
On Sep 21, 2010, at 1:00 AM, Erik L. Arneson wrote:
> On Thu, 16 Sep 2010, Nathan Rixham wrote:
>> Floyd Resler wrote:
>>> I need to send encrypted email. Can I use our server's signed certificate
>>> we use for Apache?
>>
>> Yes you can use the servers certificate, you can use any x509
>> certificate you like - however, I'd recommend checking out
>> startssl.org who will give you a free smime certificate.
>
> But that is probably just for *signing* the email. If you'd like to
> encrypt email, you will need a public key or shared secret from the
> email recipient.
>
> --
> Erik Arneson <[email protected]>
> GPG Key ID : 1024D/62DA1D25 BitCoin : 1LqvuGUqJ4ZUSoE7YE9ngETjwp4yZ2uSdP
> Office : +1.541.291.9776 Skype : callto://pymander
> http://www.leisurenouveau.com/
>
>
I got it all figured out. The part I was missing was combining the certificate
with the key and giving it to the end-user to install on their system. I was
able to use the Web server's certificate for the encryption. The interesting
thing is that the client wants ALL passwords sent via encrypted email. Of
course, they need the P12 file installed in order to view the email and that
requires a password to install it. So, obviously, I can't send that password
encrypted. So, my solution is to provide a Web page that the user gets to by
an emailed link that has a unique identifier and the user must enter a piece of
personal information for verification (in this case, ZIP code). Once verified,
they are shown the password on the page. That's the only way I can think of to
do it. Is that a good solution or does someone have a better way?
Thanks!
Floyd
--- End Message ---
--- Begin Message ---
On Tue, 21 Sep 2010, Floyd Resler wrote:
> I got it all figured out. The part I was missing was combining the
> certificate with the key and giving it to the end-user to install on
> their system. I was able to use the Web server's certificate for the
> encryption. The interesting thing is that the client wants ALL
> passwords sent via encrypted email. Of course, they need the P12 file
> installed in order to view the email and that requires a password to
> install it.
Wait, you didn't send the webserver's certificate to the user, did you?
That's a bad idea. The email recipient should have her own certificate,
which has both a private and a public part.
The webserver's certificate (presumably the one you have signed by the
CA), especially the private key, needs to be kept *private*, and not
sent all over the place. Using the same private/public key pair on both
endpoints defeats the purpose of PKI. You would be better off using
plain old symmetric encryption.
>So, obviously, I can't send that password encrypted. So, my solution
>is to provide a Web page that the user gets to by an emailed link that
>has a unique identifier and the user must enter a piece of personal
>information for verification (in this case, ZIP code). Once verified,
>they are shown the password on the page. That's the only way I can
>think of to do it. Is that a good solution or does someone have a
>better way?
I'm sure there are some good products out there to handle this.
Personally, for email encryption I always prefer the OpenPGP family of
tools (including GnuPG and commercial PGP). End-users can install PGP
on their systems, generate public keys, and then send them to the
webserver. No passwords need to be handed out---they will come up with
their own passphrases when they generate their public/private key pairs.
--
Erik Arneson <[email protected]>
GPG Key ID : 1024D/62DA1D25 BitCoin : 1LqvuGUqJ4ZUSoE7YE9ngETjwp4yZ2uSdP
Office : +1.541.291.9776 Skype : callto://pymander
http://www.leisurenouveau.com/
--- End Message ---
--- Begin Message ---
On Sep 21, 2010, at 11:15 AM, Erik L. Arneson wrote:
> On Tue, 21 Sep 2010, Floyd Resler wrote:
>> I got it all figured out. The part I was missing was combining the
>> certificate with the key and giving it to the end-user to install on
>> their system. I was able to use the Web server's certificate for the
>> encryption. The interesting thing is that the client wants ALL
>> passwords sent via encrypted email. Of course, they need the P12 file
>> installed in order to view the email and that requires a password to
>> install it.
>
> Wait, you didn't send the webserver's certificate to the user, did you?
> That's a bad idea. The email recipient should have her own certificate,
> which has both a private and a public part.
>
> The webserver's certificate (presumably the one you have signed by the
> CA), especially the private key, needs to be kept *private*, and not
> sent all over the place. Using the same private/public key pair on both
> endpoints defeats the purpose of PKI. You would be better off using
> plain old symmetric encryption.
>
>> So, obviously, I can't send that password encrypted. So, my solution
>> is to provide a Web page that the user gets to by an emailed link that
>> has a unique identifier and the user must enter a piece of personal
>> information for verification (in this case, ZIP code). Once verified,
>> they are shown the password on the page. That's the only way I can
>> think of to do it. Is that a good solution or does someone have a
>> better way?
>
> I'm sure there are some good products out there to handle this.
> Personally, for email encryption I always prefer the OpenPGP family of
> tools (including GnuPG and commercial PGP). End-users can install PGP
> on their systems, generate public keys, and then send them to the
> webserver. No passwords need to be handed out---they will come up with
> their own passphrases when they generate their public/private key pairs.
>
> --
> Erik Arneson <[email protected]>
> GPG Key ID : 1024D/62DA1D25 BitCoin : 1LqvuGUqJ4ZUSoE7YE9ngETjwp4yZ2uSdP
> Office : +1.541.291.9776 Skype : callto://pymander
> http://www.leisurenouveau.com/
>
>
I used OpenSSL to generate the P12 file (I haven't actually sent this to anyone
since I'm still testing). So, I assumed that it was okay for distribution.
Perhaps not. At any rate, I like the idea of the OpenPGP better. I'll see how
to do that.
Thanks!
Floyd
--- End Message ---
--- Begin Message ---
On Tue, 21 Sep 2010, Floyd Resler wrote:
> I used OpenSSL to generate the P12 file (I haven't actually sent this
> to anyone since I'm still testing). So, I assumed that it was okay
> for distribution. Perhaps not. At any rate, I like the idea of the
> OpenPGP better. I'll see how to do that.
Oh good, good. That should work just fine. I thought you were saying
that you'd sent the webserver's keys to the end-user.
There's an email encryption method called S/MIME that uses that uses
certificates and such that I think is handled pretty well by Outlook (or
whatever Microsoft users do their email with these days). You could
also look into that. It *might* be easier for your end-users.
--
Erik Arneson <[email protected]>
GPG Key ID : 1024D/62DA1D25 BitCoin : 1LqvuGUqJ4ZUSoE7YE9ngETjwp4yZ2uSdP
Office : +1.541.291.9776 Skype : callto://pymander
http://www.leisurenouveau.com/
--- End Message ---
--- Begin Message ---
From: Andy McKenzie
> I think the main thing I'm seeing is that there isn't a single,
> accepted, simple way to do this: no matter what I do, it will be a
> workaround of some type. Either I'm adding complexity (a function to
> convert everything), or I'm adding lines (heredoc/nowdoc seem to
> require that the opening and closing tags be on lines without any of
> the string on them), or I'm adding typing (adding ' . "\n"' to the end
> of every line of HTML). Perhaps I'll put some effort into building a
> function to do it, but not this week... I think for now I'll keep
> appending those newlines, and just have more code to fix at a later
> date. It's reasonably clean, it's just mildly annoying.
It should be relatively easy to do a search and replace on the double
tag locations and insert the newlines. Using tr(1) to replace all "><"
pairs with ">\n<" might be an improvement. Would it be easier to remove
the extras, or to insert all of them in the first place?
Bob McConnell
--- End Message ---
--- Begin Message ---
At 2:56 PM -0400 9/20/10, Andy McKenzie wrote:
Hey folks,
I have the feeling this is a stupid question, but I can't even find
anything about it. Maybe I'm just not searching for the right things.
Here's the problem. I'm writing a lot of pages, and I hate going in
and out of PHP. At the same time, I want my HTML to be legible. When
you look at it, that's kind of a problem, though... for instance
-snip-
You can mix html and php more effectively and with better clarity than that.
Two things you should consider:
1. Effective use of includes. Please review and learn from this demo:
http://sperling.com/examples/include-demo/
2. Isolated use of echo()'s. I only mix html and php when it is
necessary to inject values created by a php/mysql process. To show
these values I typically use this format:
<?php echo($whatever); ?>
within html -- for example:
<h1><?php echo($title);?></h1>
As such, all my code (html, css, php, mysql, javascript) is not
complex, nor unreadable, and is easily maintainable.
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
At 10:48 AM +0100 9/21/10, Tom Barrett wrote:
Hi
I need to build a custom client management app, which will build and manage
a database per client. This means that on top of the usual sql crud, it
needs to be able to create databases, add/edit/delete database users, create
tables.
Is there a way for me to do this nicely as PHP solution? am I better off
incorporating non PHP pieces into this (e.g. shell)? or should I leave the
admin tasks (e.g. database creation) as a 'normal' administrative task
(commandline/webmin/watever)?
I'm not sure as to what you need, but for me I do all my database
creation in phpMyAdmin. From there I populate with php.
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
Just on this topic, I found swiftmailer library to be really useful
esp. in dealing with 'template' emails with custom variables per
recipient:
http://swiftmailer.org/
The e.g. on email template processing:
http://swiftmailer.org/docs/decorator-plugin-howto
There are batchSend() functionalities, ability to compose various mime
type emails etc...
Ravi
On Mon, Sep 20, 2010 at 8:20 AM, chris h <[email protected]> wrote:
>> Ignore the other parameters unless you are very familiar with RFCs 2821,
>> 2822 and their associated RFCs
>>
>
>
> I would advise against ignoring the other parameters. Doing so will pretty
> much guarantee having your email end up in SPAM. Instead look up the
> examples in the docs, or better yet use something like phpmailer as Tom
> suggested.
>
>
> Chris.
>
>
> On Sun, Sep 19, 2010 at 6:37 PM, TR Shaw <[email protected]> wrote:
>
>>
>> On Sep 19, 2010, at 6:00 PM, Joe Jackson wrote:
>>
>> > Hi
>> >
>> > Sorry for the simple question but I am trying to get my head around PHP.
>> I
>> > have a sample PHP script that I am trying to use to send a php powered
>> email
>> > message. The snippet of code is shown below....
>> >
>> > mail('[email protected]', 'Subject', $values['message'], "From:
>> > \"{$values['name']}\" <{$values['emailaddress']}>");
>> >
>> > This works fine, but how can I add in other fields to the email that is
>> > recieved?
>> >
>> > For example in the form there are fields called, 'emailaddress',
>> > 'telephone', 'address' and 'name' which I need to add into the form along
>> > with the message field
>> >
>> > Also with the formatting how can I change the format of the email to
>> >
>> > Name: $values['name'],
>> > Address: etc
>> > Message:
>> >
>>
>> Joe
>>
>> The mail command lets you send mail (an RFC2821 envelop). The function is:
>>
>> bool mail ( string $to , string $subject , string $message [, string
>> $additional_headers [, string$additional_parameters ]] )
>>
>> $to is where you want it to go
>> $subject is whatever you want the subject to be
>> $message is the information you want to send
>
> Ignore the other parameters unless you are very familiar with RFCs 2821,
>> 2822 and their associated RFCs
>
>
>> So if you want to send info from a form you might want to roll it up in xml
>> and send it via the message part. when you receive it you can easily decode
>> it. If you don't want to do that put it in a format that you can easily
>> decode on the receiving end.
>>
>> Basically "mail" is a way to deliver information in the $message body. How
>> you format the information there is up to you. However, depending on your
>> system's config you are probably constrained to placing only 7bit ascii in
>> the $message body.
>>
>> You might also move away from the mail function and look at phpmailer at
>> sf.net if you need more complex capabilities.
>>
>> Tom
>>
>>
>>
>>
>
--- End Message ---
