<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.1-alpha" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: One more reason to love spammers</title>
	<link>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/</link>
	<description>the blog that is not dansdata.com</description>
	<pubDate>Thu, 07 Aug 2008 21:00:51 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.1-alpha</generator>

	<item>
		<title>by: Jonadab</title>
		<link>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2407</link>
		<pubDate>Sat, 03 May 2008 01:59:52 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2407</guid>
					<description>This used to happen to be on a semi-regular basis, but on a smaller scale.  A particularly egregious spamming operation, operating out of Asia, whose database I was in (probably because of my address appearing in the From: fields of usenet posts; this was a while ago) appeared at that time to have a practice of randomly grabbing a fresh address from their database for each message sent, or at least for each SMTP connection.  So my address, being in their database, got used as a From: field several times an hour, continuously.  I also got quite a bit of spam directly from them, so I was able to piece together a reasonable amount of information about their operation.  They migrated to a fresh IP address every few hours, usually within the same Class A network (either that or they kept a full Class A of mail-sending computers busy, *shudder*, but I think rather that they were migrating across addresses as a filter-thwarting mechanism), but periodically (after weeks or months) they would move to a new Class A.  Sometimes they had control of three or four Class-A IP ranges simultaneously, always within APNIC space.  They made no attempt to couple email addresses to language, and they sent spam in a number of languages, but it was *mostly* Chinese (or gb2312 at any rate) and English.  Mostly.

Since I don't read chinese, I used to filter more than half my spam based on character set alone.  Then the botnet spammers came along, and unicode, and the filtering has become much more difficult these days.  

I am hoping to eventually move to a system wherein I create a distinct email address to give to each sender (or, at least, a distinct address for each situation in which I am giving out my address), and then when the spammers get one address I can just change that address without changing all the others.</description>
		<content:encoded><![CDATA[	<p>This used to happen to be on a semi-regular basis, but on a smaller scale.  A particularly egregious spamming operation, operating out of Asia, whose database I was in (probably because of my address appearing in the From: fields of usenet posts; this was a while ago) appeared at that time to have a practice of randomly grabbing a fresh address from their database for each message sent, or at least for each SMTP connection.  So my address, being in their database, got used as a From: field several times an hour, continuously.  I also got quite a bit of spam directly from them, so I was able to piece together a reasonable amount of information about their operation.  They migrated to a fresh IP address every few hours, usually within the same Class A network (either that or they kept a full Class A of mail-sending computers busy, *shudder*, but I think rather that they were migrating across addresses as a filter-thwarting mechanism), but periodically (after weeks or months) they would move to a new Class A.  Sometimes they had control of three or four Class-A IP ranges simultaneously, always within APNIC space.  They made no attempt to couple email addresses to language, and they sent spam in a number of languages, but it was *mostly* Chinese (or gb2312 at any rate) and English.  Mostly.</p>
	<p>Since I don&#8217;t read chinese, I used to filter more than half my spam based on character set alone.  Then the botnet spammers came along, and unicode, and the filtering has become much more difficult these days.  </p>
	<p>I am hoping to eventually move to a system wherein I create a distinct email address to give to each sender (or, at least, a distinct address for each situation in which I am giving out my address), and then when the spammers get one address I can just change that address without changing all the others.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Daniel Rutter</title>
		<link>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2396</link>
		<pubDate>Sun, 27 Apr 2008 01:04:56 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2396</guid>
					<description>There's been a second, smaller run today, giving me several hundred more bounces.

I'm also intrigued by the a new run of German pharmacy spams, all of which have, thanks to the usual letter-duplication obfuscation techniques, the subject line &quot;Internetttapoooootheke&quot;.

(&quot;Apotheke&quot; is German for &quot;pharmacy&quot;. I can only presume that an &quot;apoooootheke&quot; is a place where certain mail-order DVDs with a rather specialised audience are produced.)</description>
		<content:encoded><![CDATA[	<p>There&#8217;s been a second, smaller run today, giving me several hundred more bounces.</p>
	<p>I&#8217;m also intrigued by the a new run of German pharmacy spams, all of which have, thanks to the usual letter-duplication obfuscation techniques, the subject line &#8220;Internetttapoooootheke&#8221;.</p>
	<p>(&#8221;Apotheke&#8221; is German for &#8220;pharmacy&#8221;. I can only presume that an &#8220;apoooootheke&#8221; is a place where certain mail-order DVDs with a rather specialised audience are produced.)
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Balentius</title>
		<link>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2393</link>
		<pubDate>Sat, 26 Apr 2008 03:39:02 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2393</guid>
					<description>I had this happen too - I was checking email ~2 weeks ago, and my normal 60 messages per 10 hour load suddenly shot up to ~800 messages...  Lots of fun for a home email account.

I saw bounceback and &quot;delayed delivery&quot; emails for at least 5 days afterwards.</description>
		<content:encoded><![CDATA[	<p>I had this happen too - I was checking email ~2 weeks ago, and my normal 60 messages per 10 hour load suddenly shot up to ~800 messages&#8230;  Lots of fun for a home email account.</p>
	<p>I saw bounceback and &#8220;delayed delivery&#8221; emails for at least 5 days afterwards.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: pakalolo</title>
		<link>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2391</link>
		<pubDate>Fri, 25 Apr 2008 22:46:59 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2391</guid>
					<description>If everyone would start using Sender Protected Framework, it would solve a lot of these issues.</description>
		<content:encoded><![CDATA[	<p>If everyone would start using Sender Protected Framework, it would solve a lot of these issues.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Chazzozz</title>
		<link>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2375</link>
		<pubDate>Thu, 24 Apr 2008 17:15:56 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2375</guid>
					<description>Not only do &lt;i&gt;you&lt;/i&gt; have to wade through the volumes of backscatter, but imagine the headaches for the poor list Owners and Moderators who also have to deal with it, too.  For every error that gets bounced to you, there's a high likelihood that one goes to the Owner as well.  If a list's address is targetted as a recipient, and it's a moderated type that requires a real human to approve posts, the Moderators then have to troll through them all to weed out the chaff from the grain.

Of course, there's a special place in my heart for spammers who use the &lt;b&gt;list's&lt;/b&gt; address as the origin...that way the Site Admin where the mailing list manager is hosted gets to share in the pain, too.

Oh, and for the record, a well-behaved non-brain-dead mail server should never be sending bounces to the address that appears in the From: or Reply-To: fields.  They &lt;i&gt;should&lt;/i&gt; be using the Return-Path: field (which is functionally equivalent to what's seen in the MAIL FROM command of the SMTP transaction, but could possibly be forged as well).  You can argue that if it's a null return-path '' then From: or Reply-To: is valid, but in this case the server should be smart enough to just drop it on the floor.
</description>
		<content:encoded><![CDATA[	<p>Not only do <i>you</i> have to wade through the volumes of backscatter, but imagine the headaches for the poor list Owners and Moderators who also have to deal with it, too.  For every error that gets bounced to you, there&#8217;s a high likelihood that one goes to the Owner as well.  If a list&#8217;s address is targetted as a recipient, and it&#8217;s a moderated type that requires a real human to approve posts, the Moderators then have to troll through them all to weed out the chaff from the grain.</p>
	<p>Of course, there&#8217;s a special place in my heart for spammers who use the <b>list&#8217;s</b> address as the origin&#8230;that way the Site Admin where the mailing list manager is hosted gets to share in the pain, too.</p>
	<p>Oh, and for the record, a well-behaved non-brain-dead mail server should never be sending bounces to the address that appears in the From: or Reply-To: fields.  They <i>should</i> be using the Return-Path: field (which is functionally equivalent to what&#8217;s seen in the MAIL FROM command of the SMTP transaction, but could possibly be forged as well).  You can argue that if it&#8217;s a null return-path &#8216;&#8217; then From: or Reply-To: is valid, but in this case the server should be smart enough to just drop it on the floor.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: LA Smog</title>
		<link>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2374</link>
		<pubDate>Thu, 24 Apr 2008 10:38:22 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2374</guid>
					<description>Actually the recipient check method is fouled as well since spammers figured out, &quot;Hey! This is a great way to test what addresses ARE valid here!&quot; They then proceed to run a list of recipients 400 miles long through the system, including sometimes using the randomly generated names.

So there is the tar pitting method where every &quot;RCPT TO&quot; request gets either 1 second added or an n+1 system to get progressively slower. This stops the mail address harvesting since it isn't feasible in the lifespan of the computer it is running on, but this generates issues and errors for real mail in the corporate world (and mail lists) and for some reason runs the machine into the rails with many connections that I have not had answered (at least on Exchange 2003).

Having said all this, it is pretty damned stupid to have the server setup to do this. I end up explaining this process and why the users at work are receiving these mailings for things they have not sent... repeatedly.</description>
		<content:encoded><![CDATA[	<p>Actually the recipient check method is fouled as well since spammers figured out, &#8220;Hey! This is a great way to test what addresses ARE valid here!&#8221; They then proceed to run a list of recipients 400 miles long through the system, including sometimes using the randomly generated names.</p>
	<p>So there is the tar pitting method where every &#8220;RCPT TO&#8221; request gets either 1 second added or an n+1 system to get progressively slower. This stops the mail address harvesting since it isn&#8217;t feasible in the lifespan of the computer it is running on, but this generates issues and errors for real mail in the corporate world (and mail lists) and for some reason runs the machine into the rails with many connections that I have not had answered (at least on Exchange 2003).</p>
	<p>Having said all this, it is pretty damned stupid to have the server setup to do this. I end up explaining this process and why the users at work are receiving these mailings for things they have not sent&#8230; repeatedly.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: VMax</title>
		<link>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2369</link>
		<pubDate>Wed, 23 Apr 2008 18:58:48 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2008/04/23/one-more-reason-to-love-spammers/#comment-2369</guid>
					<description>&amp;gt;What mail servers should do in this situation is check the recipient before they accept the message, and reject message delivery if the recipient does not exist. Then an error gets sent directly to the sending mail server.

It's very difficult to do this if you're a secondary MX - especially when the people you're secondary for demand that you don't filter their mail, they have specially tailored this and that... *sigh*</description>
		<content:encoded><![CDATA[	<p>&gt;What mail servers should do in this situation is check the recipient before they accept the message, and reject message delivery if the recipient does not exist. Then an error gets sent directly to the sending mail server.</p>
	<p>It&#8217;s very difficult to do this if you&#8217;re a secondary MX - especially when the people you&#8217;re secondary for demand that you don&#8217;t filter their mail, they have specially tailored this and that&#8230; *sigh*
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
