8000 [RFC] DkimSigner (and SMimeSigner & Encrypter) return type · Issue #53939 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[RFC] DkimSigner (and SMimeSigner & Encrypter) return type #53939

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jontjs opened this issue Feb 14, 2024 · 3 comments
Closed

[RFC] DkimSigner (and SMimeSigner & Encrypter) return type #53939

jontjs opened this issue Feb 14, 2024 · 3 comments
Labels
RFC RFC = Request For Comments (proposals about features that you want to be discussed) Stalled

Comments

@jontjs
Copy link
Contributor
jontjs commented Feb 14, 2024

Description

I'm new to (DKIM)signing emails, and have a couple, of observations/suggestions that might make the process easier to work with.

The DkimSigner's sign() method (and SMimeSigner's sign() method & SMimeEncrypter's encrypt() method, though I haven't used those) returns a Symfony\Component\Mime\Message but this can cause a problem when used to sign an object type that extends that Message class.

My specific problem was #53928 (Web profiler "Emails" tab breaks with signed emails) but I suppose other things might need to get the same object type back from the method as they passed to it) because the profiler was expecting an Email object but got a Message object.

Perhaps the PHP return type doesn't need changing, and the method logic could clone the passed $message and perform its operations on that clone, then return that clone? I'm not sure if PHP's return declarations are strict in that way, or whether it is allowed to return a class that extends the one in the return type.

I also don't know if something absolutely needs those methods to return a Message and not some other object that extends it.

Example

No response

@carsonbot carsonbot added the RFC RFC = Request For Comments (proposals about features that you want to be discussed) label Feb 14, 2024
@carsonbot
Copy link

Thank you for this suggestion.
There has not been a lot of activity here for a while. Would you still like to see this feature?

@carsonbot
Copy link

Hello? This issue is about to be closed if nobody replies.

@carsonbot
Copy link

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC RFC = Request For Comments (proposals about features that you want to be discussed) Stalled
Projects
None yet
Development

No branches or pull requests

2 participants
0