That works for me.

Hm.
How?

I’m doing something like this:

$email->getHeaders()->addTextHeader('o:deliverytime', $sendAt->format(\DateTimeInterface::RFC2822));

But I get a payload like: “h:o:deliverytime”

MailgunApiTransport does not do much with various headers:

o:tag with

$email->getHeaders()->add(new TagHeader('tag'));

v:my-var with

$email->getHeaders()->add(new MetadataHeader('my-var', 'value'));

h:X-My-Header with

$email->getHeaders()->addTextHeader('oX-My-Header', 'value');

Oh. I see. Thank you. I was just looking at 5.0.

But there is still no way to set o:deliverytime

It was added here: #35047

That was done for Postmark. To fully support Mailgun, it should be done something similar.

Regarding these:

• [Mailer] message metadata and tags #35047 (comment)
• [Mailer] message metadata and tags #35047 (comment)

@fabpot, can we implement a CustomHeader class instead of a bunch of specialized classes as TagHeader, MetadataHeader and so on, to move all customization logic to the ApiTransport layer?

@greedyivan Yes, I think that is a good idea. The CustomHeader should be able to define both its name and value. Drawbacks of using the custom header is of course that values will be provider specific.

Do you mind submitting a PR?

@Nyholm Drawbacks of using the custom header is of course that values will be provider specific.

I did some research and found out that the only place where it is needed is MailgunApiTransport. Even MailgunHttpTransport, as well as transports of all other providers, do not change the name of the header.

Thus, I suggest break BC and removing the addition of h: to the header in MailgunApiTransport by default.

The upgrade will consist of the need to explicitly set the full name of the header.

Thank you!

Im all for making things consistent. But I really don't want to break BC.
Since this feature is MailgunApiTransport specific again, could we change it slightly so we allow all headers that begins with h:, t:, o:, v: and then fallback to prefix with h:. That will allow us to add this in a BC compatible way.

It is much more complicated than just adding prefix support.

Currently, MailgunApiTransport does not support these parameters of Mailgun API:

• amp-html
• template
• t:version
• t:text
• o:dkim
• o:deliverytime
• o:deliverytime-optimize-period
• o:testmode
• o:tracking
• o:tracking-clicks
• o:tracking-opens
• o:require-tls
• o:skip-verification
• recipient-variables

Just add support for t: doesn't mean anything without template.

I understand that the Mailer component is not a full substitution for the original API library, but we must decide what part of that API it should support. It looks good that it supports arbitrary custom headers using the h: prefix. Should it supports any of Mailgun extensions? If not and we want not to break BC, I think it’s better not to add anything at all.

Let’s not complicate it to much, it’s a BC break but it’s still experimental, so it should be no problem to change this behavior if it makes sense. We did this quite often in messenger component

What @OskarStark said. The goal of a component being experimental is precisely to allow us to break BC whenever it makes sense.