Might be a good idea to move direct paypal donation link from footer up to sourceforge donation button.Chris Corbyn wrote: My understanding is that if you don't have a SF account, the donation just shows up as "anonymous".
Thanks again
return-receipt 1pxl img hack
Moderators: Chris Corbyn, General Moderators
Re: return-receipt 1pxl img hack
Re: return-receipt 1pxl img hack
Howdy,
I'm no genius/export at Swift yet - but I've been using it for a while, and just wanted to mention two things:
1. A 1 px hack like the one you mentioned will be caught by a *LOT*, if not ALL spam filters. Definitely Hotmail, Yahoo, Gmail, Outlook etc will block it, but even more I would imaging. But I'm guessing you already know this!
2. Decorator plugin is what I use to do the functionality you're describing. (Although my situation is different, however I still need custom content per recipient). It is the Swift tool provided for this purpose. Personally I've never had a single problem with decorator plugin, in over 4000 or so emails worth of sends so far.
Cheers,
EoN
I'm no genius/export at Swift yet - but I've been using it for a while, and just wanted to mention two things:
1. A 1 px hack like the one you mentioned will be caught by a *LOT*, if not ALL spam filters. Definitely Hotmail, Yahoo, Gmail, Outlook etc will block it, but even more I would imaging. But I'm guessing you already know this!
2. Decorator plugin is what I use to do the functionality you're describing. (Although my situation is different, however I still need custom content per recipient). It is the Swift tool provided for this purpose. Personally I've never had a single problem with decorator plugin, in over 4000 or so emails worth of sends so far.
Cheers,
EoN
Re: return-receipt 1pxl img hack
If this were the case, then ANY HTML email with <img> tags would be marked as spam. I think you're referring to embedding the images, which is very bad practice.EoN wrote:A 1 px hack like the one you mentioned will be caught by a *LOT*, if not ALL spam filters. Definitely Hotmail, Yahoo, Gmail, Outlook etc will block it, but even more I would imaging. But I'm guessing you already know this!
How would the decorator plugin do what I want? All it does is insert unique content into each email. If it provided a way for me to generate stats for each email I send, then I'll use it for that purpose. Until then, if somebody comes up with a better way of letting me know when somebody opened my email, this is what needs to be used.EoN wrote:Decorator plugin is what I use to do the functionality you're describing. (Although my situation is different, however I still need custom content per recipient). It is the Swift tool provided for this purpose. Personally I've never had a single problem with decorator plugin, in over 4000 or so emails worth of sends so far.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: return-receipt 1pxl img hack
EoN is right... 1px image hacks are a bad idea and it's not really something I condone. But for a spam filter to detect if the image is tiny or not it would have to download it which would cause bigger issues. I dare say if you had "width=1 height=1" in the HTML it would start alarm bells ringing though.tgavin wrote:If this were the case, then ANY HTML email with <img> tags would be marked as spam. I think you're referring to embedding the images, which is very bad practice.EoN wrote:A 1 px hack like the one you mentioned will be caught by a *LOT*, if not ALL spam filters. Definitely Hotmail, Yahoo, Gmail, Outlook etc will block it, but even more I would imaging. But I'm guessing you already know this!
But I'm confused by your statement that embedding images is bad practice? Why? It's more bandwidth intensive I know that but it's a good way to deliver such content to end-users with a little more privacy.
SpamAssassin does approximations based on the ratio of images to other content, so sending your entire content as embedded images is a big no-no; but using embedded images in general is not bad.
Re: return-receipt 1pxl img hack
I'm generally referring to embedding the entire content. What my app is doing is sending out newsletters - some of which tend to be graphically heavy. Actually, most newsletters are that way now. I'm not saying it's good or bad, that's just the way it is. So embedding all of those images is not a good thing.Chris Corbyn wrote:EoN is right... 1px image hacks are a bad idea and it's not really something I condone. But for a spam filter to detect if the image is tiny or not it would have to download it which would cause bigger issues. I dare say if you had "width=1 height=1" in the HTML it would start alarm bells ringing though.tgavin wrote:If this were the case, then ANY HTML email with <img> tags would be marked as spam. I think you're referring to embedding the images, which is very bad practice.EoN wrote:A 1 px hack like the one you mentioned will be caught by a *LOT*, if not ALL spam filters. Definitely Hotmail, Yahoo, Gmail, Outlook etc will block it, but even more I would imaging. But I'm guessing you already know this!
But I'm confused by your statement that embedding images is bad practice? Why? It's more bandwidth intensive I know that but it's a good way to deliver such content to end-users with a little more privacy.
SpamAssassin does approximations based on the ratio of images to other content, so sending your entire content as embedded images is a big no-no; but using embedded images in general is not bad.
Everything that I've read about embedding images into HTML states that it is a bad idea. Other than bandwidth, viruses can be embedded into jpegs. It also makes for a much larger download for the recipient. Only about 50%-60% in the U.S. use broadband (that number may have changed, or course), so there are still a lot of people on dial-up.
The 1px img hack isn't the best idea, but for now it's the only one (that I know of anyway). return-receipts just don't work. People want to track their email. They're very fussy about that. However, since this is for opt-in lists it shouldn't be an issue.
As I said before, find me a better tracking solution and I'll gladly use it
Re: return-receipt 1pxl img hack
EoN wrote:A 1 px hack like the one you mentioned will be caught by a *LOT*, if not ALL spam filters. Definitely Hotmail, Yahoo, Gmail, Outlook etc will block it, but even more I would imaging. But I'm guessing you already know this!
tgavin wrote:If this were the case, then ANY HTML email with <img> tags would be marked as spam. I think you're referring to embedding the images, which is very bad practice.
Chris Corbyn wrote:EoN is right... 1px image hacks are a bad idea and it's not really something I condone. But for a spam filter to detect if the image is tiny or not it would have to download it which would cause bigger issues. I dare say if you had "width=1 height=1" in the HTML it would start alarm bells ringing though.
But I'm confused by your statement that embedding images is bad practice? Why? It's more bandwidth intensive I know that but it's a good way to deliver such content to end-users with a little more privacy.
In my eyes, I see remote images as worse practise than embedded images - from a viewpoint of privacy. I agree with Chris that now days, remote images would now be considered 'spammier' than embedded images.tgavin wrote:The 1px img hack isn't the best idea, but for now it's the only one (that I know of anyway). return-receipts just don't work. People want to track their email. They're very fussy about that. However, since this is for opt-in lists it shouldn't be an issue.
As I said before, find me a better tracking solution and I'll gladly use it
Also, even if the emails don't get entirely 'blocked' as spam, you can be 100% sure that the email clients will 'hide' all remote images anyway (unless the end user either clicks 'display' or changes their security settings)
From my perspective I would have imagined that Spam Detectors would see remote images that link back to scripts on servers as a dead giveaway that you're trying to track. Or if you look at 'tracking' from a spam point of view, it is used to determine if this email has reached its recipient, in which case it would be a 'hit', and the spam-sender would know to keep that email on the records forever, and sell it, and so forth.
As far as I know, remote images were blocked by email clients long before embedded ones.
Also - what Chris said about the cheker 'determining' if it's a tracker iamge is a good point. I'm thinking (not sure if this is how it works, but assuming), that it woudlnt be too hard for a spam checker to see that an image is linking back to something that is either a) not an image extension, b) has GET parameters (or even just a url) that look like 'identifiers' of any sort. In fact it would be VERY easy to determine.
tgavin - re your question "find you a better tracking solution". Welcome to 2008!!! 4 years ago I didn't even bother trying to use 1 x 1 tracking images, because it was outdated technology that is the oldest trick in the book. If email clients and spam catchers are getting smarter, tighter & more effective, I hardly think they're going to let such an obvious technique through! Have you even checked how many of your emails get to their recipients? People that "want to track their emails" are going to have to be told that it's at the cost of potentially a *HIGH* percentage of their emails being blocked. That's how it is, love it or leave it.
Hey, I wish there was a way to morally track as well without any privacy issues, let alone spam filters. But I gave in to the fact that there isn't, long ago. So did the last 3-4 companies I worked with.
Re: return-receipt 1pxl img hack
Arrgh! Help..I'm using that plugin.. what's the bug? Did you mean viewtopic.php?f=52&t=77319&p=435411 ?Chris Corbyn wrote:There's a plugin called the Decorator plugin, but a bug was discovered in it recently so I'm not really advising you use it until the next version of Swift.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: return-receipt 1pxl img hack
The bug is that if an exception is thrown (and internally caught) during a batchSend(), the message never has its place holders put back so all the other recipients get the replacements which were intended for the recipient where the exception occurred.
There was a (untested) fix posted in that thread. In addition version 4 has a more suitable API so this can't happen.
There was a (untested) fix posted in that thread. In addition version 4 has a more suitable API so this can't happen.