Smime signing for system notifications

Feature requests
1
  1. What is your original issue/pain point you want to solve?

It is possible to modify the system notifications described in the documentation but
it is not possible to sign these outgoing emails with smime.

  1. Which are one or two concrete situations where this problem hurts the most?
    All emails send as system notification are not signed.
  2. Why is it not solvable with the Zammad standard?
    smime can only be used for customer communication, not for system notifications
  3. What is your expectation/what do you want to achieve?
    Every outgoing system message is signeable.
4 Likes
2

I would like to bring this up again, because the need still exists for us.

After looking at the current code, the central path for built-in system notification emails seems to be:

  • lib/notification_factory/mailer.rb
  • especially NotificationFactory::Mailer.deliver

Ticket communication already uses the existing secure mailing infrastructure by passing security into channel.deliver. A possible implementation approach for system notifications could be to reuse the existing S/MIME notification option handling, for example via:

  • SecureMailing::SMIME::NotificationOptions

The requested scope would be signing only, not encryption:

  • If S/MIME integration is enabled,
  • and the configured notification_sender has a valid private S/MIME certificate,
  • system notification emails should be S/MIME-signed.

Open design question:
Should this happen automatically when S/MIME is enabled and a matching certificate exists, or should there be a separate admin setting, e.g. smime_sign_system_notifications?

I would be happy with either approach. The important part for us is that built-in system emails such as password reset messages, signup/account emails, admin/security tokens and similar notifications can be signed without relying on an external mail gateway workaround.

3

I think admins have to decide, similar to the trigger approach. However, it‘s sonewhat more complicated, because triggers can run in a much narrower scope than a notification does.

5

Thanks, that makes sense.

I agree that admins should decide this explicitly. I also see the difference to triggers: trigger-based email notifications can be scoped quite narrowly, while built-in system notifications are broader and cover different use cases.

I prepared a small draft implementation as a starting point for discussion:

The draft currently uses a global opt-in setting:

  • smime_sign_system_notifications
  • default: disabled
  • signing only, no encryption
  • applies to built-in system notifications sent through NotificationFactory::Mailer
  • if no matching private S/MIME certificate exists for notification_sender, delivery continues unsigned

This is intentionally conservative and does not change existing behavior by default.

If a more granular approach fits Zammad better, one could adjust the design in that direction. Possible options might be:

  • separate signing policies per notification type/template,
  • signing only selected security-sensitive templates such as password reset, signup/account confirmation, admin/security tokens,
  • or keeping a single global opt-in switch as a first iteration.