I came home after newyear and was flabbergasted as soon as I saw, I had no mail! With exception of my whitelist, which is bitter small. After reading Slashdot, I’ve noticed Spamassassin has a 2010 bug, dropping legit mails to spam or nowhere; depending on the account settings.

There are two ways to fix this by hand; to keep the ability to thwart mails coming from the future (after 2014 in this case):

Step 1: edit the ruleset file.

• With root privileges: Edit the file /usr/share/spamassassin/72_active.cf
• Without root privileges: Add to the file ~/.spamassassin/user_prefs

Step 2: find/add or change FH_DATE_PAST_20XX:


##{ FH_DATE_PAST_20XX
header FH_DATE_PAST_20XX Date =~ /20(1[4-9]|[2-9][0-9])/ [if-unset: 2006]
describe FH_DATE_PAST_20XX The date is grossly in the future.
##} FH_DATE_PAST_20XX


I wish variables could be used in regexps like these, like $year + 2 would be a nice start….

Alternative Step: Automatic update of rulesets

The Spamassassin rules can be updated automatically by executing the following command:

• any unix system: sa-update && /etc/init.d/spamassassin reload
• Directadmin: /usr/local/directadmin/scripts/packages/Mail-SpamAssassin-3.2.5/sa-update && /etc/init.d/spamassassin reload
• admispconfig: /usr/local/admispconfig/ispconfig/tools/spamassassin/usr/bin/sa-update && /etc/init.d/spamassassin reload

Enjoy your mail without spam coming from the future!

02/jan/2010: Thanks go to mike for the even more-fine-grain regexp: 20(1[4-9]|[2-9][0-9])/

There have been some issues lately with the Wordpress MU Domain Mapping plugin; which has been playing with my brains for multiple weeks now. First of all the “add media” plug-in didn’t work as it used to be. When pressing the “add to post” button, nothing happened! For us developers that wouldn’t be a problem but to get users to add their images with raw html code is a little bit overkill…

I’ve started searching and found out I’ve had some error in my rewriting rules which took all requests from subdomain.artistblog.me towards it’s destination subdomain; but also including the administration interface directory which in it’s turn gave errors like cutting off the last character of the post slug, not adding categories, failing the “add media” and “add to post” button, failing random uploads and more functions that depend on the real root domain set in the WordPress database.

Next to that, I’ve started to get mildly annoyed the old posts of my blog has been lost at DIGG, because DiggBar serves as transparant proxy, but without the compatibility for URL redirects! That’s partially solved now in my solution, as long as the user has referers turned on. So, I’ve finally streamlined my rewrite rules, with the following remarks for code:

1. exclude wp-admin from redirecting to the new domain
2. redirect the domain with as hostname source.domain.com
3. exclude the referer digg.com from redirecting the domain (for compatibility with DiggBar)
4. rewrite to the new virtual.domain.com with all extra parameters

RewriteCond %{REQUEST_URI} !^/wp-admin(.*)$
RewriteCond %{HTTP_HOST} ^source\.domain\.com$ [NC]
RewriteCond %{HTTP_REFERER} !digg.com [NC]
RewriteRule (.*) http://virtual.domain.com$1 [L]

---

Another solution to get rid of DiggBar completely is by adding the following code to your header of your template:

<script type="text/javascript">

   if (top !== self) top.location.href = self.location.href;

</script>

---

Have Fun, Freaking Wildchild.