I'll echo the excellent answers already given, you're very likely to have spam traps within your list. Even if that's just old legitimate addresses that have been left online, but since reclaimed by the ISP. You're very likely to get blacklisted, which makes the whole endeavor ineffective. As they're sending from their own IP address, they'll suffer one of two issues:

1. They wont send enough volume to each ISP to register a reputation, and will perpetually have a slightly negative, default reputation. With a few spam complaints, most sends will never see the inbox.
2. They will send enough volume to be monitored by ISPs, but the IP will be hitting spam traps and is unlikely to get much mail delivered.

But actually, I'd say the biggest danger is in brand reputation damage. While ISPs hold an opinion of you, so do the people you're emailing. If you do manage to get to the inbox of users that haven't heard of you before, some will remember you as a spammer - hardly the kind of reputation you want for your business.

Besides, it's illegal in most jurisdictions to email harvested addresses. In the US, according to CAN-SPAM:

harvesting electronic mail addresses of the users of a website, proprietary service, or other online public forum operated by another person, without the authorization of such person;

Fantastic question. I'm not aware of inbound spam filters that perform GET (or HEAD) requests on images within the HTML part when scoring a message. We can tell if they are doing this by requests made to tracking bugs, such as Email Analytics', but we don't ever see these requests. Without performing a GET or HEAD request for an image, there's no way to determine its size.

After examining SpamAssassin's rules database, they do use two variables within their rules:

1. Does the HTML part have any images at all?
2. How many images does the HTML part have?

Actually fetching the image to determine its size isn't something they do.

That said, some ESPs perform pre-flight, outbound spam checks. These can be more sophisticated because they have more information to hand (such as file size of images, sending volume in advance etc). It wouldn't surprise me if some ESPs perform checks on image sizes and score lower as a result, but I don't think this is anything to worry about.

Great questions!

I'll try to tackle the mail server infrastructure question first. Postini is usually installed as an SMTP relay, where the MX records for the domain are changed to a dedicated Postini mail server, so you're correct that the sending infrastructure would look like:

Mail Queuing -> MTA -> Postini SMTP -> Postini filtering -> ISP SMTP

This works by updating the DNS MX records for the recipient's domain to Postini's SMTP servers, then telling Postini which records it should use to deliver the mail to the ISP as expected. So in future when you try to send to that recipient, you'll find a new MX record, which points to Postini. When Postini receives the email, it uses the old MX record value to deliver to the ISP's SMTP server.

That said, there's nothing stopping additional filters or SMTP relays in between the outbound SMTP (the MTA) and the Postini SMTP server. You can check this two different ways.

1. Perform an MX lookup on the domain of a recipient that's not receiving the email, here's an example lookup on our Postini filtered domain: http://mxtoolbox.com/SuperTool.aspx?action=mx%3aps.emailtests.com&run=toolpage
   (psmtp.com is a Postini domain). Run this on your recipient's domain and see what value is returned.

2. Send a single email to the recipient, then ask to view the raw source of the email once received, you'll get something along these lines:

Received: from omr-d03.mx.aol.com (omr-d03.mx.aol.com. [205.188.109.200])
by mx.google.com with ESMTPS id x4si32999358qad.172.2014.01.07.06.22.32
for ********@litmus.com
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Tue, 07 Jan 2014 06:22:32 -0800 (PST)

There'll be a Received header for each SMTP node that the email passed through, including Postini and any before it. See if you spot any unusual servers along the way that appear to be filtering in addition to Postini.

In terms of what's happening to the missing email, I can see a few scenarios:

1. There's a volume-sensitive filter in front of Postini that's rejecting the email when it sees larger volumes. You can spot volume-sensitive filters by unusual gaps in time between Received headers (you might have to send through a few at lower volume to get through for an example). If this is true, you should see an MX record for the recipient's domain (see above) that doesn't include "psmtp.com".

2. Postini is not quarantining the email, but actually delivering it with a header indicating it considers it to be spam. Another filter along the way (possibly even Exchange) is then deleting the email because it's detecting Postini's rejection. There are different ways of doing this, but one such example is prepending "[Spam]" to the subject line.

3. There's a bug causing the MTA to not be able to deliver the message (for example, until very recently PowerMTA was unable to deliver SMTP servers ending in .255). You can diagnose this by inspecting your MTA's outbound logs. You should see a 250 OK from Postini's SMTP server. If you do not, the problem lies before or at the MTA.

So, first confirm that the first 'hop' in the SMTP chain for your recipient is actually psmtp.com. Then confirm that the email has left your MTA by checking its logs.

It's a great question, Veronica, I've wondered this too.

Litmus has a service called Scoop that does something similar, and what we saw certainly backed up Jason's comments - great content that people want to read would be delivered directly to their inbox, at their request, or read within Scoop's digest consistently.

Another interesting thing we notice with Scoop usage is that users are more likely to read their favorite newsletters each edition, because there is less 'noise' from other senders in their inbox. By collapsing away emails from senders that aren't of interest to them, it allows them to spot and read the emails that are of interest.

That's an excellent point. I don't think it would have any effect.

You're right that when you naturally forward, in an email client, the sending mail server and from domain become your own, and the links remain as they were. But it's not unusual for a user to compose HTML emails with 3rd party domains in them (think of any time you've emailed a friend a link to something online), I'm not aware of reputation organizations that tie these together with the sending server domain or the from domain. The only damage that could be done is if the forwarder's recipients mark the email as spam, or the ISP decides it's spam, which would be unusual, because the forwarder to recipient relationship is likely to be a strong one (ie in their contacts).

I suspect that the spam reports rate for forwarded marketing messages is super low, because it's so often from a contact or other trusted source. So there'll be little negative feedback to associate with either the forwarder's domain, or the domain within links.

On the other side of the equation, it's absolutely true that if I send spam that contains links with your domain, it will damage the reputation of your domain. Uri blacklisting isn't taken anywhere near as seriously as mail server or from address blacklisting, though, so it's not too much of a concern.

Is there a significant technical challenge with caching at delivery instead of at open?

If I were Google, I wouldn't cache at delivery, seems like a big waste. They've already overcome the more technically challenging task of opening at open, which is more efficient. Caching every image, rather than just those requested, would likely double their proxy's load.