Hi I am sending some campaigns through ElasticEmails and these are the SpamAssassin rules scores of my campaigns.
0.2 JAM_LONG_LINK : BODY: Very long link in mail, possibly filled up with
0.8 HTML_FONT_LOW_CONTRAST : BODY: HTML font color similar to background
0.6 HTML_IMAGE_RATIO_04 : BODY: HTML has a low ratio of text to image area
0.5 JAM_LARGE_FONT_SIZE : RAW: Body of mail contains parts with very large
How can I avoid these filters?
Long links are added by ElasticEmails. I have no control over this.
What font size is large as per SpamAssassin rule?
I am using black font through out the email. I have few section with dark colors and the fonts on these sections are white. Everything is clearly visible. I have tested by changing the whole template background to a slightly darker color, but the filter still catches it.
Because of these issues my email delivery is seriously affected. Any suggestions?
Thanks
JAM_LARGE_FONT_SIZE
After several trial and error I found that anything above 30 was considered too large. A small portion of my email had size 34. It was a header. I reduced its font size to 26px and gave it a bold style. Now that issue is solved.
HTML_FONT_LOW_CONTRAST
This was trickier. So I explored the SpamAssassin rules and found out that all the text element should have a background-color and color attribute. It doesn't matter if the parent elements have these attributes. In my case, the parent element had background-color attribute so everything looked fine. But for SpamAssassin that was not enough. If background-color attribute is not present on a Text element, SpamAssassin will use the default value (#ffffff).
Adding a background-color attribute on all the Text elements rectified this problem.
Related
I am using quill js and making a fully responsive editor that will scale font-size with the container, using the view width property.
I have it fully built except for one problem:
Even though I am using prepareFormat(), (for times where the cursor is at one point and no other text is selected) the font-size will change on occasion to the highest default font inside of the quill minified file, which in version 0.20.1, happens to be 48px. I have tried putting my own numbers into the quilljs FONT_SIZES object, but only sometimes it would select them properly.
The thing I am most confused about is that if i highlight them, the letters will change to exactly what I would like them to be, whereas for the prepareFormat() fails to change it into any number but a preset in FONT_SIZES.
If anyone has a good idea as to what event I should tie prepareFormat() to, please let me know :)
Thanks in advanced!
Quill 0.20.1 uses execCommand which only allows 1-7 as valid font sizes. Quill 1.0 has no such limitation.
I want to change the color of date text tag {{_es_:signer:date}}. Is there a way to do that? I have been on EchoSign for 4 days. I am now looking for the color changing in it.
This is what they have in their Text tagging documentation,
"The form field formatting (font size, type, color, etc.) is determined by the format of the first ‘{‘. To ensure correct processing of Text Tags by EchoSign tag definitions should be specified in commonly occurring fonts within the document (Helvetica, Times New Roman, Arial, Verdana or Courier). Text Tag definitions are case sensitive and must be specified in lowercase text."
Or if you want to set color of the field dynamically, I guess you'll have to google about using Acrobat Javascript.
this should work
{{es:signer:date:font(color=green}}
probably too late, but might help someone
http://www.akaskyness.com/
This is in the early stages of development. I want this "cover" page to be non-scrollable, with the height of the white|black background adjusting to the height of the browser window. At the moment, when reducing the height of the browser window, the headers don't shift up proportionally and a scrollbar appears. I'm not really concerned about browser width at the moment because I haven't added any code for that yet.
I think I see what you mean - you want the <h1> and <h2> elements to shift vertically as the viewport height is resized, so that they don't end up off the screen (when it gets too short) and create a scrollbar.
In your current CSS, you try to do this using margin-top:17% on <header>. This seems like a logical approach, except something curious happens: the margin-top never changes, regardless of how you resize the browser vertically.
I'll be honest, this stumped me for a while, so I did some searching around about margin behaviour and found out this critical piece of information: "The percentage is calculated with respect to the width of the generated box's containing block." So the browser height is completely ignored in the calculation! If you resize the width of your browser, you can actually see how your headers move up and down on your webpage.
Well, that completely invalidates using a percentage margin to attempt to vertically align <header> relative to the viewport height. What now? Vertical alignment of elements is actually something lots of other developers have tackled in various ways. Here's a simple one that uses absolute positioning, by only rewriting the styles for <header>:
header {
margin-top:-3em;
position:absolute;
width:100%;
top:50%;
}
Here's a JSFiddle demonstration of this new CSS. Note that margin-top:-3em; is a bit of a guess on (half of) how tall your headers are, so if you don't want to hard-code that value, you'll probably have to look at a different approach for vertical alignment (this is just one of the easiest). Also, if you don't want it vertically centered, just change top:50%; to a different percentage value.
Hope this helps! Let me know if you have any questions.
I'm designing a responsive site using edge reflow with the following rules for breakpoints:
<480px, <768, 1024>
I'm using a different background picture for each breakpoint of respective widths. However when I add them to Reflow with contain for scale-x it seems as if the image I created is not that size. Most of them were at least 200 pixels shorter than designed.
So my question is what dimensions should I use background images for each breakpoint as well as any other guidance for this using Reflow or suggestions of I'm doing something wrong.
Normally I'd use cover rather than contain but then the image scales and doesn't show what I need it to from device to device.
Thanks
I'm building a website (summer-band.com) and trying to tweak the mobile settings (browser at < 600px) with 100% width settings for several of the elements. Unfortunately, with what I've done so far, the header/ container and the navigation bar as well as the footer all seem to be shooting out different widths and I can't seem to fix this on my own, thus asking for some assistance.
First, the menu: #navigation li a and #navigation li.current_page_item a's width is 100% but has a padding, so the box model won't do what you want. The width should be auto. This is a recurring problem of yours.
Next, the header: You have #headerImg's width set to a constant 600px. In your media query, you'll probably want to make the width and height auto and make the actual img's width 100%.
Moving down, your main #box has a width of 100% and a padding. Due to the box model, this probably won't do what you want. Make the width auto.
Further down, your #footer has a display of inline-block and a width of 100%. You'll probably want to change its display to block and width to auto.
I think that's mostly it, but you might want to set article img's max-width to 100% and remove the explicit width on your Kickstarter screenshot. I don't really know how to deal with the iframe with the video. Sorry.
A few last comments: You seem to be overusing brs and empty p tags rather than using appropriate margins.