from powerMTA to KUMO

Hi for making an ideea regarding KUMO cinfiguratin can you please help me explain how we should translate this vmta configuration from powerMTA to KUMO

host-name fidel.com smtp-source-ip 98.332.10.17

include /etc/pmta/dkim_clients.txt

<domain *>
    dk-sign yes
    dkim-sign yes
    deliver-local-dsn   no
    second-dkim-sign yes
    second-dkim-identity @whi.net
    second-dkim-identity-fallback @whi.eu
    use-starttls yes
    require-starttls no
</domain>
queue-priority 75 max-msg-rate 3550/h backoff-max-msg-per-hour 3550 backoff-retry-after 1h backoff-notify andrei@whi.ro

cold-virtual-mta vmta25
<domain *>
max-cold-virtual-mta-msg 70/day

Hey there @yummy-hawk, thanks for posting. Please read the “Troubleshooting” and “How to Ask for Help” buttons below. If you would like a 1:1 support session from the KumoMTA team, details are at the “Book a Support Session” button below.

I’d suggest starting here: Moving from PowerMTA

:+1:

@yummy-hawk a similar config is in that blog post. In general, much of it can be ignored because we do it by default. DKIM double sign is native if you use the DKIM helper. Queue priority is irrelevant. Back off is all handled in the tsa agent.

Is that the whole config, of just the part you are interested in? I’d be happy to take a deeper look if you want.

that was only one vmta…we still have definitions and conditions depending on the email headers and different rules for certain areas… I was just trying to understand the logic/similarities/differences between PMTA and KUMO

Understood. All of the useful functionality is there, but may be done in a slightly different way. Eh: backoff vs TSA. VMTAs are roughly equivalent to egress sources or Tenants depending on how you use them.

The useless things like priority and run as root are just native by default.

Hello @faithful-ostrich , sorry for chiming in, but I also have a question:
I am trying to mirror a logic we have for the PMTA, when we dynamically assign a second DKIM signature per VMTA (
if vmtaName=something then
second_dkim_identity == somethingelse )
And I am wondering what would be the best way to approach it in Kumo.
I could do it based on each event kumo.on(‘smtp_server_message_received’)
and place
dkim_signer(msg) for the first DKIM signature
and use
kumo.dkim.rsa_sha256_signer() for a second DKIM based on the x-header in the message?
I would appreciate your thoughts.

Is it the same second signature for all?

no, it depends on the VMTA

we have several categories of VMTA’s, and I need to lookup the category, then use it to decide which identity should be added as a second DKIM signature

@yearning-hyena if I sign with
local dkim_sign = require ‘policy-extras.dkim_sign’
dkim_signer(msg)

in init.lua

and then use kumo.dkim_rsa.sha256_signer()
on the same message, will it create a second dkim signature?

In that case yes, you will need to use lua: How Can I Apply Multiple DKIM Signatures to a Message? - KumoMTA Docs

You could combine the two, using dkim_signer for the helper for the default case, then introduce logic to perform the second signature.

Ok, that’s what I thought, thanks!

@yearning-hyena so something like this should work?

dkim_signer(msg)
local double_sign = kumo.dkim.rsa_sha256_signer {
domain = second-dkim-identity
selector = ‘myselector’,
headers = { “From”, “To”, “Subject”, “Date”, “MIME-Version”, “Content-Type”, “Sender”, “Cc”, “Date”, “Message-Id” },
key = “/path/my.key”,
over_sign = true
}
msg:dkim_sign(double_sign)

Essentially yes.

Where is ‘but’? :grinning_face_with_smiling_eyes: