php-generated email not formatting on a mac

P

Paul Furman

Any idea what's wrong with the formatting of this php-generated email
that would cause some mac users to not get it formated in html but
rather show all the coding as gibberish?

I substituted a small 'x' to anonymize the content for emails & send
paths, etc. Also here's the html portion posted as a web page:
http://edgehill.net/temp-/Order-Confirmation.htm

saved as text from my PC Thunderbird install as I received the email:

X-Account-Key: account2
X-UIDL: UID83144-1099634831
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:

Return-Path: <[email protected]>
Received: from x.x.com (x)
by x.x.com (x) with SMTP id x
for <x>; Tue, 2 Jun 2009 21:02:03 -0700 (PDT)
(envelope-from (e-mail address removed))
Received: (qmail 42633 invoked by uid 3174); 3 Jun 2009 04:02:00 -0000
Delivered-To: (e-mail address removed)
Received: (qmail 42606 invoked by uid x); 3 Jun 2009 04:02:00 -0000
Date: 3 Jun 2009 04:02:00 -0000
Message-ID: <[email protected]>
To: (e-mail address removed)
Subject: x Order Confirmation for x
MIME-Version: 1.0
FROM: x <[email protected]>
CC: (e-mail address removed)
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.773 (HTML_MESSAGE,MIME_HTML_ONLY)

<html>
<body>
ORDER CONFIRMATION<br>
x
<br>
x
<br><a href="http://www.x.com">www.x.com</a>
</center><br>June 3, 2009, 12:02 am<br>Customer: x / Invoice
Number: 76384387<br> x / (e-mail address removed) x <center>
<table border='1' cellpadding='2' cellspacing='1'>
<tr><th>Qty</th><th> </th><th>Price</th><th>Total</th></tr>
<tr><td>1</td><td>x</td><td>$ 15.00</td><td>$ 15.00</td></tr>
<tr><td>1</td><td>x</td><td>$ 9.50</td><td>$ 9.50</td></tr>
<tr><td colspan='3' align='right'>Subtotal:</td><td>$x</td></tr>
<tr><td colspan='3' align='right'>Tax:</td><td>$x</td></tr>
<tr><td colspan='3' align='right'>Delivery:</td><td>$0.00</td></tr>
<br><tr><td colspan='3' align='right'>Order
total:</td><td>$104.5725</td></tr>
</table>

</center><br>
We will contact you
once the order is ready. Send us an email if you have questions
or call one of us directly:<br>
x <center>

</body>
</html>
 
T

The Natural Philosopher

Paul said:
Any idea what's wrong with the formatting of this php-generated email
that would cause some mac users to not get it formated in html but
rather show all the coding as gibberish?

Wait till you send ANY HTML to Outlook Express. Its beyond crippled.
 
J

John Hosking

I didn't see the original post, but I can add some remarks to this reply.
comp.lang.php trimmed, as this doesn't seem too PHP-centric to me.

I have no Mac, sorry. But I'm wondering if you were happy with the
formatting in other clients, such as TB? It's not valid HTML in the
first place, so I'd say you're lucky any recipient (not just the Mac
users) can decipher it at all.

No Mac, but I can send a Web page to the validator:

http://validator.w3.org/check?uri=http://edgehill.net/temp-/Order-Confirmation.htm

I have no idea what Mac e-mail clients do with invalid markup.

Still wondering how it looks to you in Outlook, Outlook Express, other
clients.

In Firefox it looks pretty rough (although that may be what you're happy
with; I don't mean to criticize). I don't coding gibberish in any case,
so maybe that's all you're worried about here.

Send multipart MIME messages with an alternative text version. The phpmailer
class is very good for this purpose and easy to use.


--
John
For example URLs and e-mail addresses, use one of the pre-defined
domains reserved for such use.
Example URLs: www.example.com or example.net or example.net
Example address: (e-mail address removed)
 
N

Neredbojias

Wait till you send ANY HTML to Outlook Express. Its beyond crippled.

Now don't be natty, Natty. That's what got me into html in the first
place, -reading da code behind those kewl html OE mail messages. Yeah,
it's probably not up to the latest specifications, but there isn't a
browser out there that's perfect. either.
 
P

Paul Furman

Pls_reply_to_group said:
I'm not sure I'd call it a "problem", but it is not uncommon for e-mail clients
to not render HTML, or to do it badly. This can be due to a functional
limitation (like Outlook) or security measure (like my Thunderbird
configuration). As coders we can't expect that the recipient will be able to
view HTML, so multipart MIME offers graceful degradation to an alternate plain
text version. If they see the pretty HTML version, consider it a bonus.

BTW, spam filters are more likely to consider HTML messages -- and especially
HTML-only messages -- to be spam, possibly lowering your delivery rate. Note
the SpamAssassin header in your original post:

Thanks, good points. I generally avoid html emails unless there's a table.

This seemed so simple...

<html>
<body>
<table>

Sheesh, what program couldn't figure out how to render that?
Doctype?? who cares, it's obvious <grin>

OK now that I've got that out of my system, I'll clean it up
 
T

The Natural Philosopher

Neredbojias said:
Now don't be natty, Natty. That's what got me into html in the first
place, -reading da code behind those kewl html OE mail messages. Yeah,
it's probably not up to the latest specifications, but there isn't a
browser out there that's perfect. either.
Its far far worse than that. It uses the rendering engine from
....MICROSNOT WORD..

Not from IE7/8 etc etc.

It doesn't even recognise <DIV> as far as I can tell.
 
P

Paul Furman

John said:
I didn't see the original post, but I can add some remarks to this reply.
comp.lang.php trimmed, as this doesn't seem too PHP-centric to me.

It might be, I replaced the php group.
Or something about mail servers...

I have no Mac, sorry. But I'm wondering if you were happy with the
formatting in other clients, such as TB? It's not valid HTML in the
first place, so I'd say you're lucky any recipient (not just the Mac
users) can decipher it at all.

It's just simple html table with default text. Nothing fancy at all.


Thanks, I should have tried that.
I only just now posted as a web page for this question.

The two warnings are similar and unclear to me:

------------------------
Unable to Determine Parse Mode!

The validator can process documents either as XML (for document types
such as XHTML, SVG, etc.) or SGML (for HTML 4.01 and prior versions).
For this document, the information available was not sufficient to
determine the parsing mode unambiguously, because:

* the MIME Media Type (text/html) can be used for XML or SGML
document types
* No known Document Type could be detected
* No XML declaration ...
------------------------

I don't understand Mime <g> but I did it like this in php:

$mailheader = "MIME-Version: 1.0\r\n";
$mailheader .= "FROM: (e-mail address removed)\r\n";
$mailheader .= "CC: " . $mail_recipient . "\r\n";
$mailheader .= "Content-Type: text/html; charset=us-ascii\r\n";
$mailheader .= "Content-Transfer-Encoding: 7bit\r\n\r\n";

mail($email, "Order Confirmation for $customer", $html, $mailheader);


------------------------
No DOCTYPE found! Checking with default HTML 4.01 Transitional Document
Type.

No DOCTYPE Declaration could be found or recognized in this document.
This generally means that the document is not declaring its Document
Type at the top. It can also mean that the DOCTYPE declaration contains
a spelling error, or that it is not using the correct syntax.

The document was checked using a default "fallback" Document Type
Definition that closely resembles “HTML 4.01 Transitional”.
------------------------

I specified "Content-Type: text/html; charset=us-ascii"
in the email header, I guess it needs to be in the html header also
where I used the simplest possible "<html>" without any attributes. That
just seems crazy that any program would be incapacitated trying to
I have no idea what Mac e-mail clients do with invalid markup.


Still wondering how it looks to you in Outlook, Outlook Express, other
clients.

Simple table & plain text in Thunderbird & Firefox.

In Firefox it looks pretty rough (although that may be what you're happy
with; I don't mean to criticize). I don't coding gibberish in any case,
so maybe that's all you're worried about here.

I didn't want anything tricky, just the simplest most foolproof. No
fonts, no logos, just a very simple table.


I don't understand this comment.
'Classes' seemed to be beyond my abilities last time I looked up
something like that, sorry. I'm not a complete newbie, I use style
sheets & pay attention for web pages but this is just one table in an
email with everything else default.



--
Paul Furman
www.edgehill.net
www.baynatives.com

all google groups messages filtered due to spam
 
N

Neredbojias

Its far far worse than that. It uses the rendering engine from
...MICROSNOT WORD..

Not from IE7/8 etc etc.

It doesn't even recognise <DIV> as far as I can tell.

Damn, that does suck! Anyway, I've been using Mozilla's Thunderbird
for years and have had little problem with it, though, admittedly, I
usually have html mail-reception set to off. In regards to html mail,
what gurus typically recommend is sending a plain-text link to an html
mail "page" so-to-speak if you want fancy stuff. Might be a pain but
certainly allows for more versatility.
 
T

The Natural Philosopher

Neredbojias said:
Damn, that does suck! Anyway, I've been using Mozilla's Thunderbird
for years and have had little problem with it, though, admittedly, I
usually have html mail-reception set to off. In regards to html mail,
what gurus typically recommend is sending a plain-text link to an html
mail "page" so-to-speak if you want fancy stuff. Might be a pain but
certainly allows for more versatility.

yes..well my issue was that I wanted to send natty looking invoices and
delivery notes..which REALLY are not for public consumption. No URLS for
private info!


In the end I defaulted to a PDF attachment.
 
J

Jerry Stuckle

The said:
yes..well my issue was that I wanted to send natty looking invoices and
delivery notes..which REALLY are not for public consumption. No URLS for
private info!


In the end I defaulted to a PDF attachment.

So you sent it in plain text where anyone can intercept and read it,
instead of a secured server.

And you're concerned about security?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================
 
J

Jonathan N. Little

Paul Furman wrote:

I don't understand Mime <g> but I did it like this in php:

$mailheader = "MIME-Version: 1.0\r\n";
$mailheader .= "FROM: (e-mail address removed)\r\n";
$mailheader .= "CC: " . $mail_recipient . "\r\n";
$mailheader .= "Content-Type: text/html; charset=us-ascii\r\n";
$mailheader .= "Content-Transfer-Encoding: 7bit\r\n\r\n";
^^^^^^^
Try reducing to only 1 pair of "\r\n" and sometimes I noticed I had to
reduce the last line of the extra headers to just a single "\n" when the
content was base64 encoded. This maybe mailserver specific.

mail($email, "Order Confirmation for $customer", $html, $mailheader);
 
T

The Natural Philosopher

Jerry said:
So you sent it in plain text where anyone can intercept and read it,
instead of a secured server.

So Jerry, how many of these emails have you intercepted and read?

Go on, post one up?

Second point, reading ONE email is no big deal. You can look in a
persons trash can and read half a dozen if you care.

Its a lot EASIER though if you simply send a link to an unprotected
site where EVERYBODIES invoices for ever, are readable. But it ain't secure

And its useless if you send them an email that has a password in it,
because then its no more secure than the email is.

If you go the otherway, and say 'your invoice is avaialable for view
with their password being something they themselves generate, then that
requires that they have, and remember a password.

On a typical e-shopping site they wont: they may exist with a temporary
session ID, but they wont have any permanent secure access.

And of course, giving them permanent access meanss that potentially the
access is hackable which reduces security.


So once again you haven't been able to think the thing through logically.


And you're concerned about security?
Concerned enough to have thought teh thing through, and balanced risks
with ease of use, but them my goal is to actually achieve a commercial
operation, not to score points of someone who shows me up in a Usenet
willy waving contest.

Why don't you go back to patronizing newbies, jerry. Its the only thing
you are good at.
 
J

Jerry Stuckle

The said:
So Jerry, how many of these emails have you intercepted and read?

Go on, post one up?

Second point, reading ONE email is no big deal. You can look in a
persons trash can and read half a dozen if you care.

Its a lot EASIER though if you simply send a link to an unprotected
site where EVERYBODIES invoices for ever, are readable. But it ain't secure

And its useless if you send them an email that has a password in it,
because then its no more secure than the email is.

If you go the otherway, and say 'your invoice is avaialable for view
with their password being something they themselves generate, then that
requires that they have, and remember a password.

On a typical e-shopping site they wont: they may exist with a temporary
session ID, but they wont have any permanent secure access.

And of course, giving them permanent access meanss that potentially the
access is hackable which reduces security.


So once again you haven't been able to think the thing through logically.



Concerned enough to have thought teh thing through, and balanced risks
with ease of use, but them my goal is to actually achieve a commercial
operation, not to score points of someone who shows me up in a Usenet
willy waving contest.

Why don't you go back to patronizing newbies, jerry. Its the only thing
you are good at.

ROFLMAO! Spoken like someone completely clueless about any security.
But then you're completely clueless about ANYTHING resembling
programming, as we all know.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================
 
P

Paul Furman

Jonathan said:
Paul Furman wrote:


^^^^^^^
Try reducing to only 1 pair of "\r\n" and sometimes I noticed I had to
reduce the last line of the extra headers to just a single "\n" when the
content was base64 encoded. This maybe mailserver specific.

Thanks for the idea but that didn't fix it.

Turns out the remaining known proof of this bug is one rather old mac. I
think this is not a big issue. I just tried adding DOCTYPE to the html
and that didn't help either. I give up :-(

 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top