I personally can't see a way to do this, but I'm hoping there could be a clever hack to make it work.
We have to send out regular emails to customers, many of who's emails expire and give us a mail delivery failure. To keep the database accurate and clean, I'd like to delete their record from the database when an email fails to be sent to them.
So currently it goes a little something like this:
<cfloop query="rsCustomers">
<cftry>
<cfmail to="rsCustomers.Email" from="us#ourcompany.com" failto="fails#ourcompany.com" subject="Whatever">
[email text here]
</cfmail>
<cfcatch type="any">
<!--- just to skip this record when it fails to send --->
</cfcatch>
</cftry>
</cfloop>
I could run a query within the catch area to delete records when there was an error in the record (e.g. malformed email address). But nothing happens when the mail is undeliverable. I get a failure notice to my inbox but these can be in the hundreds so its difficult to manually go through and delete from the database.
Is there anyway to "catch" the failed to send emails and then feed them back in to a query to delete from the database?
Someone once did a presentation on this at a function I attended. The approach was:
when sending mail, use a special email address in the failto attribute.
write a .cfm file that uses the cfpop tag to read mail sent to this address. (This may have been before the cfexchange tag was available)
add code that reads Delivery Failure Notfications and extracts the email addresses.
do something about those addresses
The presenter ran this file as a scheduled job.
#Dan Bracuk's answer above is the closest thing to a good answer you're probably going to get. Here's why: The CF server isn't delivering the mail, per-se. It's just handing the mailpiece off to a real mail server (even if that server runs on the same machine) for delivery. After it's accepted, CF's job is done. Non-delivery at this stage does not reflect on the quality of the address anyway, but rather the connection between your CF server and the mail server.
From there, it's spooled again, by the mail server. Sometimes a recipient's domain will accept email and ask questions later. The only way to know if an email delivery has failed is to wait for a Non-Delivery Report (email) to be sent to the failto (if used) or from address. This can come from "your" mail server, or a mail server for the recipient's domain. Depending on your mail server delivery retry options and third-party delays, this can take a day or more. If you want to do this yourself, you'll have to write a routine to POP and read the email from the account(s), and analyze them to determine if they are NDRs, and what type. Non-delivery Reports can indicate hard or soft bounces, blocks, delays, or gateway conditions. Obviously, many of these are not "throw it out" situations, so you'll have to parse them for SMTP codes http://www.serversmtp.com/en/smtp-error and keywords to determine if you should drop or mark the email address.
Related
I am sending email from application. My problem is when your type email address means format is correct but it may be not available anywhere.so when I am trying send such email address using SMTP through application, so how to track fail-over notification if intended recipient not found.
please suggest any approach.
There is no standard way of doing this. You might be able to make it work in some cases by parsing incoming email looking for delivery failure notices but it'll be a lot of work to keep that parsing code up to date. So at best you'll only get some of the notices. If you get a notice at all. The recipient's SMTP server may not send you anything, or the notice might get lost on it's way back to you.
The only way you are reliably get this sort of information is to host the SMTP server yourself, and deliver directly to the recipients SMTP server. In that case the SMTP server knows the status of the email's delivery and could report that to your email client via some non-standard back channel.
Note: Hosting your own SMTP server is non-trivial. And you will probably need to be on a fixed IP otherwise external SMTP servers will treat your email as spam. In case you're thinking of running one over a home connection or something.
Given there is a "FAILTO=''" option for cfmail, triggering an email to be sent to that email if the email didn't get delivered...
Is there a way to somehow assign an ID or tracking # to an email, store it in a database with that ID... then update the status of that email if it fails?
I'd like to track bouncebacks... preferably WITHOUT sending the FAILTO to a POP3 or IMAP and then checking it with cfimap...
Is there any alternate way of handling this?
Maybe an event gateway that is triggered upon email failure?
UPDATE: I've decided to take a different approach, utilizing the sendgrid API.
I'm hoping that lends me with a few more tools than CF offers.
The short answer to your question is unfortunately no.
A longer version with a possible solution:
The failTo email address populates the return-path in the email header, this then 'should' be used by mail servers for bounce backs (however see - http://www.bennadel.com/blog/1899-GMail-Seems-To-Ignore-The-Return-Path-Header-Defined-By-The-CFMail-FailTo-Attribute.htm for an example where it doesn't)
So you are going to need to monitor an Imap or pop account to see your mails, however you can set up an event gateway to monitor this, with detailed instructions here - http://www.alagad.com/documentation/imapGateway/ImapWatcher%20Gateway%20Documentation.pdf
What you're left with is needing to identify which mail matches which bounceback, when I've done something similar in the past I used unique id's for the failTo email addresses at a domain I owned. If you set that up and then use your listener cfc to look for the id in the return-path.
So your sending code would work along the lines of:
Generate unique id
Send mail
Add row to database with unique id
Your listener.cfc would then need to inspect the email returned and if it finds the unique id update the row with whatever information that you're after.
Hope that that at least helps even if you'll need to set up some other bits.
You could use a directly watcher on the undelivr folder to log the failed emails, only really a solution if its own server and not a shared server though.
As far as I know once it leave the spool and is off to your SMTP server CF assume it's been sent correctly.
The email will trickle down the chain of SMTP servers/relays and if anything happen the only instruction they have is to bounce it back to the from address or failto address if present. CF isn't listening at this point so it can't respond.
We use an external tool called Glock email processor to handle exceptions. It's not free, but works pretty well. You can find it here: http://www.glocksoft.com/email-processor/
You need to configure it to check the failto address and from there you can take many actions. I got it setup as a three strikes system.
Email address bounce, I increment a counter in my email table, at 3 I deactivate that email from the system.
Nothing you can't do yourself with cfpop though.
I'm sending newsletter using Zend Mail. I have used setReturnPath() to put all undelivered mail notifications in one place.
And what now?
How to get the list of addresses which were unreachable?
How do I read and parse the returned notifications?
How to know whether the mail returned because of non existing email or just quota exceeded?
Which headers do I need to send and check?
Related:
Variable Envelope Return Pathwiki
Handling undelivered emails in web appso
This class may be helpful. Can determine whether the mail is a bounce and return a response code with description:
http://www.phpclasses.org/package/2691-PHP-Parse-bounced-e-mail-message-reports.html
Short Answer:
you can't do that in a simple way and not in your app.
Long Answer:
You should handle that in asynchronous way and outside your php app (at least in part). First of all you must setup the return address to something like sender+recipient=recipientdomain.com#senderdomain.com as in the TimB answer. At this point all the notification sent by receiving smtp server will go to that address.
Then you need to setup the smtp daemon at senderdomain.com mail exchanger to handle that kind of bounce messages and process them in some sort of pipe.
With a pipe you can forward the returned message to an external program which parse the message and extract the needed informations (i.e. the reason why the delivery is failed)
At that point in your program (which can be a cli script in your application) you can mark the address as failing and optionally can record why.
This is a pretty difficult task, which can't be handled in a simple application. Usually I use a dedicated software for large mailing list handling such as sympa which takes care of this task for you.
Otherwise you can use an external delivery service such as Sendgrid which will do the dirty job for you and report the failing addresses with a simple API. As a bonus with this solution, they are in the whitelists for all the major providers, so your email won't be marked as spam as far as you respect some simple rules (i.e. removing bouncing addresses and use an opt-in policy for your newsletter)
Well, the second link and especially the answer by TimB explains very well the procedure.
What may not be clear is that the return path is nothing other than a regular email account, i.e. you will get the email to that address. Zend_Mail is not waiting for a response and hence there is no list of addresses.
On our website which is asp.net, we make a sale and an automated email is sent out to the client with an attached PDF invoice we create using a 3rd party app. We are having trouble getting these delivered successfully to some corporate clients. Yet we also send a copy of that same email to ourselves which we receive fine. We can then forward this on to the client and they do receive it no problems. So the original is not received but the forwarded mail is.
The webserver is a seperate IP address to our office Exchange server which sends the forwarded mail.
I have tried to find the difference between the 2 mails and it looked like a rich text issue, except that the mail is plain text or html!
The question is a little vague i know as i do not know where to look for the best. It seems to make no differenec which mail program is used, we tried MailEable and it was the same thing.
Mail is logged on the web server as leaving and that is the last we see of it. It doesnt bounce but it is definatley delivered to the client server, but doesnt reach the recipient. We used to track thru Message Labs and it would say it had reached the destination server ok. We do not use ML anymore until we find the issue, keeping it simple.
We have no issues sending to AOL, Hotmail and Yahoo etc.
It appears something in the email is upsetting server based spam software.
We havnt been able to get hold of any email logs from clients.
any suggestions?
Check out this link mentioning a reason not related to size issues
The SMTP (internet mail protocol) RFC (An RFC is a document describing
the standards that make the Internet work.) explicitly states that the
length of a single unterminated line can be 1000 bytes, no larger.
Some SMTP servers violate this, and the Firebox (this is our firewall)
will drop the connection when the line length exceeds the configured
length, which defaults to 1000.
which might indicate your pdf generator and/or mail generator creates output that's not 100% standards compliant. Might be a good point to check as it could explain why certain customer suffer fom this problem only.
552 Requested mail action aborted: exceeded storage allocation
This means there was a violation at the client's ("customer's") mail server. The message exceeded a threshold/limit of some kind. It's not clear if this is a per-message limit or if the user's mailbox is just so full that it cannot accept another message.
Either way, this is mostly out of your control. Only thing you can do it try to keep your e-mail messages and attachments as small as possible. If you can, compress (zip) any attachments before sending.
Our clients sometimes don't get the emails that we send out. It's a BIG loss. How do I assure that they receive the emails so that if it's not received in the other end, the program can resend it or do something about it.
None of the suggestions above will work 100% of the time. Many email clients will (rightly so) refuse to load foreign images, negating the usefulness of "web bugs". They will also refuse (or be unable to) return Outlook-style "receipts". And many mail servers either deliberately (to curb spam) or mistakenly (due to misconfiguration) won't return bounce messages. Or possibly an over-aggressive spam filter ate your message, so it arrived but was never seen by the end user. Plus there is the little matter of mail taking hours or days to reach the end user or bounce, and how do you correlate these late notifications or bounces with the mail you sent 4 days ago?
So basically, you can catch some but not all, no matter what you do. I'd say that any design that relies on being able to know with certainty whether the end user got your mail is fatally flawed.
One thing that you can do is set up a bounceback address that receives any mail that is undeliverable. Use the bounceback address as the From address -- you may want a different one for Reply-To so that replies get directed properly.
Check the bounceback mailbox daily and contact customers to get updated email addresses for the ones that fail. You may be able to automate a couple of retries to failed addresses before resorting to the manual contact in case the failure is only intermittent.
This would take some code outside your application that scans the mailbox and keeps some state information about the number of contacts, etc. and attempts the resend.
Depending on how you generate the mails, you might be able to make this process easier: generate a unique bounce address for every single email you send out. You could use bounces+1234#example.com, for example.
Many SMTP servers will allow you to use the part after the + as a parameter to an external script, etc.
The problem is that many (broken) SMTP servers don't return enough info with a bounce to identify the original message -- sometimes, when there are forwardings involved, you don't even get back the original addressee...
With the above trick you can reliably correlate outgoing messages with incoming bounces.
There is no standard way to know whether the email reached the destination. Many email clients support different types of receipts though. You can use any of those if you want.
There are some ways to know when the user actually read the email.
There are many techniques like adding an image to your email that is to be fetched from your web server. When the user reads the email, the request for the image comes to your server and you can capture the event.
The problem is that there is no way to know that the mail did not reach the destination.
I worked on a bulk email system in a previous life. Deliverability was one of our major issues. The most common cause of undelivered emails is a spam filter.
Here are the steps we took to ensure the highest delivery rates:
We used Return Path to test emails for that spam-like smell.
If you send a lot of emails, you need to make sure your SMTP server is not blacklisted.
Remind your users to add your FROM address to their "safe senders" list.
Use a system that collects bouncebacks and use them to scrub your mailing list. This will also help keep you off the blacklists.
If the emails are critical, consider sending them return-receipt-requested. This will not really guarantee anything, but it might give you some metrics on actual deliverability.
There's not really a good way to determine if the email actually arrives in their inbox, you can only confirm that you sent it. Attach a receipt that lets you know when they open it perhaps?
Microsoft Outlook provides similar functionality, however it is based on the email client. I'm not sure if other clients, like Thunderbird, support this.
However, there is nothing in the protocols that specify receipts.
One option that may work: send a link to a generate web page and monitor that page for hits. This provides its own issues however: confidentiality, etc.