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 email@example.com 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!
View API documentation, code samples, get your API key.Visit Page