One of my customers mentioned to me that the way they have out look set up, allows them to see a short email preview in the form
hello#email.com
Hi, this is a message preview
However when I email, the get a big long https string and at first they thought that the email might include a virus so were dubious about opening it.
I am keen to find a way to stop this happening.
My email displays as
me#email.com
<https://z86orge6w04.....>
I use Thunderbird to send my emails, I shouldnt think that my email client would cause this though.
Also I use an smtp relay mailersend and their details are included in the https link as you will see from the pic.
I have also used socket labs and when I send using their relay, the link is still there but changes slightly
So I think that it may be something to do with the fact I use an SMTP relay
I have noticed though that it only seems to be outlook that shows this, Gmail, thunderbird and others that I have sent testemails to do not display in this manner.
At first I thought that it was because my logo in the header contained a link to the website but I have removed the link and there is no change
The part at the top circled in yellow is what they see when I email, the bit below circled in red is what they see from everyone else
The problem is not related with Thunderbird but with MailerSend which is a transactional email service.
According to mailchimp:
Transactional emails are automated emails sent from one sender to one recipient, usually related to account activity or a commercial transaction.
The URL shown in the Outlook preview is a tracking URL. You can solve this problem by removing tracking or by asking support to MailerSend.
Actually I am facing a lot of problem about email sending. When I am trying to send a email using a module named phpmailer that contains an anchor tag or hyperlink as like
click here
email go to the spam folder but when i remove this anchor tag or remove the link from the body of the email its send properly and goes to inbox.
i do not get what was the problem.
i am using a shared hosting with cpanel.
please anybody help me.
For all links? Or just links to a particular site?
You might want to check that the site you're linking to isn't listed in SURBL or similar blacklist.
It's also worth inspecting headers on received messages - spam filters will often add headers telling you why it classified a message as spam.
Generally there is nothing specific you can do - if there was an obvious way to avoid spam filters then spam senders would use it and the filters would be useless. That said, almost every receiver uses entirely different spam filtering, so your results may vary enormously anyway.
I am sending out emails from my website using Zend_Mail and Send Grid. I have hyperlinks in the email that are being overwritten with what appears to be garbage by the time it gets to the user's inbox.
For example,
href="http://www.foo.com" is becoming href="http://email.foo.com/wf/click?upn=DSDRHSSBH2938TS".
I do not have this problem when I remove the 'http://' from the href. This is not a solution for me however, because links without 'http://' do not work in some email clients.
I checked the Zend Mail content and the links appear to be fine, so I am wondering if this is a problem with Send Grid or the email client. I have looked all over the web and have found very little information on this. I have seen some people with similar issues, but no one has been able to provide a real solution.
Has anyone seen anything like this? I'll be happy to provide more information if needed.
It looks like Send Grid is re-writing the URLs for click tracking. Try disabling this feature in your Send Grid account. https://sendgrid.com/docs/Apps/click_tracking.html
I need to be able to display ads on email forwarded through a server (preferably postfix) based on the demographic information of the recipient. Basically a message will arrive for someuser#fakedomain.com and be forwarded to realuser#theirdomain.com with a small advertisement at the bottom.
I would like to use postfix because it appears to be able to use mysql data for various tasks, which would be beneficial so that the system could be controlled by a web app that feeds the database.
I'd prefer to use OpenX for the ad server due to targetting channels (used to select ads based on demographic information), the ability to do text ads as well as email zones, and the ability to run it locally. Other ad servers that are better suited to this problem are acceptable, of course.
The core of the problem, as I see it, is being able to write something at the bottom of any given email message. Of course html messages make this even trickier, but I'd settle for having a solution that works for plain text and work up from there.
Commercial software is an option as well, but a few days of intermittent searching hasn't turned anything up.
Simply writing something to the bottom of the email message will fail miserably in a LOT of cases, particularly with HTML email encapsulated in a MIME multipart message (or anything else in a MIME multipart message) because anything after the last MIME section marker is explicitly supposed to be ignored by any MIME parser. If you want your app to work it needs to
determine if the target message is a MIME message other than TEXT/PLAIN
If it is not, append your text only ad at the end and you're done
if it is, determine if its multipart
if not, then you need to determine the content type of the whole message
If the content type is HTML then you can attempt to insert your ad HTML somewhere appropriate. This will be very hit or miss since you have no idea what the HTML layout will be like.
if the content type is anything OTHER than HTML (or maybe RTF), you're best off not touching the message.
If the message is multipart, determine the subtype
if its 'mixed', then you need to determine which part if any is the primary readable content, and then modify that portion as if it were the whole message based on the above rules
If its 'alternative' then you need to find ALL the readable portions and modify each of them in turn according to the above rules
Finally, and most importantly
Be prepared for the massive ill will you will receive from everyone who gets mail routed through your server.
Let me see... People sign up for your service, which I assume is free. They provide you their real email address and in return you provide them a different email address which they can use to e.g. subscribe to mailinglists and for other services. And maybe some spamfilter functionality? That sounds like a legit service to me, especially if you only provide the ads to the person who subscribed. I do wonder if you'd get many subscriptions, though, since many people can just as easy use a Google, Yahoo or Hotmail account for these purposes. So, what is the added value those subscribers will get?
Anyway, you would need to modify existing emails, which is a bit complex when they are HTML mails or if they're digitally signed. (Especially in the latter case, you would actually block the recipient from receiving those emails, since their email system would detect that the email has been tampered with. You might also be at risk of possible legal problems, although I don't think there's anything illegal as long as the recipient agrees with the terms of your service.
A number of applications have the handy feature of allowing users to respond to notification emails from the application. The responses are slurped back into the application.
For example, if you were building a customer support system the email would likely contain some token to link the response back to the correct service ticket.
What are some guidelines, hints and tips for implementing this type of system? What are some potential pitfalls to be aware of? Hopefully those who have implemented systems like this can share their wisdom.
Some guidelines and considerations:
The address question: The best thing to do is to use the "+" extension part of an email (myaddr**+custom**#gmail.com) address. This makes it easier to route, but most of all, easier to keep track of the address routing to your system. Other techniques might use a token in the subject
Spam: Do spam processing outside the app, and have the app filter based on a header.
Queuing failed messages: Don't, for the most part. The standard email behavior is to try for up to 3 days to deliver a message. For an application email server, all this does is create giant spool files of mail you'll most likely never process. Only queue messages if the failure reasons are out of your control (e.g., server is down).
Invalid message handling: There are a multiple of ways a message can be invalid. Some are limitations of the library (it can't parse the address, even though its an RFC valid one). Others are because of broken clients (e.g., omitting quotes around certain headers). Other's might be too large, or use an unknown encoding, be missing critical headers, have multiple values where there should only be one, violate some semantic specific to your application, etc, etc, etc. Basically, where ever the Java mail API could throw an exception is an error handling case you must determine how to appropriately handle.
Error responses: Not every error deserves a response. Some are generated because of spam, and you should avoid sending messages back to those addresses. Others are from automated systems (yourself, a vacation responder, another application mail system, etc), and if you reply, it'll send you another message, repeating the cycle.
Client-specific hacks: like above, each client has little differences that'll complicate your code. Keep this in mind anytime you traverse the structure of a message.
Senders, replies, and loops: Depending on your situation, you might receive mail from some of the following sources:
Real people, maybe from external sources
Mailing lists
Yourself, or one of your own recipient addresses
Other mail servers (bounces, failures, etc)
Entity in another system (my-ldap-group#company.com, system-monitor#localhost)
An automated system
An alias to one of the above
An alias to an alias
Now, your first instinct is probably "Only accept mail from correct sources!", but that'll cause you lots of headaches down the line because people will send the damnedest things to an application mail server. I find its better to accept everything and explicitly deny the exceptions.
Debugging: Save a copy of the headers of any message you receive. This will help out tremendously anytime you have a problem.
--Edit--
I bought the book, Building Scalable Web Sites, mentioned by rossfabricant. It -does- have a good email section. A couple of important points it has are about handling email from wireless carriers and authentication of emails.
You can set the address that the email is sent from, what will be put into the To: address if someone just presses 'Reply-to'. Make that unique, and you'll be able to tell where it came from, and to where it must be directed back to.
When it comes to putting a name beside it though '"something here" ' - put something inviting to have them just reply to the mail. I've seen one major web-app, with Email capturing that has 'do not reply', which turns people off from actually sending anything to it though.
Building Scalable Web sites has a nice section on handling email. It's written by a Flickr developer.
(source: lsl.com.au)
EDIT: I misunderstood your question.
You could configure your email server to catch-all, and generate a unique reply-to address. E.g. CST-2343434#example.com.
A polling process on the server could read the inbox and parse out the relevant part from the received email, CS-2343434 could mean Customer Support ticket ID no. 2343434.
I implemented something like this using JavaMail API.
Just a thought.
The best way to achieve this will be to write a window service that acts like a mail client [pop3 or imap]. This windows service should execute a timed action triggered by a timer, which connects to the mail server and polls the server for any unread message(s) available in the email inbox. The email ID to check for is the email ID on which the users will give their input on/to. If the windows service client finds that there exists any new mail(s) then it should download and filter the email body and push further for processing based on the user input in the email. You can host the input processing in the same windows service but it is not advisable to do so. The windows service can put the inputs in a special application directory or database from where your main appication can read the user inputs received in email and process them as needed.
You will be required to develop a high performance TCP/IP client for doing so. I advise you not to use the default .Net library due to performance issues, instead use one of the best availabel open source TCP/IP implementations for .Net like XF.Server from kodart. we have used this in our applications and achieved remarkably grear results.
Hope this helps..
Bose has a pretty great system where they embed a Queue and Ticket ID into the email itself.
My company has the traditional Case # on the subject line, but when CREATING a case, require a specific character string "New Case" "Tech Support Issue" on the subject line to get through the spam filters.
If the email doesn't match the create or update semantics, the autoresponder sends an email back to the recipient demonstrating how to properly send an email, or directs them to our forums or web support site.
It helps eliminate the spam issue, and yet is still accessible to a wide technical audience that is still heavily email dependent.
Spam is going to be a bit of a concern. However since you are initiating the conversation you can use the presence of your unique identifier (I prefer to use the subject line - "Trouble ticket: Unable to log into web...[artf123456]") to filter out spam. Be sure to check the filter on occasion since some folks mangle the subject when replying.
Email is a cesspool of bad standards and broken clients. You need to be prepared to accept almost anything as input. You will need to be very forgiving about what kinds of input are tolerated. Anything easy for you to program will likely be difficult for your users to use correctly. Consider the old mailing list programs that require you to issue commands in the subject line. Only hardcore nerds can use those effectively. And some of those trouble-ticket CRM things you mentioned have bizarre requirements, such as forcing the user to reply between two specific text markers in the text. That sort of thing is confusing to people.
You'll need to deal with email clients that send you formatted text instead of plain text. Some email clients still don't handle HTML properly (cough GMail) so your replies will also need to be designed appropriately. There are various ways in which photos might be "uploaded" via email as well, especially when mobile phones are involved. You will need to implement various hacks and heuristics to deal with these situations.
It's also entirely possible that you will get email that is valid but unusable by the email parsing library you are using. Whether or not this is important enough to roll your own will be a judgement call.
Finally, others have mentioned using specific email addresses to uniquely identify a "conversation". This is probably the easiest way to do this, as the content of the mail will often not survive a round trip to a client. Be prepared, however, to get mail to old IDs from old customers who, instead of opening a new ticket somehow, reply to an old ticket. Your application will probably need some way to push emails with an old ID into a new case, either manually or automatically. For a CRM system it's very likely that a user would reply to an old email even if you already sent him a new email with a new ID in it. As for whether you should use some.email.address+some.id#yourdomain.com or just some.id#yourdomain.com, I'd go with the latter because the plus-sign confuses some email clients. Make your IDs guids or something and have some way to validate them (such as a CRC or something) and you'll get less junk. Humans should never have to type in the GUIDs, just reply to them. The downside is spam filtering: a user's computer might view such email addresses as spam, and there wouldn't be an easy way to whitelist the addresses.
Which reminds me: sending email these days is full of pitfalls. There are many anti-spam technologies which make it extremely hard for you to send email to your customers. You will need to research all of these and you need to be careful, and do some testing, to ensure that you can reach the major email providers. A website like Campaign Monitor
can help you if you are sending email.