Posted on 6 Comments on Goodbye mygbiz

Goodbye mygbiz

Google seems to try to invent new and interesting ways for spammers to spam me (and many others).  I’ve still not worked out a good way to block “fake googlegroups” which follow this method:

  1. Make new fake gmail login
  2. Make new fake google group
  3. Add lots of people’s email addresses to the group
  4. Send lots of junk to these people
  5. Repeat when it gets closed down

I’m not sure why  groups aren’t opt-in. A rather simple and standard way to stop this exact problem.

Anyhow, the next new spammer enablement that the nice folks at Google have come up with is the mygbiz.com domain. These are temporary email addresses you can use when setting up Google apps. The only thing I have ever seen from them is spam. So I thought I’d try to report some to Google.  After looping around several help screens that were, despite their name, very unhelpful, I’ve come to the conclusion that Google isn’t too serious about fixing this problem.

If you have postfix, the solution is very simple:

  1. vi /etc/postfix/access_sender
  2. Add a line like “mygbiz.com  REJECT”
  3. postmap /etc/postfix/access_sender
  4. postfix reload

I find the results to this method far superior to trying to get Google interested in being responsible for a domain they run. If you want to use google apps then spend the $50 and get a domain. Alternatively don’t use something that spammers abuse.

Does it work? You bet it does!

Sep 18 23:26:38 elmo postfix/smtpd[19013]: NOQUEUE: reject: RCPT from mail-ye0-f208.google.com[209.85.213.208]: 554 5.7.1 <[email protected]>: Sender address rejected: Do not send from mygbiz.com domains; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail-ye0-f208.google.com>
Posted on 2 Comments on jqGrid in TurboGears2 Admin Screens

jqGrid in TurboGears2 Admin Screens

I wanted to use the jqGrid for my admin pages as I liked that look and it matches some of the other screens outside the admin controller.  The admin controller, or rather the CrudRestController out of tgext.crud, has a way of exporting results in json format. So surely its a matter of changing the TableBase to use jqGrid in the admin controller and we’re done?

Well, no.

First you need to adjust the jsonReader options so that it lines up to the field names that the controller sends and this was one of the first (or last snags). The json output looks like:

{
  "value_list": {
    "total": 20,
    "items_per_page": 7,
    "page": 1,
    "entries": [(lots of entries)...]
  }
}

Now this is a little odd because of the top-level dictionary that is being used here. Most of the examples have everything that is inside the value_list being returned. In fact adjusting the controller to return only those items in the value_list values works.

To look inside this structure we need to adjust the jsonReader options. jqGrid documentation uses the format “toptier>subtier” for the XML reader so that was the intial attempt. It was also an intial fail, it doesn’t work and you get your very familiar empty grid.

The trick is close to this format, but slightly different for json. You change the options to “toptier.subtier”. In other words change the greater than symbol to a full stop for json access.

The jqGridWidget now has the following options (amongst others):

options = {
  'datatype': 'json',
  'jsonReader': {
    'repeatitems': False,
    'root': 'value_list.entries',
    'total': 'value_list.total',
    'page': 'value_list.page',
  }
}

There might be a way of saying all entries sit under value_list inside jqGrid, but I couldn’t find it. Those options given above do give a working jqGrid on the admin screens.

Posted on 7 Comments on Odd WordPress pingbacks

Odd WordPress pingbacks

I’m getting some odd log messages for the apache module modsecurity.  Essentially its xml parser is breaking when random places are sending pingbacks. The requests go to xmlrpc.php and the response headers are ok, but the body is binary.  The message in the modsecurity log looks like:

Message: XML parser error: XML: Failed parsing document.

After a bit of guessing and sending messages to and fro, I can now see that it is a gziped response. So I’m not sure if it is modsecurity not realising that the response is gziped or wordpress not marking it correctly. In any case I can regularly get very similar binary strings using gzip and the usual xml response. So that’s half the mystery solved.

Most of the requests are spammers so I’m not too worried.  I think it also impacts legitimate pingbacks because I’ve not had any, even from the usual automatic places.