I have a problem with my hotmail account. For some reason I receive a lot of messages every day which have a link lead to 3-4 sites so that they will track who opens the link. They also have unsubscribe links which go to a similar URL but it is not actually unsubscribe me. I receive 20-30 messages every day. They go to the junk folder but I can to keep this folder clean.
What I was looking for is a way to automatically delete these messages by using some kind of filtering but they use different emails every time that they send the messages and the only way to automatically delete these messages is by checking the contents of the message and find the specific URL pattern that they use in order to track the users who actually see the messages that they send.
I tried to use the hotmail rules or the thunderbird message filters but I have not found a way to find the messages which contain a specific link inside the body of the message so that the application will automatically delete them.
Is there a tool or mail client which will allow me to filter and delete these messages?
Thanks in advance,
Aristotelis
Related
We have a newsletter where people opt-in (everything is on the up and up here). As people leave jobs (fired, layoffs, etc.), we still send to those emails and now after a few years, we have a considerable amount of emails that need to be purged.
The inbox that is receiving the bounces/invalid emails is a gmail account. We can filter (via a search) and find the emails that need to be removed but how can we export those emails to a list so that we can clean up our distribution list? Are there any tools that would help simply this?
We are looking into mailgun and sendgrid for future send outs but we need to clean up the list before we migrate. Any help or suggestions would be appreciated.
Our tech stack is apache/coldfusion 11 (not that it matters but in case it helps).
You could use CF to log into gmail and pull all the messages. Then loop through them all to find the bounce messages. Appending those bounced email addressed to a simple flat file. If you want to get fancy you can use a database, but I think a simple text file would do in this case. One email address per line.
I just read that you are deleting those bounced email addresses from a database. IF you're confident of your coding the above idea, you could directly delete from your database rather than saving a file.
I receive dozens or hundreds of emails from nagios each day. Many are related to the same service/server. For example, I get two emails within a few minutes of each other:
State CRITICAL on server: service
State OK on server: service
Outlook doesn't see this as a conversation so I can treat them that way.
I would like to have a filter, rule or process that would see "State OK" then go find all other emails that came in before that associated with that server: service and delete them.
I started with rules that took all emails associated with a server/service that are not OK and put them in a folder. My hope was to then have a rule that would see the OK email and delete all the messages in that folder then delete the OK message.
Unfortunately, I was not able to see an action to delete all emails in a folder.
I'm stuck at this point. I thought about writing a vba add-in, but it looks like the admin has that turned off.
Any suggestions? This could be useful for many system admins.
There are two macros you can include in the automatic email that Nagios sends out.
$SERVICEPROBLEMID$
$LASTSERVICEPROBLEMID$
You can append the serviceproblemid macro to the subject of the email on a critical/warning/unknown state and append the lastserviceproblemid macro to the recovery alert.
That way you can tie the two emails together and outlook can process accordingly (might take some playing with Outlook rules but I'm sure it can be done.)
In Email Queue, when I send queued campaign emails all emails are sent. I want it to send only the emails which are checked(selected checkboxes). Does any one know the way to do the same.
Thanks.
That's the default behavior, to modify it you'd check in /modules/EmailMan and ideally copy code/customization to the custom directory to try to stay as upgrade-safe as possible. Really, though, my experience with Campaign and Email customization is that there is heavy copy-paste from core files which are technically upgrade-safe but may not be upgrade-aware later on.
Also, the number of outgoing emails in a single blast can be controlled with Campaign Email Settings :
index.php?module=EmailMan&action=campaignconfig
On a more basic level though, why would you queue emails you don't want to send?
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.
If I were to build a newsletter emailing system, I will need to be able to generate reports on how many emails bounced, flagged as spam, unsubscribed, read vs. unread, click through rates etc....
So how do you keep track of user activity after the email has been sent? Am I right in assuming that you CAN NOT embed javascript code into emails to monitor user activity? How else do I gather data for my reports?
Once you send the e-mail, it's free like a baby bird kicked out of the nest. The writers of e-mail clients go to great lengths to make sure that they block any feature that will give you that kind of feedback you're asking for. While there are legitimate uses for this sort of information, spammers use such information to verify and clean their e-mail lists.
Many ISPs also block bounces because they give spammers information.
The best you can do is try to give your readers an incentive to click through back to your site. Then, you can gather information not available to a sender of e-mail.
You can easily track click-through rates by including a tracking query string bit in the URLs and route them through your site.
So a link might be: http://mysite.com/?LinkID=foobar
As for read vs. unread you can get an idea for that by including a small transparent image from your site that includes a tracking URL http://mysite.com/track.gif?EmailID=email. However this is not foolproof since emails can be read offline and most modern email clients do not display images without a user action to display images in the email.
For bounced, you'll have to track those by reading from a mailbox for the From email.
Can't think of way to track emails flagged as spam except to send it to several mailboxes that use some of the common spam filtering products and check the results. However, this isn't likely to be accurate because most can and are customized/trained by individual users.
If you want to do click tracking you'll have to replace all links from your message with links
that point back to your tracking script.
To do efficient tracking that you can actually use later for segmenting your list and better targeting you would have to track the subscriber's id and message and/or campaign id.
Some email marketing systems even track the link position in the message so you know exactly if the recipient clicked on the same link that was at the top of the message or in the middle and in the system that I have built I even track if they clicked a link in the html part of the message or the text part.
The tracker script would record all this information then redirect to the actual link.
Bounce tracking is done by processing the bounce messages that your server will receive or generate when a message cannot be delivered. I recommend using VERP: http://en.wikipedia.org/wiki/Variable_envelope_return_path
Open tracking is done by including the image with tracking code in the url. This would normally point to a script on your site that would record the subscriber id and message and/or campaign id then output the binary date for a transparent 1x1 px wide gif.
You can also track messages that are flagged as spam by some users of some ISPs like hotmail, yahoo, aol, and a few others. they offer feedback loops so every time someone clicks that "Spam" button in their webmail application they will send you a message that you can parse and determine the subscriber that actually flagged the message as spam. VERP also helps with this because the feedback loop messages don't always include the actual email address of the subscriber so you need another way to identify them. This page on wikipedia has a list of feedback ISPS that offer feedback loops : http://en.wikipedia.org/wiki/Feedback_Loop_%28email%29