<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Word to the Wise &#187; throttling</title>
	<atom:link href="http://blog.wordtothewise.com/tag/throttling/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.wordtothewise.com</link>
	<description>Email, Delivery, Spam and more</description>
	<lastBuildDate>Tue, 07 Feb 2012 23:24:18 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.3</generator>
		<item>
		<title>I need IP addresses to avoid throttling</title>
		<link>http://blog.wordtothewise.com/2009/11/i-need-ip-addresses-to-avoid-throttling/</link>
		<comments>http://blog.wordtothewise.com/2009/11/i-need-ip-addresses-to-avoid-throttling/#comments</comments>
		<pubDate>Tue, 10 Nov 2009 19:42:16 +0000</pubDate>
		<dc:creator>steve</dc:creator>
				<category><![CDATA[Best Practices]]></category>
		<category><![CDATA[godzilla]]></category>
		<category><![CDATA[ip addresses]]></category>
		<category><![CDATA[throttling]]></category>

		<guid isPermaLink="false">http://blog.wordtothewise.com/?p=763</guid>
		<description><![CDATA[Number three of seven in our occasional series on why ESPs need, or don’t need, lots of IP addresses to send mail properly. I need many IP addresses so that I can work around ISP throttling limits Why this is right: There are ISPs that limit the number of emails that can be sent from [...]]]></description>
			<content:encoded><![CDATA[<p>Number three of seven in our occasional series on why <a title="Why do you need so many IP addresses?" href="../2009/11/2009/10/why-do-esps-need-so-many-ip-addresses/">ESPs need, or don’t need, lots of IP addresses</a> to send mail properly.</p>
<blockquote><p>I need many IP addresses so that I can work around ISP throttling limits</p></blockquote>
<p><strong>Why this is right:</strong> There are ISPs that limit the number of emails that can be sent from a particular IP address in a given time period to quite a low level, as low as 1000 emails per hour per IP address in some cases. If that&#8217;s a mid-sized ISP with perhaps a million users and an ESP customer is sending email to 5% of their user base (not unreasonable for some customers) then that would take more than two days to send a news letter to those recipients, assuming absolutely perfect management of send rate. With more realistic inefficiencies for send rate management it could easily be a week. Using multiple IP addresses to spread the traffic in that case seems perfectly reasonable, though it would make everyone involved happier if the ISPs used more reasonable rate limiting metrics, perhaps tied to sending IP address reputation rather than applied globally to all non-whitelisted senders.</p>
<p><strong>Why this is wrong:</strong> Not every customer will be trying to send huge volumes of email to a receiving ISP that throttles inbound mail. For dedicated IP customers there&#8217;s no need to give them extra outbound IP addresses for this reason unless it actually becomes a real operational problem -  if it takes an hour or two for a  senders maildrop to reach the inbox at a particular ISP that&#8217;s not an operational problem. For pooled IP customers you may need to add IP addresses to deal with this, but only to the extent it&#8217;s needed to keep delivery times for pool customers to that recipient ISP reasonable. And two or three hours is not unreasonable.</p>
<p><strong>Why else is this wrong: </strong>Naive throttling of this sort, combined with the obvious engineering changes needed for senders to work around it hurts everyone &#8211; senders, recipients, receiving ISPs. You might have to work around it in the short term, but in the longer term work with receiving ISPs to resolve the problem in a way that makes everyone happier, whether that be whitelisting your outbounds or moving to a reputation adaptive throttling approach. Of course, if they tell you that your mail is throttled because it has a poor reputation you need to fix that before doing anything else.</p>
<div id="attachment_865" class="wp-caption alignnone" style="width: 260px"><a href="http://blog.wordtothewise.com/wp-content/uploads/2009/11/mothra_godzilla.png"><img class="size-full wp-image-865" title="Mothra and Godzilla" src="http://blog.wordtothewise.com/wp-content/uploads/2009/11/mothra_godzilla.png" alt="Tread light as a moth" width="250" height="195" /></a><p class="wp-caption-text">Tread light as a moth</p></div>
]]></content:encoded>
			<wfw:commentRss>http://blog.wordtothewise.com/2009/11/i-need-ip-addresses-to-avoid-throttling/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Technology does not trump policy when it comes to delivery</title>
		<link>http://blog.wordtothewise.com/2009/09/technology-does-not-trump-policy-when-it-comes-to-delivery/</link>
		<comments>http://blog.wordtothewise.com/2009/09/technology-does-not-trump-policy-when-it-comes-to-delivery/#comments</comments>
		<pubDate>Tue, 22 Sep 2009 22:22:51 +0000</pubDate>
		<dc:creator>laura</dc:creator>
				<category><![CDATA[Delivery Improvement]]></category>
		<category><![CDATA[compliance]]></category>
		<category><![CDATA[Deliverability]]></category>
		<category><![CDATA[magill]]></category>
		<category><![CDATA[rate limiting]]></category>
		<category><![CDATA[Reputation]]></category>
		<category><![CDATA[ReturnPath]]></category>
		<category><![CDATA[throttling]]></category>

		<guid isPermaLink="false">http://blog.wordtothewise.com/?p=647</guid>
		<description><![CDATA[Recently Ken Magill wrote an article looking at how an ESP was attempting to sell him services based on the ESPs &#8216;high deliverability rates.&#8217; I commented that Ken was right, and I still think he is. Ken has a followup article today. In the first part he thanks Matt Blumberg from Return Path for posting [...]]]></description>
			<content:encoded><![CDATA[<p>Recently Ken Magill wrote an article looking at how an ESP was attempting to sell him services based on the ESPs &#8216;high deliverability rates.&#8217; I commented that Ken was right, and I still think he is.</p>
<p>Ken has a <a href="http://directmag.com/magilla/0922-stupid-esp-good-points/">followup article today</a>. In the first part he thanks Matt Blumberg from Return Path for posting a thoughtful blog post on the piece. Matt did have a <a href="http://www.returnpath.net/blog/2009/09/you-go-ken-the-deliverability.php">very thoughtful article</a>, pointing out that the vast majority of things affecting delivery are under the control of the list owner, not under the control of the ESP. As they are both right, I clearly agree with them. I&#8217;ve also posted about reputation and delivery regularly.</p>
<ul>
<li><a href="http://blog.wordtothewise.com/2009/08/failed-delivery-of-permission-based-email/">Failed Delivery of Permission Based Email</a></li>
<li><a href="http://blog.wordtothewise.com/2009/07/fixing-high-complaint-rates-and-improving-reputation/">Fixing high complaint rates and improving reputation</a></li>
<li><a href="http://blog.wordtothewise.com/2009/04/reputation-as-measured-by-the-isps/">Reputation as measured by the ISPs</a></li>
<li><a href="http://blog.wordtothewise.com/2008/10/reputation/">Reputation</a></li>
<li><a href="http://blog.wordtothewise.com/2008/10/reputation-part-2/">Reputation: part 2</a></li>
</ul>
<p>While some of us agree wholeheartedly with Ken, he did receive comments from a few delivery people indicating they thought that ESPs should talk about how their technology could improve delivery for senders. Having had experience with customers of most (if not all) of the major ESPs, I would argue that most of the ESPs have roughly equivalent technology. Some may have slightly different bells and whistles, but those bells and whistles are not going to improve delivery on their own.</p>
<p>One commenter says, &#8220;ESP technology completely varies, and as ISPs increase &#8216;throttling&#8217;, the ESPs that can optimize throughput will have dramatically better deliverability than others.&#8221; What&#8217;s wrong with this statement? Nothing is wrong on the surface, it makes sense if you don&#8217;t know much about delivery and ISP rate limiting. However, in the last 12 &#8211; 18 months ISPs have really moved from one rate limit for all senders to dynamic limits based on the reputation and type of mail coming from a particular source.  Throttling at the major ISPs is mostly controlled by  reputation &#8211; they are dynamically assigning rate limits based on a senders&#8217; short term and medium term reputation. If your ESP has to implement technology in order to cope with those limits on your behalf then your delivery through that ESP, by definition, has a problem.</p>
<p>Moving to an ESP that can dynamically &#8220;adjust&#8221; to ISP imposed limits may improve delivery over the short term, but will not do anything to fix the underlying reputation issues that are prompting the ISPs to throttle mail.</p>
<p>Another commenter says, &#8220;Some ESPs have better support structure in place than others, whether it’s technology, staff, or approach, to make marketers more successful.&#8221; I agree with some of this. Some ESPs do have better techology and staff and will hold marketers hands and help them improve delivery. In most cases, this revolves around actually making the marketers into better senders, teaching them about best practices and even forcing the sender to make changes or find another ESP. Rarely does the actual SMTP technology factor into this improvement.</p>
<p>There are a lot of technical things that ESPs could do to improve delivery, but that many (most?) of them don&#8217;t do. Two of the more obvious things ESPs could do technically to facilitate delivery improvements are:</p>
<ol>
<li>Send VALID and w3c compliant HTML mail. This is pretty easy to do with off the shelf or open source technology, but most ESPs don&#8217;t do any cleanup of the email format. Invalid HTML will hurt delivery. HTML from a MS Word document pasted into an email creates ugly, uncompliant, messy HTML that looks a whole lot like spam to ISP filters.</li>
<li>Use data mining techniques to identify potential problem customers before mail is sent. I know one ESP is doing this very successfully, but most ESPs deal with problems reactively instead of proactively. It is better for everyone concerned if bad mail is caught before it goes out, not after.</li>
</ol>
<p>Overall, I am a big supporter of ESPs. I think their technology and their policy expertise makes them a good vendor for the average company wanting to use email marketing. I think, though, that <a href="http://blog.wordtothewise.com/2009/04/deliverability-versus-delivery/">delivery and deliverability</a> are under the control of the sender, not the ESP. An ESP that attempts to sell the idea that the technology is more important than practices and policies is misleading both themselves and their customers.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.wordtothewise.com/2009/09/technology-does-not-trump-policy-when-it-comes-to-delivery/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>

