Call to undefined method Swift_Mime_Headers_UnstructuredHeader::getAddresses()

The From field in the issue summary is correctly encoded... as far as I can see...

>>> iconv_mime_decode('=?utf-8?Q?=D0=A1=D0=B4=D0=B0=D0=B9-=D0=BB=D0=BE=D0=BC?=.рф <info@sday-lom.ru>');
=> "Сдай-лом. <info@sday-lom.ru>"

Background

We've encountered the same issue after we upgraded Core from Drupal 9.1.10 to 9.2.2
Mail System 8.x-4.3
SwiftMailer 8.x-2.0

Steps to reproduce the issue

1. Install new drupal site 9.2.
2. Enable mail system, swiftmailer.
3. Set your mailsystem to assure the default sender as Swiftmailer. (/admin/config/system/mailsystem)
4. Configure your transport settings to any SMTP service you're using. (/admin/config/swiftmailer/transport)
5. Set Site Name as Chinese character that is equivalent to 7 characters(Use: 台灣永續展望天) at Basic site settings (/admin/config/system/site-information). (Six characters doesn't show error, probably it suits the encoding of Symfony Mime without going wrong dealing with Chinese characters)
6. Send a test email to see error message (/admin/config/swiftmailer/test).

Temp Solution We Figured out

The temporary solution of this issue for us was by changing our site name to pure english. (We're building a Chinese Site).

The Cause

As mailManager.php has been updated since Drupal 9.2, \Drupal\Component\Utility\Mail::formatDisplayName() was replaced by \Symfony\Component\Mime\Header\MailboxHeader.

New code as seen below.
Read Change Records. https://www.drupal.org/node/3207439

    // To prevent email from looking like spam, the addresses in the Sender and
    // Return-Path headers should have a domain authorized to use the
    // originating SMTP server.
    $headers['From'] = $headers['Sender'] = $headers['Return-Path'] = $site_mail;
    // Make sure the site-name is a RFC-2822 compliant 'display-name'.
    if ($site_mail) {
      $mailbox = new MailboxHeader('From', new Address($site_mail, $site_config->get('name') ?: ''));
      $headers['From'] = $mailbox->getBodyAsString();
    }

While processing through $mailbox->getBodyAsString(), our Chinese encoding has gone wrong running getTokenAsEncodedWord() in vendor/symfony/mime/Header/AbstractHeader.php.

Drupal 9.1 "=?UTF-8?B?5Y+w54Gj5rC457qM5bGV5pyb5aSp?="
Drupal 9.2 (6 Character, 台灣永續展望) "=?utf-8?Q?=E5=8F=B0=E7=81=A3=E6=B0=B8=E7=BA=8C=E5=B1=95=E6=9C=9B?="
Drupal 9.2 (7 Character, 台灣永續展望天) "=?utf-8?Q?=E5=8F=B0=E7=81=A3=E6=B0=B8=E7=BA=8C?=
=?utf-8?Q?=E5=B1=95=E6=9C=9B=E5=A4=A9?="

When seen in our mailhog, with patch#3 given by OP, it shows the wrong character on the FROM name of email.

So for now the preg_match pattern in SwiftMailer that checks doesn't fit the new Q-encoding styling in

web/modules/contrib/swiftmailer/src/Utility/Conversion.php

   if (static::swiftmailer_is_mailbox_header($key, $value)) {
      return SWIFTMAILER_HEADER_MAILBOX;
    }

// Line 217, This will return false when supposed to be true in "From"
  public static function swiftmailer_is_mailbox_header($key, $value) {
    if (preg_match('/' . static::SWIFTMAILER_MAILBOX_PATTERN . '/', $value)) {
      return TRUE;
    }
    else {
      return FALSE;
    }
  }

Therefore returning false, not setting the headerType correctly in line 248 of web/modules/contrib/swiftmailer/src/Plugin/Mail/SwiftMailer.php.

should be "mailbox", instead "text" was returned.

Add patch to remove new lines and carriage in returned string for encoded long site name.

Setting issue status to need review

Patch adds 2 coding standards violations. You should be using short array syntax, [] instead of array().

Otherwise, looks good.

Update patch to meet coding standards, thanks @TR!
Hooray! @super_romeo

Patch from #13 worked for me.

Thanks for the patch. Please can someone explain in more detail? It seems that this patch is saying that line-breaks are legitimate inside mailbox headers and they can safely be ignored. Is there a webpage or specification that confirms this?

The comments should be updated to contain the explanation please. And I suggest to remove the reference to a specific version of Drupal.

It would be great to have a test to validate this case. It should be simple: just use the example from the issue summary or one of the comments.

@AdamPS yes line breaks are totally legitimate within a mime header. The spec on mime headers is very specific about line lengths. Note that a line break within a header does not mean a line break within the header value. Have a look at #84883: Unicode::mimeHeaderEncode() doesn't correctly follow RFC 2047 and the related RFCs.

Thanks @alexpott.

I would suggest the comments could be written as Alex says:

Remove line breaks, which are legitimate within a mime header. A line break within the header does not mean a line break within the header value. See RFC 2047, the related RFCs. @see https://www.drupal.org/project/drupal/issues/84883.

Updated patch comment by suggestion on #17, thanks to @AdamPS and @alexpott.

Great thanks. All this needs now is a simple test (see #15) then it can be committed.

Added fail and success test on Utilities of Conversion static function

1. swiftmailer_is_mailbox_header (should return true after patch)
2. swiftmailer_parse_mailboxes (decoded text should match site_name given after patch)

Swapping the assertEquals to meet argument description (swapping expected and actual variables).

Add interdiff.txt

Great thanks. Please can you fix the 4 extra coding standards messages? After that it's good to commit.

Hi @AdamPS, thanks for reviewing the patch, but I think I'm missing two other that's within the scope?

Currently I fixed
Line 217 Line exceeds 80 characters; contains 89 characters
Line 302 Line exceeds 80 characters; contains 95 characters

Thanks. You did it right - removing the use statements fixed the other 2.

Good to know, thanks!

Can someone explain why is this issue marked as "Fixed"? I didn't see any related commits into the module.

@AdamPS maybe you need to push :) (the number of times I've forgotten to do that...)

Oops thanks for the reminder.