Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Mailer] DataPart#setContentId requires @ #54162

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.

Sign up for GitHub

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

Jump to bottom
Closed
boesing opened this issue Mar 5, 2024 · 10 comments · Fixed by #57295
Closed

[Mailer] DataPart#setContentId requires @ #54162

boesing opened this issue Mar 5, 2024 · 10 comments · Fixed by #57295
Labels
Bug Mailer Status: Needs Review

Comments

@boesing
Copy link
Contributor

boesing commented Mar 5, 2024 •
edited
Loading

Symfony version(s) affected

6.2.0 - 7.0.5

Description

We are using symfony/mailer to partially forward messages with attachments as they were received i.e. from outlook, gmail, etc. accounts.

Some mail clients seem to create attachments with content-ids not containing @ which led to issues when forwarding those messages via symfony/mailer.
We do now have to generate that @-Part plus replacing the non-@-content id within HTML bodies. Tho it does work to manually search/replace cid:<contentIdWithout@>, this feels kinda weird.

From what I can read from the RFC (mentioned in the PR referenced below), there is no requirement for an @ and since there are clients out there which do generate mails without @ which are properly displayed in other mail clients, etc. I wonder if this "validation" is really necessary.

Refs: #46962

How to reproduce

Extracted from the DataPartTest#testSetContentIdInvalid of #46962

$part = new DataPart('foo');
$part->setContentId('test');

Possible Solution

Maybe, allow passing a strict boolean flag via __construct which allows projects as ours to bypass this kind of validation.
I have no idea why it had to be implemented in the first place but as I am aware of the BC contract symfony is pushing, I'd be fine with opt-in for non-strict validation.

Additional Context

    /**
     * @return $this
     */
    public function setContentId(string $cid): static
    {
        if (!str_contains($cid, '@')) {
            throw new InvalidArgumentException(sprintf('Invalid cid "%s".', $cid));
        }

        $this->cid = $cid;

        return $this;
    }
    public function testSetContentIdInvalid()
    {
        $this->expectException(InvalidArgumentException::class);

        $p = new DataPart('content');
        $p->setContentId('test');
    }
@boesing boesing added the Bug label Mar 5, 2024
@dakujem
Copy link

dakujem commented May 30, 2024

Bump!

Confirmed for being present since 5.x till 7.x (at least till 7.2)
image

I dare suggest updating the documentation as the fastest and non-breaking way to fix this issue, the underlined parts not being accurate:
image
Changing footer-signature to footer-signature@my-app would do.

@fabpot
Copy link
Member

fabpot commented May 30, 2024

If having @ is not a requirement in the spec, let's remove the check. That seems the most appropriate fix here.

@dakujem
Copy link

dakujem commented May 30, 2024

I don't know what the spec is, to be honest.
I followed the documentation and bumped into the issue. That's why I suggested correcting the documentation to be in line with the implementation as the least-effort solution.

I may try to prepare a PR for either of the possible solutions. Let me know.

@dakujem
Copy link

dakujem commented May 30, 2024

I found this RFC 2392.

It refers to addr-spec from RFC 822, which does indeed specify the format as local-part "@" domain.

So provided the RFCs are in use, it would seem the CID has to contain at least one @ character. What I'm not sure is whether Symfony should or should not restrict the choice of CID.

Also, I suggest adding the info to the restriction for further clarification. Something in the line of "This restriction is in place for CID to adhere to RFC 2392 which requires URL-encoded RFC 822 addr-spec string." If someone stumbles upon the restriction in code they can refer to the documents for reasoning.

@boesing
Copy link
Contributor Author

boesing commented Jun 2, 2024

The issue I faced when I opened this issue on github was, that I was passing a parsed content id from a mail Ive received. The Mail was properly displayed in a bunch of Mail clients (well I guess these have to deal with a lot of stuff) and thus I was expecting that there is no requirement for an @

That is why I suggested to have a strict-like flag one can toggle when dealing with mails not properly providing a proper content id.

For now, we are adding an @ and then search/replace the HTML body of a mail since these do contain references to the image with "invalid" content id.

Imho thats not a good solution but works for now (we are forwarding parsed mails and thats why we have to deal with it). So it would help if at least the strictness could be toggled off so that there is no need to replace HTML body as in our case.

@fabpot fabpot mentioned this issue Jun 3, 2024
Merged
@fabpot
Copy link
Member

fabpot commented Jun 3, 2024

See #57295 for a better error message.
Regarding the toggle, we tend to avoid them as much as possible in general, especially for such a very specific behavior.

@dakujem
Copy link

dakujem commented Jun 3, 2024

So if it was agreed that the @ sign restriction should be in place, the documentation should be updated not to be misleading.

@xabbuh
Copy link
Member

xabbuh commented Jun 3, 2024

PR welcome to improve the documentation

@boesing
Copy link
Contributor Author

boesing commented Jun 3, 2024

Regarding the toggle, we tend to avoid them as much as possible in general, especially for such a very specific behavior.

Understood. Thanks for the feedback.

@boesing boesing closed this as not planned Won't fix, can't repro, duplicate, stale Jun 3, 2024
@fabpot fabpot closed this as completed Jun 4, 2024
fabpot added a commit that referenced this issue Jun 4, 2024
@fabpot
minor #57295 [Mime] Tweak an exception to be more descriptive (fabpot)
ea47cb4 
This PR was merged into the 7.2 branch.

Discussion
----------

[Mime] Tweak an exception to be more descriptive

| Q             | A
| ------------- | ---
| Branch?       | 7.2
| Bug fix?      | no
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Issues        | Fix #54162 <!-- prefix each issue number with "Fix #", no need to create an issue if none exists, explain below instead -->
| License       | MIT

Commits
-------

b5cacc9 [Mime] Tweak an exception to be more descriptive
@dakujem dakujem mentioned this issue Jun 7, 2024
Merged
@dakujem
Copy link

dakujem commented Jun 7, 2024

Dox PR here: symfony/symfony-docs#19946

javiereguiluz added a commit to symfony/symfony-docs that referenced this issue Jun 10, 2024
@javiereguiluz
minor #19946 [Mailer] Fixed and clarified custom Content-ID feature d…
90140b4 
…ocumentation (dakujem)

This PR was merged into the 6.4 branch.

Discussion
----------

[Mailer] Fixed and clarified custom Content-ID feature documentation

> Addresses [symfony/symfony #54162](symfony/symfony#54162)

The documentation is incorrect, as it shows calls to `DataPart::setContentId` with strings that are rejected by [the method's implementation](https://github.com/symfony/symfony/blob/7.2/src/Symfony/Component/Mime/Part/DataPart.php#L66), because they do not contain a required `@` character.

![image](https://github.com/symfony/symfony/assets/443067/560fd816-e4d2-4a48-8d82-ef7dfa38db16)

I also added a sentence clarifying that the actual Content-ID value will be ramdom-generated by Symfony when not using a custom Content-ID.

This feature has been added in `v6.3` (according to the documentation) and the documentation is incorrect throughout versions `6.3`, `6.4`, `7.0`, `7.1` and `7.2`.
I'm not sure how to distribute this PR to all other branches - should I create separate PRs for each?

Commits
-------

468a9ac [Mailer] Fixed and clarified custom Content-ID feature documentation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Mailer Status: Needs Review
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[Mime] Tweak an exception to be more descriptive fabpot/symfony
5 participants
@fabpot @dakujem @xabbuh @boesing @carsonbot