Skip to content
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

[Bug]: Name not handled in "reply to" and recipients #30

Open
paindaveine opened this issue May 5, 2024 · 2 comments
Open

[Bug]: Name not handled in "reply to" and recipients #30

paindaveine opened this issue May 5, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@paindaveine
Copy link

What happened?

When couples (email, name) are provided in message, only email addresses are kept in the final message sent, except for e-mail addresses known by the tenant, for which the name known in tenant is used.

Seems that problem can be solved by adding one line 'name' => $address->getName(), in function transformEmailAddress() of MicrosoftGraphTransport.php

protected function transformEmailAddress(Address $address): array
    {
        return [
            'emailAddress' => [
                'address' => $address->getAddress(),
                'name' => $address->getName(), 
            ],
        ];
    }

How to reproduce the bug

Send e-mail with recipient or "reply to" not known by the tenant

Package Version

1.3.0

PHP Version

8.2.11

Laravel Version

11.6.0

Which operating systems does with happen with?

macOS, Linux

Notes

No response

@paindaveine paindaveine added the bug Something isn't working label May 5, 2024
geisi added a commit that referenced this issue May 8, 2024
@geisi
Copy link
Contributor

geisi commented May 8, 2024

@paindaveine
I tried to fix that issue in the https://github.com/InnoGE/laravel-msgraph-mail/tree/30-bug-name-not-handled-in-reply-to-and-recipients branch.

Unfortunately in my tests, adding the name property does not change the behaviour. It seems that it is not supported by Microsoft to set the Name implicitly. Can you confirm that?

@paindaveine
Copy link
Author

According to my tests, behavior is different if e-mail address is known by the Microsoft tenant or not. See this example:

$recipientsByAddress[$address][] = [
                'email' => '[email protected]',
                'name' => 'test InnoGE JPA',
            ];

$recipientsByAddress[$address][] = [
                'email' => '[email protected]',
                'name' => 'test InnoGE Inscription',
            ];

$recipientsByAddress[$address][] = [
                'email' => '[email protected]',
                'name' => 'test InnoGE CPA',
            ];

First two are email addresses that are known by the sender tenant, either as redirect address ordirectly as a user :

image

image

Without the fix, here is the content of to: section in the raw message:

To: Jean Paindaveine -adresse gmail <[email protected]>,
	=?iso-8859-1?Q?Inscription_acad=E9mie_eghez=E9e?=
	<[email protected]>, "[email protected]" <[email protected]>

You can see names are the ones of microsoft tenant if known, and copy of email address if not.

With the fix, here is the content of to: section in the raw message:

To: Jean Paindaveine -adresse gmail <[email protected]>,
	=?iso-8859-1?Q?Inscription_acad=E9mie_eghez=E9e?=
	<[email protected]>, test InnoGE CPA <[email protected]>

You can see names are still of microsoft tenant if known, but this time the name explicitly added in recipients is used instead of email address if not known by the tenant.

According to my tests, the fix corrects the usage of names for "external" addresses not known by the microsoft tenant of sender, but it changes indeed nothing for known addresses, as stated in original post.

Anyway, many thanks for your code and explanation!
I was stuck by frequent and unavoidable session timeout in using Horizon with SMTP server...

@geisi geisi linked a pull request Aug 27, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants