Line Breaks in OpenPGP (Using PEAR with drupal) - php

I am encrypting form submissions in drupal with Pear. The encryption//decryption is working fine, but line breaks are not working.
What I mean by that is, whether I use Enigma in thunderbird, or I use gpg4win, the message gets decrypted, but it looks like this:
Online Form = 1\r\nFirst Name: John\r\nLast Name: Smith\r\n
I have tried \n\n \r \r\n none of these seem to work.
So the question is how do I get line breaks to output properly after being decrypted.
(I'm using the drupal mail function sending plain text email with UTF-8 encoding, although I don't think this matters since the message is being decrypted)

Related

PHP Invalid quoted-printable sequence, malformed q encoding from Yahoo

I came across the following error in PHP generated by an email forwarded from a Yahoo account:
Notice: Unknown: Invalid quoted-printable sequence: =?UTF-8?Q?ck-off with Weekly Sale up to 90% off (errflg=3) in Unknown on line 0
I've spent hours researching this issue and decided to send myself the exact same output string in an email without having Yahoo involved. The original q-encoded text that decodes correctly:
=?UTF-8?Q?GOG_Forward=3A_Fw=3A_=F0=9F=98=89_A_great_Monday_kick-?= =?UTF-8?Q?off_with_Weekly_Sale_up_to_90=25_off?=
The malformed q-encoded text from Yahoo:
=?UTF-8?Q?GOG_Forward =?UTF-8?Q?ck-off_with_Weekly_Sale_up_to_90%_off?=
The correct string when decoded:
GOG Forward: Fw: 😉 A great Monday kick-off with Weekly Sale up to 90% off
Roundcube manages to decode both the normal and the malformed text though I'm not sure how and 25 megabytes is a bit much to dig through and I haven't been able to determine even where they're decoding subject headers.
How do I fix Yahoo's malformed version of q-encoding?
<?php
//These fail:
echo imap_mime_header_decode($mail_message_headers['Subject']);
echo quoted_printable_decode($mail_message_headers['Subject']);
?>
For clarification the imap_fetchstructure page clarifies the value 4 for encoding is Quoted-Printable / ENCQUOTEDPRINTABLE.
New Development
It turns out that for some reason Yahoo sends the subject twice for the same header, one malformed and the other is not. Here is the Subject header from the raw email:
Subject: =?UTF-8?Q?GOG_Forward:_Fw:_=F0=9F=98=89_A_great_Monday_ki?=
=?UTF-8?Q?ck-off_with_Weekly_Sale_up_to_90%_off?=
MIME-Version: 1.0
I created a solution that uses Roundcube's source code to decode the message.
I posted the code and demo:
You can see it here
Click the big play button to preview the extraction
Go to code tab to see the extracted Roundcube code that you could use for your project
Since you mentioned to not use classes in the example I extracted Roundcube's decode_mime_string() function from rube_mime, and a couple of things from rcube_charset such as $aliases, parse_charset(), and convert().
As far as decoding the malformed text from Yahoo:
=?UTF-8?Q?GOG_Forward =?UTF-8?Q?ck-off_with_Weekly_Sale_up_to_90%_off?=
Into this:
GOG Forward: Fw: 😉 A great Monday kick-off with Weekly Sale up to 90% off
It's impossible. There's not enough data in there. For example it's missing the "😉 A great Monday ki". Do you have the full source of the email address?

Stop Spanish characters from getting converted into html

I have seen this type of question asked multiple times and I've tried all the answers but had no luck so far;
The problem is when I try to send an email (I am using Zend Mail) with special characters in recipient name, it gets converted into html for e.g. A user is named Mateo Julián which gets replaced as Mateo Julián
I have tried html_entity_decode but had no success, added UTF-8 header and meta but they didn't work either. And one point to be noted is that I am facing this issue only while sending emails. Added UTF-8 also to mail object like this.
$mail = new Zend_Mail('UTF-8');
and it is called as
$mail->setBodyHtml($recipient_info['message'])
->setFrom($recipient_info["sender"]['email'],$recipient_info["sender"]['name'])
->addTo($recipient_info["receiver"]['email'],$blabla)// $blabla is the problem area where I send the name of recipient.
->setSubject($recipient_info['subject']);

PHP convert html special chars like accents to show properly

I have a simple web page where I get some data from $_POST that users input: comments, usernames, etc. And I send them to email and save them on database. My problem is what when I send to email, doesn't matter what client is, I only see gibberish. I tried declaring the meta tag in the emails with all iso 88xx, utf8, windows, etc., but with no success. Also tried a million examples of htmlentities(), all leading to the same thing... plain gibberish. (Althought the source code shows different things sometimes, the plain text never changes).
Example code:
if (isset($_POST['name'])) {
$name = htmlentities($_POST['name'], ENT_QUOTES);
}
A result of mail() of $name (Don Quijóte) would be something like this "Don Quijóte".
Sorry if this is a repost but I just can't get this working.
Have you tried setting the headers, something like...
// Always set content-type when sending HTML email
$headers = "MIME-Version: 1.0" . "\r\n";
$headers .= "Content-type:plain/text;charset=UTF-8" . "\r\n";
mail($to,$subject,$message,$headers);
This sets the encoding to UTF-8. More here:
http://www.w3schools.com/php/func_mail_mail.asp
It is surprisingly hard to send a mail in the right way. The error you get with Don Quijote is due to the fact that your string is in utf8 but it is showed with ISO8859 encoding. (That is why you get that weird A and a small 3.
I would recomend using php mailer You can get it here
It is way simpler to setup and it will be more efficient if you at some time in the future need to send out a lot of emails. (Because mail() opens and closes the connection on each call)
Also be aware that if you are using utf-8 everything should be with utf-8. Your database should be set to utf-8. You outputs to html and so on. Every step of the way you should be sure it is utf8.

Is there a way to change the encoding of the headers in SwiftMailer?

I'm using SwiftMailer to send emails but I have some codification problems with UTF-8 subjects. Swiftmailer uses QPHeaderEncoder as default to encode email headers and the safeMap looks like it has some problems with some UTF-8 French characters. One subject I use contains the word trouvé (found in French) and when the subject gets to the user it shows trouv.
I'd like to use something similar to the NativeQPContentEncoder that's available as content encoders but for headers there's only Base64 and Quoted Printable encoders.
Is there a way to fix this, maybe I'm doing something wrong so I paste the code I'm using here
$message = Swift_Message::newInstance()
// set encoding in 8 bit
->setEncoder(Swift_Encoding::get8BitEncoding())
// Give the message a subject
->setSubject($subject)
// Set the From address with an associative array
->setFrom(array($from => $niceFrom))
// Set the To addresses with an associative array
->setTo(array($to)) ;
Check if in your PHP configuration mbstring.func_overload option has any value other than 0. If yes, change it to 0, reload your webserver and try to send message again.
mbstring.func_overload overrides some string PHP functions and may lead to tricky bugs with UTF-8.
Personally I solved exactly this problem by disabling mbstring.func_overload.
First, make sure you know how is your subject string encoded. If it is not UTF-8 then utf8_encode() it.
Also, make sure you setCharset('utf-8') your message.

PHP _EOL not working when input to $message of mail() function

I'm using PHP _EOL when building the message body of my email but the line feeds are not getting through and the entire message body ends up one long line in the resultant email. This happens regardless of Multi-part or html only messages. Sending as text only it works fine, but of course I want to send Multi-part messages.... Any ideas?
Uhm. If there are no line breaks in your HTML email, it's probably because neither a \n nor a \r\n is a newline in HTML; a <br /> tag is.
I've never even used PHP_EOL before, but I wonder if it is set to the type of your server, not of the recipient. I don't see how a constant could be correct for all recipients, that doesn't make sense.
Usually '\n' is all that is needed... in some cases you may need '\r\n' depending on the protocol involved. What are you using to send the email? What are you using to view the email?

Categories