I'm trying to send an appointment to Lotus Notes, I am able to send something but not all headers are consider in my mail. At first I found that it is not allowed to use '' in header name so I found that if I will use '-' instead of '' the server will send the email with the '_' at the end. This I had to use in case when I want to set header '_ViewIcon'.
Now I have another problem. Some Lotus headers start with dolar, like '$Abstract' ... But when I set this header using PHPMailer I will get on the Lotus side instead of $Abstract the $24Abstract.
So I can to do if these chars are not allowed for RFC 822 ? How can I send a correct appointment to Lotus Notes.
With PHP Mailer I'm using these headers:
$mail->AddCustomHeader("\$PublicAccess: 1");
$mail->AddCustomHeader("-ViewIcon: 148");
But in the Lotus when I open detail of email I can see:
$24PublicAccess.
Solution:
I find out the solution which is helpful for me. The special characters like $,_,-,... are not allowed only for header name. So I send from Lotus Notes appointment to my GMail and then I open the source of mail from GMail. I found many Lotus headers with this format:
X-Lotus-Item: 1; name=$PublicAccess; type=300
// and type=300 means number I think
So when I rewrite all my headers into this format, it's working now!
I can setup all headers which contains $ or any other special character.
try with simple quote and without a backslash
$mail->AddCustomHeader('$PublicAccess: 1');
Related
I have read the following comment in the official documentation of php about mail() function:
Although it is not documented, for the parameters $to and $subject the mail() function changes at least \r and \n to space. So these parameters are safe against injection of additional headers. But you might want to check $to for commas as these separate multiple addresses and you might not want to send to more than one recipient.
Is it correct? Also, I have always considered the $message parameter safe against injection, is it also correct?
I know how to protect myself against injection, I just want to know if I can avoid to filter those parameters.
Yes, that's true, but it's also incomplete. In the engine source code, the function php_mail_build_headers ensures headers comply with RFC 2822 § 3.6 requirements for maximum number of values. Particularly, the following headers are checked for single value:
orig-date
from
sender
reply-to
to
bcc
message-id
in-reply-to
subject
Yes, the message parameter is safe from header injection by definition: the message part is inserted after the separating new line between headers and body, so any header-like text inserted as part of the message will appear as literal text within the message body.
For your comment that you don't want to apply those filters.
I think you can get it done automatically by using Zend_Mail as I commented.
$ composer require zendframework/zend-mail
I'm pasting this from their documentation:
use Zend\Mail\Message;
use Zend\Mail\Transport\Sendmail as SendmailTransport;
$message = new Message();
$message->addTo('matthew#example.org');
$message->addFrom('ralph#example.org');
$message->setSubject('Greetings and Salutations!');
$message->setBody("Sorry, I'm going to be late today!");
$transport = new SendmailTransport();
$transport->send($message);
Im using php's mail() function to send an e-mail to multiple receivers.
If i enter as the first parameter of the "mail" function something like "example1#example.com,example2#example.com,example3#example.com,example4#example.com,example5#example.com,example6#example.com........" a string of more than 1000 characters, when I receive the e-mail I see a " "(an empty space) being inserted at about the 995th character and whatever e-mail was at that position is broken.
I read that this is because the mail server doesn't accept very long lines of string so you should insert a "\n" at every 70 or so characters.
Therefore, I tried using wordwrap($emailList) that should insert line-breaks.
Unfortunately this doesn't solve my problem and I'm running out of ideas right now.
Finally I was able to solve this problem like this:
I have the to list in a $strTo variable which contains the emails like this "email1, email2, email3, email4, "... with each email separated by ", " .
Before doing the mail() function I did this:
if($strTo != ""){
$strTo = wordwrap($strTo,900,"\r\n ");
$strTo .= "\r\n";
}
Which means I put carriage return, new line and a white space at every 900 characters(without breaking any words) and finally, at the end of the string I inserta carriage return and line feed.
wordwrap did not work for me. I guess it depends upon whether your mail server honor it or not. Also in my case the fold was occurring every 998th character.
I was able to solve using multiple 'To:' fields in message header. e.g.
header = <<EOF
From: xyz#xyz.com
To: abc1#abc.com, abc2#abc.com, abc3#abc.com, ...abc100#abc.com
CC: prq1#prq.com
Subject: 'my subject'
EOF
constructed multiple arrays of 20 each using array.each_slice(20). Then formed the header such that
header = <<EOF
From: xyz#xyz.com
To: abc1#abc.com, abc2#abc.com, abc3#abc.com, ...abc20#abc.com
To: abc21#abc.com, abc22#abc.com, abc23#abc.com, ...abc30#abc.com
To: abc31#abc.com, abc32#abc.com, abc33#abc.com, ...abc40#abc.com
CC: prq1#prq.com
Subject: 'my subject'
EOF
my mail server honored it.
I have a strange issue with encoding, described as follows:
the ù is now shown as ù in the email subject. The email is sent through php mail function.
When viewing the e-mail in the mailbox, it is shown correctly. However, when anybody opens the e-mail, the ù is suddenly changed to ù.
Uw contact met Meeùs
should be
Uw contact met Meeùs
i have already used the encoding.
$emailsubject contains the above mentioned email subject.
$subject=$emailsubject;
$subject=$emailsubject;
$email_message=new email_message_class;
$email_message->SetEncodedEmailHeader("To",$to_address,$to_name);
$email_message->SetEncodedEmailHeader("From",$from_address,$from_name);
$email_message->SetEncodedEmailHeader("Reply-To",$reply_address,$reply_name);
$email_message->SetHeader("Sender",$from_address);
$email_message->SetEncodedHeader("Subject",$subject,"UTF-8");
In localhost it is working properly, but in the webserver it is not working properly. In webserver also encoding is set to utf-8 by default.
What i am doing wrong?
Thanks in advance.
Your code is correct absolutely there is no error in it but its other things failing encoding. As I need message source headers and message to tell you exactly what is happening? I have further no information about are you sending the email as plain text or HTML. But there are generally two issue which are:
Missing Mime-Version
Reason for showing the character wrongly is developers forget to describe the message as MIME Version. if the message is missing the "Mime-Version" header that Internet mail standards require, Webmail will ignore the "charset" header completely, garbling the message unless it's already in the UTF-8 character set.
Showing Subject with Special Characters
As you want to show the subject with utf-8 encoding then you must encode the subject as:
//Setting the Language as Japan
mb_language("ja");
//Converting the string into Japan Encoding
$subject = mb_convert_encoding($subject, "ISO-2022-JP","AUTO");
//Now convert the string to MIME Header type
$subject = mb_encode_mimeheader($subject);
If the above mentioned things doesn't resolve the problem then request you post the RAW Headers of the Email as it will help in better way to resolve issue.
Are you test to change the charset with .htaccess ?
AddDefaultCharset UTF-8
Since you indicate in the comments you are using Joomla 1.5, it seems there is an issue with the phpmailer() library in that version that forces the character set of the mailer—on the message—to send things out using the character set setting of iso-8559-1. To fix this open up the core phpmailer() libary here:
[path to your Joomla install]/libraries/phpmailer/phpmailer.php
Around line 50 there is a setting called $CharSet. Change that to utf-8 if it’s not set to that already:
/**
* Sets the CharSet of the message.
* #var string
*/
var $CharSet = 'utf-8';
You might also want to do search of your Joomla 1.5 codebase for iso-8559-1 to see if a component or library is forcing iso-8559-1 encoding somewhere in the chain of code.
And another setting I would recommend checking is $Encoding around line 63. The default setting seems to be 8bit, but I have had to adjust that in the past to either quoted-printable or base64 to solve some mailing issues on specific setups I was working on.
/**
* Sets the Encoding of the message. Options for this are "8bit",
* "7bit", "binary", "base64", and "quoted-printable".
* #var string
*/
var $Encoding = '8bit';
I suggest you to use joomla mailer class, the could would look like this:
$mailer = JFactory::getMailer();
$mailer->setSender(array($from_address,$from_name));
$mailer->addRecipient($to_address, $to_name);
$mailer->setSubject($subject);
$mailer->setBody("BODY MESSAGE STRING");
$mailer->Send();
It's utf8 by default, and i don't see any reasons for not to use it, if you're using Joomla.
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.
Zend Mail throws an exception (because mail() returns false) when the to name is set to something with both a foreign character (like "å") and a comma (","). Re-produce with code below.
$mail = new Zend_Mail('utf-8');
$mail
->setFrom('info#myhost', 'My company')
->setSubject('hi')
->addTo('MYEMAIL#SOMEHOST.COM', 'aå,a')
->setBodyHtml('<p>asd</p>')
->send();
If I change the addTo call to something of the below, no error occurs.
->addTo('znarkus#gmail.com', 'aåa')
->addTo('znarkus#gmail.com', 'a,a')
->addTo('znarkus#gmail.com', 'aa')
The weird thing is, even though it throws an exception ("Unable to send mail"), the mail is delivered. I'm running the latest Zend Mail (1.9.5?). Please halp!
It's just a bug in Zend_Framework:
http://framework.zend.com/issues/browse/ZF-10792
a comma is allowed in the name part of the e-mail:
"Smith, Frank"
this is okay
The problem is that mail() function for $to accepts
User <user#example.com>, Another User <anotheruser#example.com>
and I guess that PHP internally splits the string on commas to separate multiple recipients but you are providing only one email address.
If you think this is a Zend_Mail, or PHP bug you should post this to the appropriate issue tracker.
The comma is a reserved literal in the "to" part of a mail header (and you should never use it though), separating different targets. Even if your "first" mail gets sent, imho it creates a header like this:
aå, a <znarkus#gmail.com>
With this header i assume your mta tries to send two mails: one to aå, which fails (badly), and a second one to znarkus#gmail.com, which should make its way.
You could try to look into the mail headers to confirm this theory.