I have a Joomla website up and running and need to set up a simple contact form.
The problem is, whenever Joomla tries to send an email, the page will hang for about a minute before I get a response. The mail will ultimately be sent fine, but the delay is way too big. I've tried setting the outgoing mail setting to PHP Mail, Sendmail and an SMTP server, all with the same effect.
Curiously, if I edit components/com_contact/controllers/contact.php and replace the lines that send the mail with a simple call to mail(), everything works fine.
Using Joomla 1.6.5, CentOS5 with PHP 5.3.
Anyone experienced something similar? Thanks in advance!
(Also, is this a case for StackOverflow or ServerFault? It seems borderline!)
Updated: Narrowed this down to PHPMailer using uniqid to generate its boundary strings. It seems that on some platforms, uniqid (without the more_entropy flag) is extremely slow.
If anyone else ever comes across the same problem, edit libraries/phpmailer/phpmailer.php and in the first few lines of the CreateHeader() function, pass true as the second argument of uniqid(). Seems to have fixed it.
Narrowed this down to PHPMailer using uniqid to generate its boundary strings. It seems that on some platforms, uniqid (without the more_entropy flag) is extremely slow.
If anyone else ever comes across the same problem, edit libraries/phpmailer/phpmailer.php and in the first few lines of the CreateHeader() function, pass true as the second argument of uniqid(). Seems to have fixed it.
Related
I have a form on a webpage which emails the details using the PHP mail() function. The form is quite long, and I also am including HTML formatting for the email.
The email sends fine if I don't include all the form information, but when I try to include the whole form the email doesn't get sent. It seems to stop working when I'm including too much information. As soon as I take some of the information out it works again, and it doesn't matter which part of the information I remove.
I have tried the form on two different website hosts with the same problem. The content for the email is only about 300 lines long so I'm not sure if size is the issue.
Does anyone know what might be causing the problem?
here is my code for your reference
When I say "stop working" above, I mean simply that the mail() function returns false and does not send the email. The actual form works fine.
When you come to that amount of HTML within a PHP-script it is useful to catch it in a variable instead of putting every single line in a $body variable.
ob_start();
?>
<html>
Your HTML.
</html>
<?
$body = ob_get_clean();
This way you can easier see if there is something wrong with your message ruining the mail-function.
Here is a description of the php mail function. This document along with this document, What is the PHP Mail Character Limit, specifies that each line of the body must be no longer than 70 characters.
This stackoverflow, What is the maximum length of a string in PHP, as well as other sources indicate that PHP does not have a specific limit other than total memory limits which your string appears to be well under.
Also there are several different places where there could be a failure and you do not specify the behavior you are seeing for a failure.
First of all, check the return value of mail() to determine if PHP was able to hand the message off to the mail agent, the MTA. Next make sure that you specify good to and return addresses so that if there is a problem in the mail agent, it will be able to send you some kind of a reply describing the problem.
An elaboration of the answer provided by Undrium above. Here are some links to additional materials based on his answer.
Here is the ob_get_clean() documentation.
Here is an example using ob_get_clear() with sending HTML Email.
I was wondering if anyone here with experience of PEAR mail or PEAR mail queue could help me out with this.
I am working on creating a bulk mailing service using PEAR and am adding X-headers to give information on where and when people signed up.
So am am trying to create a X-header similar to this:
X-Subscription: Subscribed on 2010/09/01, via web form, by 92.8.196.121 from http://mydomain.com/signup.htm
However after I pass the headers to PEAR mail mime and queue they are formatted with a line break at certain points so they end up looking like this:
X-Subscription: Subscribed on 2010/09/01, via web form, by 92.8.196.121 from
http://mydomain.com/signup.htm
I have tested this by creating a few different headers and the line break always comes after a certain amount of characters but I cannot seem to find any code in PEAR which would cause this.
Does anyone here have any experience of this? Or know of a way I could fix this?
Thanks for looking
The "issue" of headers being split onto multiple lines is correct behavior according to RFC 822, section "3.1.1. LONG HEADER FIELDS":
For convenience, the field-body portion of this conceptual
entity can be split into a multiple-line representation; this
is called "folding". The general rule is that wherever there
may be linear-white-space (NOT simply LWSP-chars), a CRLF
immediately followed by AT LEAST one LWSP-char may instead be
inserted.
As described in What is the email subject length limit?, RFC 2822 suggests to keep a line length of 78.
I have created a small script that sends a multipart email via php the mail() (that has been a challenge in itself!).
When I test the script and send and email it all works fine, but when I try another address (one which has the same domain as the server) the email appears blank. All the content is there when you look at the raw code, but nothing displays.
I solved the problem by removing the doctype tag from the code and left everything bare coded.
I also noticed the php variable
$body=' (html code here) '
The whitespace after ' was causing the email to show up empty sometime... I'm not exactly sure why!
I have encountered a similar issue and it was because I had a website www.example.com sending an email to me#example.com but the web server and email servers were on different machines. I had to ask the host to sort it so that the website wouldn't try to route emails within the server itself.
I managed to sort this by changing my own code to instead using something a little more supported - phpMailer.
I found this very easy to use and install into my own code. Also giving me as much flexibility as I had with my original code.
I guess though this isn't sorting the original problem, but it did seem to sort on my code.
Designing forms has always been fun, but getting them to send email on the server side is another story. I have used various email scripts (dynaform,phpmailer, etc), and have experienced a ton of problems.
So here is the site I am working on: Contact On the Right. It is very basic: no validation, no required fields. I simply need anything that is entered to be sent back to me.
Does anyone know of any BASIC PHP form processing scripts, or have a few lines of code that would work here? I'm not a PHP guy, so I am struggling!
Thanks in advance.
I simply need anything that is entered
to be sent back to me.
<?php
mail('your#mail.here','Site feedback',implode("\n\n",$_POST));
header("Location: thankyou.html");
?>
you can add this tag into thankyou.html:
<META HTTP-EQUIV="REFRESH" CONTENT="5;URL=http://v2.ztmag.com/livedates.html">
it will get user back in 5 seconds
For simple and hard tasks (it does HTML mail) this library always served me well: PHPMailer
Depending on servers and administrators, sometimes mail() doesn't work.
It must be configured to work correctly with smtp or have a sendmail binary installed in the correct path.
PHPMailer, instead, only needs outbound connection trough fsockopen not to be disabled.
A simple tutorial here:
http://www.ustrem.org/en/articles/send-mail-using-phpmailer-en/
A number of CMS uses it internally, too. Joomla, for example.
Folks,
I have a PHP-based site (using the QCubed framework); as a part of the site, I have a daemon that's sending out several thousand emails a day (no i'm not a spammer, everything is opt-in :)). Emails are sent through a custom framework component; that component serves as an SMTP client. I'm using a paid SMTP gateway from DNSExit.com to get the emails actually delivered.
Those emails are simple HTML-based emails; they really have just simple links inside.
My issue is that these links sometimes (not consistently!) get scrambled during transition. Tags somehow get mixed up, and some links are non-functional in the email. The issue happens on a small percentage of all sent emails; it is not consistent (i.e. the same exact source message HTML may or may not cause the scrambling in transition).
Have any of you seen this? Any thoughts on how to troubleshoot?
Is it possible that you are using temp files to create the emails (or at minimum to create the variable content)? I did something vaguely similar once upon a time. The email text was generated and written to a temp file based on the exact time in seconds. Unfortunately, when sending thousands per day, we were hitting the same second more than once (since there are only 86k seconds available). That might explain a) the small error rate and b) the apparent randomness. For troubleshooting, I'd just see if the error rate increases with the number of emails and go from there.
I ran into a similar problem on a server running sendmail.
I was creating and testing an html email that would one day be mass mailed (opt-in, of course). I had myself a template for the email that was easy for any html programmer to read, but as such was heavy on the whitespace to line everything up correctly. I thought to myself, if this is going to be mass emailed, after the template is rendered, I think I will minimize the whitespace in the file to save on space! So I created a brilliant regular expression to rid any unnecessary to send whitespace from the rendered email.
Upon sending the email to myself, I opened the email and was baffled when I saw that some of the css and html were not showing up correctly, when my previous emails prior to my regexp were. By looking at the original message I noticed that every once in a while, an exclamation mark (!) was appearing seemingly randomly throughout the message, thus breaking any css and html that came in its random path.
Turns out that sendmail doesn't like it if a line in your email gets too long without a line break. When the line does get too long, sendmail will insert an exclamation mark followed by a line break right then and there, just to confuse and confound you.
Why did it not just choose a space between words to line break? Why insert the exclamation mark? Questions I'm afraid, without answers.
My solution?
sudo apt-get remove sendmail
sudo apt-get install exim4
I was having other problems with sendmail like it taking a full 60 seconds to send an email and exim4 just worked and I have never had to think about it again.
If your mail server is using sendmail, this very well could be the problem, if not, thank you for letting me share my story with you. I needed to vent.
When you're sending email you should encode it so every line in the message body is not longer then 76 characters. You could use base64 for this but most systems use the
quoted-printable encoding for text because it generates smaller messages.
Base64 is usually only used for binary data.
The problem is that HTML is not compatible with email. That is why I created Mail Markup Language.
HTML was created to operate with the HTTP protocol as those two technologies were invented by the same person at about the same time. The difference is that HTTP is a single session one way transfer from a server to a client. That never changes as the HTML document always originates on a server, is sent to a requesting client, and once the transfer completes the connection between the client and server is dropped.
Email does not behave in such a way. In email a communication originates at a client, is sent to one or more email serves, and then terminates at a distant client. The biggest difference, however, is that the document does not die with finality of a single transmission instance as is the case with a document transfer over HTTP. A document sent in SMTP can be replied to, forwarded, or copied to multiple unrequested users. This one difference is profound when consideration for an email thread is considered.
The problem is that SMTP and HTTP are different as demonstrated in the prior two paragraphs. This differences is compounded in that SMTP and HTTP have radically different formatting methods for the creation of header data. HTML has header data that is intended to be compatible with the headers of HTTP transmissions and offer no compliance to SMTP transmissions. The HTML headers also do not account for the complexity of an email thread.
The problem is exemplified when email software corrupts a HTML document to add formatting changes necessary to fit the conforming demands of that software and to also write header data directly into the document. This exemplification becomes extremely pronounced when an HTML email becomes an email thread. Since the HTML header data has no method to account for the complexities of an email thread there is no way to supply relevant presentation definitions from a stylesheet that survive the transfer of the document. Each time a HTML document, or a document with HTML formatting, is sent from one email software to another the document is corrupted and each email software device corrupts the prior corruption. Email processing software may refer to either an email client, which certainly will corrupt a document, or an email server, that may only likely corrupt an email document.
The solution to the problem is to create a markup language convention that recognizes the requirements of email header data directly. Those requirements are defined in RFC 5321 for the SMTP protocol and RFC 5322 for the client processing. The only way to properly extend this solution to account for the complexities of an email thread are to provide a convention for a multi-agent DOM.
Paragraphs deleted due to technical inaccuracy and difference between the term multi-agent DOM and the nature of an invented feature not mentioned here even prior to the edit.
EDIT: a multi-agent DOM applies some degree of hierarchy, which may not be necessary to represent an email thread.
Had 2 problems with email data - usually "?" symbol somehow got inside some words, another was UTF and title related. First got "fixed" by changing hosting provider (so it was mail-server related) second one got fixed by changing PHPmailer library.
Try to specify how exactly data is scrambled.
Have you any special attributes in your links? May be title attribute with not escaped quotes inside?
Something like this: Link