I have an html form within an email (I know this isn't the best practice). I am able to have the form transmit data via POST in gmail, however, in iphone mail it the POST array is empty. Does anyone have any insight into this, could it possibly be a security setting, etc? Thanks!
A lot of email clients block POST requests from being sent from within an email. Allowing POST requests is dangerous in many ways. It can make phishing and XSS emails even more malicious. If you want your email to function properly in every email client (which is hard as it is), you should leave out POST requests. If possible, do a GET instead by appending a query string to a URL. That would have 100% support, so hopefully you can accomplish what you want to do like that.
Related
I manage an email newsletter for a customer. It uses a custom list management utility, but the emails are being delivered through SendGrid.
In order to integrate correctly with our list management unsubscribe. I'm manually creating the "List-Unsubscribe" header, with a mailto address, which goes to an email parser, and unsubscribes the user from the correct publication etc.
The email parsing etc. works fine. However for some reason gmail is not displaying the "Unsubscribe" link in the header, as it does with other newsletters I receive.
Another newsletter I manage for a different customer, uses SendGrid's built-in unsubscribe management, and for these ones gmail does display the link.
What I want to know, is why is my custom "Unsubscribe-Link" ignored by gmail, but SendGrid's works?
SendGrid's "List-Unsubscribe" looks like this ...
List-Unsubscribe: <mailto:unsubscribe#email.mycustomdomain.com?subject=http://links.mycustomdomain.com/asm/unsubscribe/*q*user_id=[SHA hash...==]>
My custom "List-Unsubscribe" looks like this ...
List-Unsubscribe: <mailto:u-[custom-encoded-user-id+publication-id]#list-management.mycustomdomain.com>
My email parser reads the incoming "to" address, and interprets the encoded user-id and publication-id, to unsubscribe the person from the correct list.
Can anyone suggest why gmail might not like my link? It's extremely difficult to find detailed information about the requirements for this header.
One obvious difference, is that mine doesn't have a subject, but that's because it doesn't need it. It gets all it needs from the "to" address. Could this actually make a difference though? Does the "to" address need to remain static?
I thought perhaps it just needed time, for gmail to familiarise itself with this newsletter. However it has been running for months, and still no link.
The list is very clean, and all recipients have opted-in. We don't get any spam reports, and very few bounces.
I've gone to a great deal of trouble to ensure that everything works correctly from my end, and it's very frustrating that I cannot find out what I need to do to make this work.
I found a similar question at the gmail forums, and the official response to that question was to "contact a professional about constructing html emails".
Not very helpful for me, as in my case, I'm supposed to be that professional.
Any suggestions would be greatly appreciated.
I am developing a page, which will be sent to people as email. Just like advertisement emails which we usually get. I wanted to know that it will support only html-php or can we use javascript and jquery also in that. Thank You for help!
Generally no you cant use javascript in an email body, but it will depend on the email client used to view the email as to whether it's allowed or not. It'd bad practise generally, and if you do this the majority of your mails will not get to their destination. Also bear in mind the HTML and CSS supported by email clients is limited, so don't expect a page that works in your web browser to look the same on an email client.
You can of course use javascript to help render the body of the message, and then extract the HTML/CSS that's been generated, but don't include any of the javascript code itself in the body that gets sent.
This looks like a duplicate of Is JavaScript supported in an email message?...
As Russell says, email clients generally do not support scripting. Maybe one or two do, but the coverage will be very low.
what i want is the countdown timer which will be displaying in the
user email.
But... if what you're interested in is a countdown, you can do that in most email clients. If you have a webserver with PHP, here is a tutorial on how to do this. This won't work in Outlook 2007/10/13, but the coverage is pretty good considering it's interactive inside an email.
There are also online tools to accomplish a countdown timer, though I can't personally vouch for those.
I know it's possible to have a polling survey in Mailchimp, but can we have a text field where people can submit responses as well, inline within the email, without being sent to a landing page?
If you were to code the email yourself, you would probably be able to include an input field. The thing is though, it won't work. Input fields are part of forms, and forms need a location to submit the entered data to. Email clients don't support that kind of data transfers, ergo: nope, not possible!
Final thought: if using a landing page isn't an option, you can always create an email link that simply allows your recipients to reply to the email with their answer to your question. Might not be the most elegant solution, but in some situations it does the trick just fine.
I know I could simply make a html form on a website and email a link to it, or send the html as an email which posts to the website and try to deal with the errors/warnings for different peoples mail clients.
But, due to a specific request from a client, I am wondering if there is a way I could send an email, a questionnaire, with the same checkbox elements which then user receiving the questionnaire simply checks and sends back as a reply to the sender?
This is not very well supported across email clients, and will even throw some scary looking error messages to your recipients. You will be much better served linking to a landing page.
More info: http://www.campaignmonitor.com/resources/will-it-work/forms/
Email only supports html and css. I think Google has something like that, but it is not widely supported.
Generally, neither html of css can submit a form or (if the form even displays) acknowledge which form fields are populated/checked. Pretty much all you have is hyperlinks.
Passing parameters in your hyperlink would allow you to pre populate a form, but that is about as tricky as you can get.
Something like this:
Register Now
You could then use PHP for example to populate the landing page form with the values. I know it doesn't help much for a questionnaire, but that's all we have to work with in email.
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.