has anyone seen error
[error_key] => json.invalid.value.no_script_tags
[error_message] => #/email_content: Field does not support script content.
when sending HTML email through API?
The error you're getting generally points to some word in the html email that is disallowed or not understood. It's hard to say what that might be without seeing the html. In the absence of script tags, I would look for deprecated tags or anything that might not be current html.
Segmenting the email into portions, and testing those portions separately as their own html emails, can help narrow down the issue.
If you want to post your email with identifying information redacted, we might be able to take a look and help troubleshoot.
API Support Specialist
Finally we got it through, problem was with some styles like
offset:0 and mso-***
I wish there was a bit more detailed error message or some tool to test html, would save lots of time!
Thanks for the feedback and glad you got passed it. Our filtering is mostly to ensure that potentially harmful code, scripting that isn't supported by email clients and other items that could cuase problems for our customers are not accepted. However, like a filtering, I'm sure that there are some valid items that we're catching.
Is there any way you can send over what you tried to submit to our support team so we can take a look? If we are being too restrictive, we will work to fix any of those problems we can find. Your help is greatly appreciated.
Also, I'll bring the idea of an HTML validator and better documentation to our email teams. We're working on enhancing our custom code experience and this is a great time to bring those types of ideas to them.
This issue persists from what I can tell. I'm getting the same error as above, with no script tags in place. You can find the full contents of the email at http://cl.ly/code/1l1s410k1Y0W . Any help would be much appreciated.
Thanks for the report. We are using an inclusive filter when checking content so we do assume this will continue to come up over time as we find new browser extensions or some HTML 5.0/CSS 3.0 tags that are newer or changed. We'll take a look at this and update the filters.
I'm sorry for the frustration this has caused. I will forward the feedback onto our engineering teams--both the suggestion for the line number and excerpt when the email content error is thrown, and to include the word 'physical' when it is a physical address that's missing. Thank you for the feedback.
API Support Specialist
Unfortunately, I have to agree. Too much more waiting time and we'll have to make a choice to make a change. The hang-up is that we have close to 60,000 contacts and about 100 groups...that'll be one large export.
I again apologize for the frustration here. We will take a look at the error message we use for the physical address and see if we can clear that up, great feedback.
Regarding the error message for script tags that we are sending, we did discuss with our security group returning more explicit error messages. After talking through all the pros and cons, we have came to the decision to not return the exact tags, encodings, scripts, etc. that could cause our validation to trigger potential malicious content.
As I hope you can understand, we have to take security very carefully. There are malicious entities out there who are always trying to find injection vulnerabilities and other hacking attack vectors to get any type of data or access they can. We have a large volume of sensitive data on our customers and we take any security situation very seriously. As such, we want to always err on the side of caution when dealing with security messaging. I understand that for our developers like yourselves who are just sending us valid HTML and trying to get your campaigns created this can be frustrating and we will certainly work as hard as we can to minimize these experiences going forward. We have a developer looking at this right now and we hope to have two things figured out soon this morning:
1. Which html/css tag/attribute is throwing the false positive so we can let you know and help you move forward immediately
2. A code fix for our validation to make sure that these valid tags/attributes are allowed in the future. Once we have this, we can get a fix out to production soon.
Again, I apologize for this frustration and we are working hard to figure out the cause and help get you through this as soon today as we can. This validation has been tested a lot, but as we get more and more developers using real world HTML/CSS, we are finding that there are many proprietary tags and even some non-proprietary sequences that we didn't anticipate and now need to issue fixes for. We thank you for reporting them and will keep working hard to get you the answers you need to move forward.
After troubleshooting the supplied HTML, the problem is around the following inlined CSS: "background-repeat: none". If you remove that, you'll be able to create the campaigns without any problem. We are going to add that to our filtering white list so that in the future, that CSS will work without issue. We are hopeful to have this done and delivered to production in our release next Thurs (8/8/2013).
It's worth mentioning that background images don't work in may email clients. We generally recommend not using them as your campaigns can look very strange, especially in all versions of Outlook and many webmail clients that don't allow those types of CSS attributes. Designs with that implemented should be tested heavily in any browser/client combinations you expect your subscribers to be using to make sure you are delivering what you intend them to experience.
This is still problematic without background-repeat, see http://cl.ly/code/2k2B0S151o0g . I'm assuming this will be a problem until next Thursday. Is that right?
You are correct, that will be a problem until next Thurs. We are not going to be able to get this into production any earlier than that.
However, I do want to mention that background images do not work in many email clients. For example, here is a screenshot of how your email would render in Outlook. Notice that all the background images are removed and the entire layout is changed because of that. It does look correct in GMail and Hotmail, it's mostly desktop clients that have problems rendering. Also, the layout is hard to read on mobile devices due to the size of fonts and the amount of images, not sure if you are targeting mobile readers are lot but the recommendation is often to do a simpler design with fewer images to define your content. If these are not concerns, than there isn't any reason to not use those.
Thanks for your suggestions. You're right, Outlook seems to have an issue with background images, but I wasn't aware it is an issue with Android ( see http://www.campaignmonitor.com/css/ ). It's something we'll definitely have to keep in mind.
We've done a lot of testing with Android in multiple versions and hardware providers. We've found that even when you do a large amount of testing and optimization for iOS, Windows Phone, Outlook and webmail clients and it looks great in all of them, there is a lot of nuance in the various Android hardware/version configurations that make it really hard to get it to look good on all Android headsets (if not impossible if you also want it to look good on other platforms at the same time). You can check out the HTML designs we've done for mobile friendly templates using media selectors and other HTML/CSS work in our mobile templates in our WYSIWYG editor. Just send yourself a test and look at the raw HTML.
We're working on providing better resources to our developers doing custom designs to better help with mobile optimization and sharing our learnings. In the meantime, feel free to give our tricks a look over and let me know what you think.
Dave is currently out of the office for the weekend, but I can definitely make sure that he gets this feedback for you. As far as getting your content working with the API, we can definitely help you to get that sorted out. If you're willing to share the code of the email here, I would be happy to help you in this topic. Otherwise, you can send us an email with the code at firstname.lastname@example.org and we will be able to help you there as well.
API Support Specialist
Looking at your HTML, found a few areas that failed validation. Fortunately, they were all the same issue.
The <a> tag does not support border="0" attribute. Note, this is not a valid attribute for the <a> tag and fails HTML validation as an unsupported attribute. We're opening up a bug to get this allowed for this tag so that if others add this in the future it won't cause any issues. When I removed those from your HTML it went through with no issues. Sorry for the long delay on getting back to you on this. I do understand the frustration on problems like this.
To try to give a little more information into why this problem even comes up, here's a little more insight into what we're doing. We actually use a very sophisticated library for scanning HTML documents for potentially problematic HTML, scripting and other types of attacks or malicious content. This is very common for companies who handle sensitive information, are large enough to garner hacker attention or just want to ensure high levels of data integrity and security. all large companies do, we face threats every day from malicious parties but we also face lots of threats from spammers trying to use our legitimate sending services to get their malicious messages out.
We of course take these threats very seriously and are always working on balancing developer experience and freedom with being too open and vulnerable to bad guys taking advantage of us. On this front, we have chosen that any HTML attributes or tags that are not in the HTML specs or that are no longer valid would cause our validation to fail and return this error. We have the ability to add exceptions to this rule and are continuously doing so as we get feedback from developers like yourself. Unfortunately, we can't differentiate easily between a common mistake (such as using an attribute that is valid in many tags on a tag that doesn't support) versus a deliberately malicious attempt to inject or hack our API. We will keep looking at this and how we can improve it for our developer community. Please keep letting us know when we've missed something and we'll keep getting things added in!