we build newsletter module,
and send email to members.
The environment is LAMP.
Are there any way to know whether member open the mail ?
i hear about put image if 'php' source ,
what is the best way?
Ultimately there is obviously no fool-proof way to get notifications, because there is no guaranteed way of getting the email client to respond back in some fashion; the email client can be set up to just interpret the incoming email as ASCII text and nothing more, and there is nothing you can do about that.
However; in most cases if you are emailing to users that are expecting an email, odds are that HTML rendering and inline images are probably turned on for your source address, so using an inline IMG tag and monitoring access to the referenced file (obviously using some per-user unique ID in the reference) should give you the best you are going to get.
Regardless you'll never be able to make the assumption that if you do not get a notification back that that means the user has not seen the email.
There's no foolproof way to do it since you're not the one in control of the email client. Many people take their privacy seriously enough to prevent read-receipts, web beacons and all the other tricks which can be used to detect the reading (people can turn off read receipts, block images, prevent unsolicited outgoing connections and so on).
This is my opinion of course but I believe you're approaching the problem the wrong way. Instead of trying to force the user to let you know if they've read the email, just make it worth their while. It's obviously of some benefit to you to have this information (otherwise why do it?) so you share that benefit around and make sure it's the user's decision.
That way, you turn the relationship from a battleground into a partnership (win/win).
Yes, there is a standard mechanism (RFC 3798) called read receipts. It is implemented by all modern mail clients, and the user can choose to send (or not) the reciept as they choose.
There are also various non-standard subterfuges for doing this without the user's consent, which I won't detail.
EDIT:
It should be like the below (using built-in PHP mail function):
mail("foo#foo.com", "Let me know if you get this", "Important message", "Disposition-Notification-To: sender#sender.com\r\n");
A common way to check if an email has been read is a web beacon, which is usually a small 1x1px invisible image that is loaded from your server, which can track when the image has been loaded and therefore the email has been read.
This is not guaranteed to work, however, since many email clients block images in their emails or your readers could be using text-only email clients.
Each email has a uniquely named image in it corresponding to the users account (or db row), when that image is loaded or accessed, you can see which user has opened the email. This relies on the user receiving HTML emails though.
Related
Say I have my own server, and I want to send an email that's reads "hello World" to my site, submit#example.com
Is there a way to automatically extract the text "hello world" and post the content to my website?
I believe I can read a file with PHP, and the file can be created by apache for every incoming email... but I'm missing some knowledge here
can anybody help me?
You need to have PHP act as an email client. Take a look at PHP IMAP (which actually works for POP too) http://php.net/manual/en/intro.imap.php
While emails are almost always stored on disk as files, accessing those files directly would not be advisable unless you were writing a new email server (I've contemplated that actually, but it is definitely NOT a trivial task) and your web server (e.g., PHP running in Apache) wouldn't have that level of access. The basic steps the right way are:
Add the email account, set the password, etc. Decide whether you want to access it as IMAP (emails stick around unless you delete and then empty the trash, which lets you archive on the server and/or access from other devices) or POP (typically "read the emails and delete from the server immediately").
Write PHP code to read the mail account. The specifics will vary slightly depending on the email server/hosting configuration. You may need to work at it a bit until you can successfully read a list of messages.
Once you are able to read the messages, you will likely need to handle multiple formats. In particular, messages may come in as plain text or as mime parts. There can be quite a bit of variation depending on the software used to write the original message, so to test you may want to send in messages using Outlook, Thunderbird and other programs.
You will also likely need to filter out HTML tags and other extraneous stuff from legitimate messages AND you will inevitably have to come up with a way to block spam. If you only accept messages from registered users then you can verify based on the From: address (at least as a start, because that can be spoofed too...) but if the support email address is "open" then filtering the junk can be quite a challenge.
This is a non-trivial project, but I have successfully set up a few systems of this type, though typically with controls to help block spam (e.g., required codes in the Subject line; limited "From" addresses).
Our web-based PHP software currently sends out a newsletter to anywhere between 1-2000 recipients. Often the newsletter has a PDF attachment (15KB-5MB). The newsletter does not need to be customized to the individual recipients.
Question: Is it better to send one e-mail that has each recipient blind carbon copied (BCC) or to generate a unique e-mail message for each recipient?
Considerations:
- Which option puts less stress on the mail transfer agent?
- Which option is more efficient programmatically?
- Which option is less resource intensive?
- Are there any limitations to either option? (e.g. BCC having a maximum number)
I've tried Google and I just can't find anyone that has a definitive opinion based on empirical evidence. It's actually hard to find anyone that has an opinion at all.
THANKS: To everyone who contributed to answering this question. Greatly appreciate the feedback from people to ensure we're doing things properly!
Generate a single email per recipient. Use the To field instead of BCC to make it personal.
Advantages
The mail queue will accurately reflect what is happening.
You can distribute the load to multiple email servers.
You can personalize the "To" "Subject" "Body" etc.
You can use tracking URL's.
Mail servers often have a BCC limit per message. You will not hit a limit if you send a single message at a time.
BCC emails typically remain in the queue until all deliveries are complete. It is rare, but we have experienced (with the latest qmail) that sometimes a single recipient will respond with an error that confuses the mail server to send it again, fail, again, fail...until we remove it from the queue. This gets people very upset.
Disadvantages
PHP script has to work harder to generate the individual requests.
There are surely other advantages and disadvantages, but that is the list I follow.
UPDATE: Regarding the PDF attachment, I would recommend providing a download link unless it is crucial to include it with the email.
PDF attachments make an email look more suspicious to spam/virus scanners, because spam is known to try to exploit vulnerable versions of Acrobat. Those PDF attachments might make your newsletter more likely to end up in the recipient's Spam folder.
Large PDF's (1+mb) are not friendly to people checking their email with slow connections or constrained devices such as smartphones.
A link is much smaller than the attachment. You will save upwards to 13GB of bandwidth if you leave off that 5MB attachment!
It depends on MTA infrastructure at your site. If the box that is running your web app is set up to forward all e-mails to some e-mail hub at your ISP then BCC is definitely the advantage. Otherwise, it may save some bandwidth for you but not necessarily (it depends on the actual addresses you send to) Also, I would recommend you not to attach the pdf to the message but place it on the web server and include hyperlink in e-mail. As I got your message is a bulk message. I believe that many people do not read your messages even they opted in to receive.
Instead of attaching such a large file (which might also be rejected by some MTAs because of the size) upload it somewhere on a publicly accessible place (i.e. a web server) and send a simple link to all of the email recipients which they can use to view the PDF.
The good thing about this approach is that you save loads of bandwidth and even if you need different PDFs for every recipient you could still use it.
I have a site that will display a large number of members publicly with their contact info. It is a bad idea to simply spit their emails up on the page in HTML due to spamming, etc., right?
So I am sure there a a thousand ways to deal with this. And I have seen recommendations ranging from using "name[at]blah[dot]com" (which just doesn't seem that much more secure). I guess the logical step would be to utilize phpmail or swiftmailer or something along those lines? Both look like they are right at the edge of my PHP skills and would cause me some headaching before I could get them to work right.
Is there an easier solution? Can anyone suggest one with the best simple-to-effective ratio?
I am grabbing the info from member-entered SQL data.
The better solution to displaying their emails or creating a mailto: link would be to add a "Click Here to Email" button that gives the user a simple form (From address, Subject, Body). When this form is posted, create the email server-side and send it to the recipient.
If you implement the above system, do not simply output the recipient's email address into a hidden input field. Instead, write out a unique identifier and then look up the email address on the backend. This way, the recipient's address is never available to be scraped by a bot or malicious user.
What do you want: send a mail or display mail? If send, use PHP's mail function, it's easy to use, won't cause headache. If you want to display only, first consider if you really need to display. If you really need, then either replace # and . with [] or something like this - not sure whether robots know this or not or even safer: display them only on click via AJAX and PHP. Spambots and mail-collecting-bots cannot click.
For our friends-site I want to create a function where I, and my friends, can send an email to a special emailadres: weblog#domain.com. I want to use the given subject as the blog-title and the mail-body to be the blog-entry. The timestamp the mail was sent must become the timestamp the blog is saved (at least this timestamp must be stored in the database) and only a specified set of mailaddress can be handled (so it's not a public service).
But I don't have a clue how to do this. Are things like this done by cronjobs and imap or something? I'm collecting thoughts on how to realize this. I'm not asking you to provide a fully working code but some suggestions on the requirements would be nice.
A cronjob logs into the email address, downloads any mail, and posts it according to time stamp.
You will need:
Secret email address. Be sure it's secret because anything that gets sent will get posted
Blogging engine that you can either manipulate externally, have a decent idea of what the database schema looks like, or are willing to hack into.
Competent scripting skills
Cronjobs are particularly easy to setup. I was surprised myself at how simplistic it is. Decent tutorial.
I have a classifieds website, and on each classifieds page, there is a form for tipping a friend where you just enter the persons email-adress and the tip will then be sent. The form is submitted to tip.php where all "magic" happens with checking and sanitizing etc etc...
Lastly I use php:s mail() function to send the email from tip.php...
Now, I wouldn't want spam-bots and automated robots etc to send mail and blacklist my server.
What should I do?
One method which I would rather NOT use is logging IP:adresses of senders in a table (MySql) and then allow only x emails per sender.
As I said, the above solution is nothing I would prefer, there must be an easier way.
Is there any method you know of?
Is there any application to install maybe, on a linux server which does the job?
Thanks
I would say that the most used method would be captcha. This will ensure that the one that sends the email is a man, but everything can be cracked. So I would recommend to find a really good one, just type captcha into google and you are good to go. Also you can use another method/thing to make it more viable, e.g. some question that can be answered a simple mathematical problem, etc.
I think you should do something in the form which makes it difficult for robots to submit rubbish into it.
Either a piece of Javascript which robots don't run (Hint: The usually don't) or if you MUST, a captcha.
You should definitely monitor the use of this facility, as well as monitoring outbound messages, message queues, and watch for bounced mail though.
Quite a lot of web spam seems to come from humans who are paid to submit rubbish into peoples' forms, which is difficult to block.
You can of course, also use something like Akismet - an API where you can ask them to spam-scan form input; I'm sure its licence terms are very reasonable and if spam is a real problem, paying for it will be acceptable to management (using Akismet is much cheaper than paying expensive developers to write and maintain an in-house anti-spam system)
Unless its a paid for service or you can restrict the recipients to a pre-approved list and can establish the bona fides of the users I would strongly recommend you don't do this. However...
Do have a look at spamassassin - but remember that one of its most important metrics is the Bayesian filtering engine - which needs to be trained using heuristics (but you can run spamassassin for your incoming mail and copy the database to your webserver).
Do make sure that you only allow authenticated customers (with an authenticated email) to use the facility, and limit the rate at which they can send messages (and the number of recipients) using a dead-man's lever.
C.