<?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>DotBlag.Com &#187; yahoo</title>
	<atom:link href="http://www.dotblag.com/tag/yahoo/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.dotblag.com</link>
	<description>Technical Trials And Errors</description>
	<lastBuildDate>Fri, 14 Oct 2011 23:07:29 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
		<item>
		<title>(non) Instant Messaging</title>
		<link>http://www.dotblag.com/2008/03/26/non-instant-messaging/</link>
		<comments>http://www.dotblag.com/2008/03/26/non-instant-messaging/#comments</comments>
		<pubDate>Wed, 26 Mar 2008 21:41:51 +0000</pubDate>
		<dc:creator>SysOp</dc:creator>
				<category><![CDATA[Net.working]]></category>
		<category><![CDATA[irc]]></category>
		<category><![CDATA[yahoo]]></category>
		<category><![CDATA[yim]]></category>

		<guid isPermaLink="false">http://www.dotblag.com/?p=28</guid>
		<description><![CDATA[Yahoo! Instant Messaging recently (from my perspective) had a nearly 2 hour outage.  This has brought back a problem we&#8217;ve had here a number of times in that we  - de facto &#8211; standardized on YIM for internal messaging.  I&#8217;m now trying to encourage everyone (again) to use IRC on our (sort of private) IRC [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://yahoo.com/">Yahoo!</a> <a href="http://messenger.yahoo.com/">Instant Messaging</a> recently (from my perspective) had a nearly 2 hour outage.  This has brought back a problem we&#8217;ve had here a number of times in that we  - de facto &#8211; standardized on YIM for internal messaging.  I&#8217;m now trying to encourage everyone (again) to use <a href="http://rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&amp;letsgo=1459&amp;type=ftp&amp;file_format=txt">IRC</a> on our (sort of private) IRC Server.</p>
<p><a href="http://messenger.yahoo.com/">YIM</a> also has an awesome quirk, that has gotten better and worse, of rather apparently randomly filtering messages, especially messages with URLs according to some scheme only they seem to know.</p>
<p>Another quirk of YIM is sometimes you get queued messages without being told that happened.  So the person logs in sometime later and gets stuff you thought they were just ignoring.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.dotblag.com/2008/03/26/non-instant-messaging/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Anti-Spam, or, Anti-Delivery&#8230;</title>
		<link>http://www.dotblag.com/2008/02/25/anti-spam-or-anti-delivery/</link>
		<comments>http://www.dotblag.com/2008/02/25/anti-spam-or-anti-delivery/#comments</comments>
		<pubDate>Mon, 25 Feb 2008 19:50:56 +0000</pubDate>
		<dc:creator>SysOp</dc:creator>
				<category><![CDATA[E.Mail]]></category>
		<category><![CDATA[anti-spam]]></category>
		<category><![CDATA[spam]]></category>
		<category><![CDATA[yahoo]]></category>

		<guid isPermaLink="false">http://www.dotblag.com/?p=22</guid>
		<description><![CDATA[Yahoo! is getting to be very aggressive against spam.  Problem is we can&#8217;t deliver ANYTHING for about the past 6 days because we can&#8217;t get a dialog with them as to 1) why they&#8217;re unblocking and 2) they won&#8217;t unblock.  I think ultimately here we&#8217;ll be forced to discontinue most or all forwarding services if [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.yahoo.com/">Yahoo!</a> is getting to be very aggressive against spam.  Problem is we can&#8217;t deliver ANYTHING for about the past 6 days because we can&#8217;t get a dialog with them as to 1) why they&#8217;re unblocking and 2) they won&#8217;t unblock.  I think ultimately here we&#8217;ll be forced to discontinue most or all forwarding services if Yahoo!, etc, continue the current extremely unfriendly-unable-to-cooperate behavior.</p>
<p>What would I like to see?  Well&#8230;It&#8217;d be nice if they used a <a href="http://www.spamcop.net/">SpamCop</a> like process to find the ACTUAL source of an email and inform some sort of blacklist of that source, that other places can query.  (DNSBL&#8217;s are great for this, REALLY!)</p>
<p>The problem is then that the small percentage of spam in this particular case causes the majority of email to be undeliverable.  AND PEOPLE ARE REQUESTING THIS STUFF GET FORWARDED.</p>
<p>This is part of why we&#8217;re trying to take steps to reduce the amount of junk we take in, I&#8217;m still researching (or rather it&#8217;s on the ToDo list) how we can effectively deploy greylisting.</p>
<p>I&#8217;m also working on redesigning the mail system so that we can do more processing &#8220;up front&#8221; and for forwarded addresses.  Doing this requires more horsepower in our mail front end&#8217;s (MFE&#8217;s) and requires we take some steps to reduce the amount of obvious junk before we start doing heavy work.  Right now we do some blacklist lookups, then go through AV processing, then pass it along for final delivery, either for local delivery, or offsite delivery.  Local delivery benefits from being processed by SpamAssassin, remote delivery can&#8217;t.  Our current SA setup is bound by which mailbox the final delivery goes to for selecting rules/scores, so no local mailbox, no way to go.  It&#8217;s also directly coupled with final delivery presently.</p>
<p>What I want to do, is for forwarded addresses allow a &#8220;discard&#8221; threshold of some sort to be set.  Set it so it can&#8217;t be turned off completely and can&#8217;t be raised above a certain score threshold (say 8 or 10) and either discard or locally deliver anything above the threshold.</p>
<p>The real problem is of course the rather dull way in which we all handle this mess.  If more providers blocked the crap up front there&#8217;d be a lot less to deal with.</p>
<p>I hear everyone clamoring but it&#8217;s so haaaaaard.  Seriously now, REALLY, how many of your customers NEED port 25 access?  I bet almost none.  They should be using your mail servers ISPs!  Heck even just having a voluntary opt-in-to-port-25 access will solve a huge chunk of the issue, even if the ISP does no verification.</p>
<p>Maybe this is the end of all forwarding service.  As that seems to cause most of the problem, uneducated users who refuse to listen and stop reporting spam on their forwarded email is what lead to the removal of AOL forwarding.</p>
<p> </p>
]]></content:encoded>
			<wfw:commentRss>http://www.dotblag.com/2008/02/25/anti-spam-or-anti-delivery/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.536 seconds -->

