How does ITIL handle frequent adjustments to mailserver?

Question

We run a MTA (mail server) to send out large numbers of emails (newsletters...). Sometimes we have to adapt on short notice the configuration of this system, i.e. slow down the send out for one specific receiving domain like (gmail) or enable encryption (TLS) for another. We do not know in advance and cannot test it as the receiving domains may change their behavior even within minutes as part of their spam protection processes.

Technically we have edit configuration files using a UI and restart the mail server.

From a "service point of view" the mail service is interrupted and needs to be fixed ASAP.

How would one organize such a change in ITIL? Ideally we should not have any lead time before we are allowed to change the configuration (as the service is interrupted and mails cannot be send out).

Answer 1

What you've described sounds like a candidate for a Standard change in ITIL.

ITIL defines 4 levels of requests for change.

• Standard
• Normal
• Emergency
• Major

A standard change is essentially any change who's inputs and outcomes are known, has a standard way of being implemented (Script Run, Cron Job, Server Restart) and which happens regularly. This blog goes into more detail of Std vs. Norm if you're interested. And this page outlines all 4 types in more detail.

How to manage Standard changes?

The CAB has made a decision at some stage that this change can be deemed standard, due to it's regularity and low likelihood of failure. Thus, standard changes do not need to be vetted by the CAB, which removes some of the time lag between request and approval.

However, with any change there should be some record of the request being made. As such, these can be managed through something like a pre-defined Service Request. Once the request is submitted, it is automatically approved and can be actioned - removing the time delay completely.

You will need to define some business rules around parameters you need, time for changes to occur and an expected timeframe for the change to be completed in.

User story:

As a user, I can select a Mailserver Change request from the service catalogue. Then when submitted, your team may carry out the change at the requested time. Then when the change is successful, the ticket will be closed as complete.

Managing exceptions

At some stage this standard change will fail and cause an event or incident, or perhaps the user may ask for some change parameters to change.

At either of these points, the change should be passed back to the CAB for re-assessment. Once the CAB are happy that the change's likelihood of failure, or potential impact is acceptable, they can again approve for this to become a Standard change. This may only take one CAB cycle.

This caveat should also be communicated to the requesters at the implementation of the process.

---

Assumptions:

• You have a CAB to approve this change to become standard
• You have an ITSM system with which to track these records
• The mail server restart is an accepted outcome of the change taking place