I am developing a dynamic mail forwarding component for a website.
The concept is that
- a user will send an email with arbitrary content to a special email address on the server
- based on the "to" and "subject" line content, the system will forward the email to a group of (external) email addresses that are pulled from a mysql database
I'm running on a shared webhost (Bluehost), so I don't think I have any advanced access to the mail infrastructure to do this for me (no .forward files, for example). The target email list is dynamic, so I can't use cPanel to set up static forwarding.
I have the incoming mail coming to a PHP script, but the processing looks challenging, especially for the MIME parts - multipart, attachments, etc. I have looked at the PEAR Mail / MIME stuff, but it seems overkill to completely decode and re-encode the msg...
Any tips?
I use phpMailer for sending email from PHP.
I implemented exactly the same concept in mod_perl a few years back. Be aware that much of your outgoing email will likely be blocked if you send a significant volume. And if your system can be hacked (and that sounds at least plausible), spammers may find it and use your system, which would then lead to all your outgoing email being blocked.
Sending email is more difficult than it should be (if considering only the tech) thanks to spam and spam filters. These days I often find it easier to write code which uses a third-party service to actually send the emails, feeding the addresses over an API. I've had good luck with MailChimp and Contactology APIs recently.
EDIT: as for the incoming email: If you weren't in a shared hosting situation, it wouldn't be that hard - simply capture it, strip the headers, and pipe it back out to a new address. I'd have to agree with Conrad I guess on that point -- a shared host PHP script seems like a rather sub-optimal environment to try and solve this problem. If you can't use system() to pipe it back out directly the the mail infrastructure, I think you do have to completely parse the incoming email and reassemble it.
Related
I´m using Drupal (PHP) and sometimes I use it to send email to some of my registered users (ie. using a contact form located inside their profile). This is very common in every CMS, PHP forum, etc.
The thing is that Drupal usually prints out a successful message when the email was sent, and not always the email is actually sent.
On the other hand, my hosting uses VHM panel with VPS servers.
From their control panel I can check all mail that goes from my server to the outside. In VHM it´s called "Mail Delivery Reports". That´s accurate enough, and I think most VPS control panel probably have some similar utility.
My question is: When Drupal tells me that the email has been sent, and I go to the Mail Delivery report on my hosting control panel, and it says that it has not been sent. Is that a PHP flaw?
Is there a way to get accurate reports within PHP?
Please excuse my grammar. It has been kinda difficult for me to actually get myself clear on what I mean in english.
UPDATE:
I´m not asking if the user reads the email, not even if it later on gets bounced, just to know if PHP has some accurate way to report if the email was sent.
I know there are some services offering that, but I´m just asking about PHP capabilities (and if that´s actually possible).
PHP responsibility is to give it to your specified transport method. (sendmail, smtp etc.) and tell you if the transport accepted it or not.
If you use sendmail (or postfix) what php tells you is that it has been queued for sending and nothing else. PHP doesn't know if it will be sent or not. unless you parse the queues and try to go from there.
No. It is impossible for PHP to track sent emails. That is not, never has been, and never will be, PHP's job.
PHP simply generates the email (e.g. builds the html) and then hands it over to a mail transfer agent. e.g. your local sendmail.
In a real-world equivalent, PHP is you walking an envelope down to the street corner and dropping it into the mailbox. If the letter disappears down the chute, PHP will report success. After that, actual DELIVERY of the mail is entirely out of PHP's hands.
Maybe the mailbox gets flattened by a drunk driver, maybe the pickup truck gets into a firey crash, maybe the postal sorting facility gets hit by a meteor, etc...
None of that is PHP's problem, and undetectable by PHP anyways. It walked down the street, it saw the letter disappear down the slots. Mission accomplished.
At best you could set the "return service requested" mail headers, which 99.99% of people will probably ignore or disallow, or embed a web-bug inside the email and hope that the recipient's mail client will actually load the bug.
I am going through my first steps on VPS management and configuration; been able to install PHP, mySql, phpMyAdmin, postfix, etc ... and migrate a Wordpress from an existing shared server to this VPS.
Sorry for my question being naive, but when testing postfix with the php mail function, I purposely sent the email with a "From" header which was not my own email address (don't worry, nothing serious).
Question is: the email was sent and received in my inbox as if it was sent by somebody else! Is it this easy to send a fake email with php and postfix? (of course, checking email headers reveals the truth).
How can I restrict my VPS from being able to send emails from arbitrary addresses?
Thank you.
The answer is "yes and now": it is easy to "fake" emails, though that actually is not faking at all. Please understand that the "From" and "To" addresses shown inside an email message are part of the messages content. From a technical point of view these addresses have nothing to do with from whom (from which account) that messages has been sent or to whom it is addressed. Those addresses (accounts) are specified on a completely different level.
In addition it is not up to the sending software to decide what is a valid message and what not, in terms of a message being genuine. That obviously would not make sense if you think about it. That is something that either the receiving side or the transmitting side have to make sure, here the email servers, especially the smtp servers accepting and routing messages.
And indeed this is the case: it is a question of your local smtp servers configuration if such a message is accepted for delivery or not. Most likely the message in your test case has been accepted because it originated from within your local network, or what the smtp server considers as your local network. For such messages typically other rules exist compared to routes received "from the outside" and this does make sense.
Further it is a well known fact that it is part of the responsibility of the smtp server administrators to make sure that their servers cannot be missused. The rules used for this are called "relaying rules", all current smtp server implementations offer configuration opions dealing with that issue.
In general you can say that
really "faking" an email is not that easy if you look at the details. If a receiver only looks at superficial details then indeed he can easily be fooled.
email is not at all a secure means of communication, it never has been and it never was meant to be. It is built on trust in general.
the only secure way to make sure that an email has indeed been sent by the party that is claimed as sender inside the message is by using "signed messages", by using a digital signature.
I have developed a CRM that is used with a marketing website similar to manta.com. The CRM has a built-in email client. Basically it matches names and emails to addresses on file, and if the email is from a customer it loads their account information next to the email.
The entire system works, but is in some cases slow. Because each "region" of the country is managed by a different company, the software connects to several different mail servers, all of which behave differently.
In some cases (mostly with godaddy servers) it takes a very long time to send an email. It also takes a long time to load the inbox if they have a lot of messages (500+), even if it is paged.
I am using pear Mail::Factory smtp to send, and the built in php imap functions to receive.
I am thinking for outgoing messages I will just store the emails into a db and then have a cron script send it out, then they can send their email and move on right away.
Does anyone have any ideas/concepts for handling large inboxes via IMAP and php? I will have no control over the mail servers themselves, but have full control over the server that the CRM is on.
I am not looking for code, just concepts if you have them.
It is Linux (ubuntu), apache, mysql, php. I can use Zend if needed.
It looks like a combination of caching the emails and using the imap_fetch_overview function which omits the body of the email. This seems to eliminate any issues with the lag. I can also use it to page the results so I am only loading a small number (25-50) at a time. Thanks for the help.
I would like to have a server that is able to receive emails. Then I want to use PHP to program the way the emails are shown to the users. Can I do it purely with PHP? I mean, it is not a problem to send emails from PHP but I do not know if I can receive emails by PHP? (In a way PHP receives POST requests).
ADDED
As a response to the first answer, I would like to specify that it looks like I need an SMTP server. I want to be able to communicate with the SMTP server in a programmatic way. For example, I want to have a possibility to "tell" to the SMTP server to create a new e-mail address. I also need to know where incoming emails stored and in what format. For example, how I can extract the "sender", "cc", "bcc" from the file corresponding to the received mail.
would like to have a sever that is able to receive e-mails.
If you are writing it from scratch then you'll need the specification for SMTP. I would advise very strongly against this. SMTP servers are hard to write, and there are several really good open source solutions out there.
My understanding of PHP is that it does very poorly when it comes to multithreading, so it probably isn't a good solution for this problem.
Than I want to use PHP to program the way the mails are shown to the users
Servers that receive mails do not typically show them to users. They usually store them in a standard way (such as Maildir or mbox) which other software (such as a local email client or an IMAP server) accesses.
The job of showing email to a user is belongs to email clients. Web based PHP web mail software includes SquirrelMail and RoundCube. AFAIK they both act as IMAP clients. See the IMAP specification.
As a response to the first answer, I would like to specify that it looks like I need a SMTP servers. I want to be able to communicate with the SMTP server in a programmatic way. For example, I want to have a possibility to "tell" to the SMTP server to create a new e-mail address.
Pick an SMTP server that runs on your OS. Read the instructions to find out how to configure delivery and accepted addresses. It usually comes down to manipulating text files.
I also need to know where incoming mails stored and in what format. For example, how I can extract the "sender", "cc", "bcc" from the file corresponding to the received mail.
Again. See the manual for the mailserver. Most will give you options about where to store the data and in what format.
Then you just need to decide if you are going to get PHP to dig into those directly, or use an IMAP server in between.
No, that is not easily possible. PHP is made for (stateless) http protocol, while a mail is sent in a conversation that is built up from various requests and responses.
It is possible to parse and process mails using PHP, but I would recommend installing a mailbox that you can read from PHP using POP3. Then, your PHP application can show and process mails from that mailbox.
I have a website that receives incoming emails via cloudmailin, adds the content to the database, and then sends a confirmation email back to the person who sent the email. Currently I'm using a php mail() function to send the reply, but it seems to take about 1.5 min to actually get to the user's inbox. Is there a way to make this more instantaneous? I'm currenly hosting the application on FatCow, and I'm sure it has to do with their mail server, but I don't really know much about how that works and am wondering if I have to change hosts to accomplish faster delivery times or if I can do anything about it without switching.
mail() is a black box. You're telling PHP to try sending a mail however the host has configured PHP to do so.
It's very likely that it's just calling sendmail in your case. It's also very likely that the mail queue on that machine isn't the fastest in the world. Shared hosting machines are often overloaded.
The very first thing you should do is ask your host about the mail delay. Perhaps something is wrong, and they can fix it. Or they might just tell you that a minute and a half is not a long time to wait.
There are lots of other options, mostly in the form of companies that provide an SMTP service to you. I can't recommend one, but I can recommend that you pop over to your favorite search engine and look for "smtp service." I've recently starting working with Amazon Simple Email Service. It's supposed to be fast and well-maintained, and it's certainly inexpensive.
All of those options are likely going to require some configuration changes on your end. For example, you'll want to set up custom DNS records (for DKIM and SPF) to ensure that mail from a third party provider isn't automatically flagged as spam.
Using SMTP with PHP is dead easy. There are plenty of mail generating options out there. My personal favorite is SwiftMailer. It even has a transport option for Amazon SES.
The final option, of course, is grabbing your own virtual private server or dedicated server, which will let you configure outgoing mail as you desire, at the cost of needing to know how to maintain that server.
Edit: Obligatory link to relevant Coding Horror post.