<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Bandwidth consumption with E-mail services</title>
	<atom:link href="http://pvanhoof.be/blog/index.php/2007/11/29/bandwidth-consumption-with-e-mail-services/feed" rel="self" type="application/rss+xml" />
	<link>http://pvanhoof.be/blog/index.php/2007/11/29/bandwidth-consumption-with-e-mail-services</link>
	<description>From the mind of Philip</description>
	<lastBuildDate>Sun, 28 Aug 2011 12:59:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.5</generator>
	<item>
		<title>By: pvanhoof</title>
		<link>http://pvanhoof.be/blog/index.php/2007/11/29/bandwidth-consumption-with-e-mail-services#comment-492</link>
		<dc:creator>pvanhoof</dc:creator>
		<pubDate>Sat, 01 Dec 2007 11:45:00 +0000</pubDate>
		<guid isPermaLink="false">http://pvanhoof.be/blog/index.php/2007/11/29/bandwidth-consumption-with-e-mail-services#comment-492</guid>
		<description>Note that IMAP has COMPRESS (although not all servers are implementing it) and that a good SSL implementation does compression too. So using STARTTLS should compress your connection too.

Double compression has few point and deflate compression of COMPRESS is good-enough, as the data being compressed is either plain text or the compression of the binary format is used by the document-format in case of BINARY fetching (which is usually the more ideal way of compression for that document type).</description>
		<content:encoded><![CDATA[<p>Note that IMAP has COMPRESS (although not all servers are implementing it) and that a good SSL implementation does compression too. So using STARTTLS should compress your connection too.</p>
<p>Double compression has few point and deflate compression of COMPRESS is good-enough, as the data being compressed is either plain text or the compression of the binary format is used by the document-format in case of BINARY fetching (which is usually the more ideal way of compression for that document type).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: steckel</title>
		<link>http://pvanhoof.be/blog/index.php/2007/11/29/bandwidth-consumption-with-e-mail-services#comment-493</link>
		<dc:creator>steckel</dc:creator>
		<pubDate>Fri, 30 Nov 2007 07:47:51 +0000</pubDate>
		<guid isPermaLink="false">http://pvanhoof.be/blog/index.php/2007/11/29/bandwidth-consumption-with-e-mail-services#comment-493</guid>
		<description>To further speed up things I am connecting to an imapproxy on my vserver through a compressed ssh-tunnel.
This works well for browsing, too: Ziproxy on the vserver end, privoxy on the tablet and protocol compression through the ssh tunnel (payload is already transcoded/compressed by ziproxy)</description>
		<content:encoded><![CDATA[<p>To further speed up things I am connecting to an imapproxy on my vserver through a compressed ssh-tunnel.<br />
This works well for browsing, too: Ziproxy on the vserver end, privoxy on the tablet and protocol compression through the ssh tunnel (payload is already transcoded/compressed by ziproxy)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

