http://gallery.sakienvirotech.com/index.php/

Chris Wilson in Avoca, there's other bands as well but Chris Wilson in Avoca...

http://www.avocamusicfestival.com/

Russell Drever at Westbury Antiques

The detail behind this is that I have two virtual servers that are with a VPS provider, on two completely different subnets and from the time they were commissioned, no email has been accepted by Yahoo! for its account holders with an error message that appears to be for persistent spamming.  This is clearly an error, one that I have tried for weeks now to resolve with Yahoo! without success.  They will not admit that their detection of spamming cannot be for mail they have yet to receive, but instead most likely for a previous owner of the IP addresses in question. They will not provide any clear information even as to the reason that we are - in their quaint and completely incorrect terminology - "deprioritized".

I don't really want prioiritised mail services, any level of mail service would be fine with me, and I suspect with those users who in good faith have signed up with one of the services we host.  "Deprioritized" suggests that there is a chance the mail will get through, just not in a timely fashion. What we have is in fact a complete embargo on mail from our servers.

It doesn't matter how you wrap it up or what policies you quote ad-infinitum, Yahoo!  If your system starts blocking mail on the first attempt then there is something wrong with your system, not mine.  If it is for prior usage of the IP address, then provide me with the methods of showing that the IP address changed hands so you can reset your system. Don't lie to me and tell me that it is temporary and will resolve itself once I get my systems in line with your policies.  It is not temporary, it is a complete block.  My systems are in line with your policies and have been for quite some time.  You will not answer any of my questions with anything other than a pointer or extract from your policy documents - so I have no idea (and I suspect neither do you) of why I am listed at all, let alone how to resolve it.

So if you are a Yahoo! account holder, stop this nonsense by switching provider. I can't be the only service provider that is affected this way, so even if you are not on one of the services we host, I can assure you there is a good probability you are affected.

If you are Yahoo!, stop this nonsense by acknowledging your system is flawed and fixing it.

For events registration we use the Signup module and use a theme template function to provide a set of standard fields.  The code looks something like this:

function ourtheme_signup_user_form($node) {
  $form = array();
  // If this function is providing any extra fields at all, the following
  // line is required for form form to work -- DO NOT EDIT OR REMOVE.
  $form['signup_form_data']['#tree'] = TRUE;

  $form['signup_form_data']['FirstName'] = array(
    '#type' => 'textfield',
    '#title' => t('First Name'),
    '#size' => 40, '#maxlength' => 64,
    '#required' => TRUE,
  );
  $form['signup_form_data']['LastName'] = array(
    '#type' => 'textfield',
    '#title' => t('Last Name'),
    '#size' => 40, '#maxlength' => 64,
    '#required' => TRUE,
  );

And so on, building up the elements and then returning the form.  This is great because it allows us to have a standard set of fields for all signup pages, making life a lot simpler when creating content that requires registration.  But the Solutions Day event required an extra field.  I could have done this a number of ways, including putting logic in the template file to check for that particular node and only display the field then, or perhaps some other hack specific to this node.  I, however, don't like specifics and tend to look for a generic solution, as the exception invariably becomes the rule.

For this exercise I wanted to be able to have a way of specifying for a particular node any extra fields that are available for this form.  So I now have in the template.php file the following code:

// If there is a special field required for this, check and display
  if (!empty($node->field_signup_extra) && !empty($node->field_signup_extra[0]['value'])) {
    $extras = explode("\n", $node->field_signup_extra[0]['value']);
    foreach ($extras as $field_def) {
        $field_def = trim($field_def);
        if (empty($field_def)) {
            continue;
        }
        $elems = explode('|', $field_def);
        $field_name = array_unshift($elems);

        $form['signup_form_data'][$field_name] = array();
        foreach ($elems as $field_element) {
          list($key, $val) = explode('=',$field_element);
          if ($key == 'options') {
              $val = explode(',', $val);
          }
          $form['signup_form_data'][$field_name]['#' . $key] = $val;
        }
    }
  }

Now all I need to do is create a field that is non-displayable but contains information to build extra fields.  For example the content that describes the Dietary Requirements field is:

dietary_requirements|title=Dietary Requirements|size=40|type=textfield

The production version does a little more analysis of the input to ensure there are no possible attack vectors, but I've left that out for clarity sake.

Now, if I have an event (or other content type) that needs extra signup fields, I ensure that the content type has the new Signup Extras field and fill it on the new content with a simple field definition that Signup can use.

Given this was heading pretty much straight for us at one point yesterday, it has to be a lucky thing that we got a chance to practice the fireplan with a heightened sense of urgency.

Things that Worked Well:

We heard about the fire quickly (heard the Siren / checked the CFA situation on the mobile - knew we had something too close for comfort very quickly).

The equipment (Tractor with water tanker from next door), fire pump on the dam, spray unit on the Quad bike from next door, back pack spray unit, clothes, face masks, etc all deployed quickly (under 10 mins).

House shut down and dogs / one cat secured in the same time.

Fire activity monitored visually from the top of the ridge here and next door, and wind direction / possible impact zones identified very quickly (hence deployment of the equipment where we did).

Alpacas into the paddock behind the house directly opposite possible fire direction - with options for bringing them into a more secure area where we could stand and defend them and the rest of the livestock if necessary.

Realised that the pigs have created quite a fire barrier at the front more by accident than design.

Communications equipment between us worked really well and over a very good distance.

Strategy for impact worked out and jobs assigned between us.

Ready to go / into watch and act mode in < 15 minutes.

Things that We Need to Think About:

Couldn't find one of the cats.  Need to consider how we go about including her in the lockdown in the future.

Need to do the boundary patrols regardless of whether it's a total fire ban day or not.  Any heightened wind = trouble when it's this desperately dry.

The tanker / bike were only here are as a result of next door neighbour being away - need to get our water tank onto a moveable source.

Will need to further consider our options in terms of a quad bike.  This made the run up and down the hill to monitor much quicker - and with the spray unit attached / full of water gave us a mobile spot fire unit (allowing for not being useable in the event of large breakouts / big spotting attacks).  As a quick attack vehicle it had potential - have added this to the general pros and cons discussion about buying our own unit.

Need to rethink the respirator options we have.

Fire fighting clothing needs to be more readily accessible at the back of the house.

Need to have the portable scanner back and operational as we don't want to have to keep returning to the house to monitor fireground updates.

Observations in General:

Local CFA brigades were brilliant.

Local knowledge is unbeatable.

Assess the risk and impacts quickly but carefully

DON'T PANIC

Watch - get outside and really bloody look.

You'd be utterly and completely barking bloody mad to rely on websites or updates or anything from any central source.  Fireground updates on the scanner were SO far ahead of the central comms.

Keep in touch with each other and know what each other is doing / where everybody is.

Debrief / adjust the plan.  Tweak / rework it frequently.

Don't think you've got it 100% right.  Always room to improve.

Here's a hint Yahoo.  If you don't tell me what the problems are, I can't fix them.  A basic tenet of support. If you keep me in the dark then I will have to start banning users with yahoo.com* addresses as it is just too hard to deal with you.  I'll have to tell them all to get a real mail account, like Gmail, so they don't have to bitch about not getting important emails. Perhaps this is why you are losing users?

While I was researching the possible reasons for by blocking I found that there are some really dodgy practices going on out there.  I checked my Reputation Score with a number of sources, and found that it was pretty good, except for one, Cisco's SenderBase.  And I can't send email to them about the problem from the problematic domain. Mind you one had information on email that went back 4 years and showed no recent activity - and I didn't own that IP address 4 years ago.   There is one, Barracuda, that suggests you sign up at EmailReg.org for $20 per year to bypass their reputation filter - um, that is uncomfortably close to blackmail for my liking.  Then there is the abuse.net system.  It appears that many reputation scores will reduce your reputation if you haven't taken the trouble to register a contact address for your domains at abuse.net.  WTF? The internet standard is that there is always a postmaster@ address that must go to a real person.  In recent times it has also become common practice to have an abuse@ address.  Since when does it become mandatory to register this somewhere?  How does that in any way contribute to the removal of SPAM?

Abuse.net also has some quirks.  With the rise of SPAM many people who set up a new domain take the precaution of using a hidden registration option offered by many domain registrars, to avoid having your contact details harvestable by spammers.  And guess what, you can't register these at abuse.net because they believe that you are likely to be a spammer if you want anonymity. Catch 22.

So the upshot appears to be don't send email - use a carrier pigeon instead.