Confirmation link in double opt-in mail gets corrupted domain (`example..com` instead of `example.com`) when using the default `f:link.action` mail template pattern

[lars-brinkmann]

Bug report: Confirmation link in double opt-in mail gets corrupted domain (example..com instead of example.com) when using the default f:link.action mail template pattern

Powermail version: 12.6.0
TYPO3 version: 12 LTS
PHP version: 8.2.31

Summary

The double opt-in confirmation link generated by Powermail's default mail template pattern intermittently produces a corrupted absolute URL, where an extra dot is inserted into the domain name (e.g. https://example.de/... becomes https://example..de/...). This corrupts the href attribute of the confirmation link and breaks it for the recipient.

Steps to reproduce

Using the standard confirmation mail template pattern as documented/shipped with Powermail:

<f:format.htmlentitiesDecode>
    <f:link.action action="optinConfirm" absolute="1" arguments="{hash: hash, mail: mail}">
        Confirm subscription
    </f:link.action>
</f:format.htmlentitiesDecode>

Send a form submission with double opt-in enabled and inspect the raw source of the resulting HTML email.

Actual result

The href attribute of the generated <a> tag occasionally contains a duplicated dot in the domain, e.g.:

<a href="https://example..de/kontakt?tx_powermail_pi1%5Baction%5D=optinConfirm&...">

This was confirmed by inspecting the raw MIME source of the delivered email (not just the rendered view in a mail client), so the corruption is present in the actual bytes sent by TYPO3, not introduced by mail transport, gateway, or mail client rendering.

Expected result

<a href="https://example.de/kontakt?tx_powermail_pi1%5Baction%5D=optinConfirm&...">

Isolation / additional findings

I tested three variants side by side in the same mail template to isolate the cause:

<!-- Variant 1: default Powermail pattern -->
<f:format.htmlentitiesDecode>
    <f:link.action action="optinConfirm" absolute="1" arguments="{hash: hash, mail: mail}">
        Confirm subscription
    </f:link.action>
</f:format.htmlentitiesDecode>

<!-- Variant 2: plain f:uri.action, no tag builder involved -->
<p><f:uri.action action="optinConfirm" absolute="1" arguments="{hash: hash, mail: mail}" /></p>

<!-- Variant 3: manual <a> tag using f:uri.action for the href -->
<p>
<f:format.htmlentitiesDecode>
    <a href="{f:uri.action(action: 'optinConfirm', absolute: 1, arguments: '{hash: hash, mail: mail}')}">Confirm subscription</a>
</f:format.htmlentitiesDecode>
</p>

Result:

• Variant 1 (f:link.action): corrupted — example..de
• Variant 2 (f:uri.action only): correct — example.de
• Variant 3 (manual <a href> built from f:uri.action): correct — example.de

This indicates the corruption is not caused by f:uri.action's URI generation itself (both Variant 2 and the URI used in Variant 3 come from the identical code path), but specifically by f:link.action's tag-building step (TYPO3\CMS\Fluid\ViewHelpers\Link\ActionViewHelper / Fluid TagBuilder), which — per TYPO3 core source — internally reuses the same URI generation as Uri\ActionViewHelper::createUriWithExtbaseContext() but then assembles the <a> tag around it.

Since this points to TYPO3 core's Fluid Link\ActionViewHelper/TagBuilder rather than Powermail-specific code, this may ultimately need to be reported/fixed upstream in TYPO3 core — but I'm opening it here first since Powermail's own documented/shipped mail template uses exactly the affected pattern (f:link.action wrapping the visible link text, historically shown alongside a nested f:uri.action in some template examples), so other Powermail users on TYPO3 12 are likely affected without realizing it.

Suggested workaround for Powermail's mail templates

Replace f:link.action with a manually built <a> tag using f:uri.action for the href, as in Variant 3 above, in the shipped mail Partials/Templates (e.g. Resources/Private/Templates/Mail/..., optin confirmation partial).

Environment

• TYPO3 12 LTS
• Powermail 12.6.0
• Double opt-in enabled
• Confirmed via raw MIME source inspection of the delivered email (not client rendering)