RfcComplianceException: RFC 2822 Return-Path

#3 patch doesn't work with latest alpha5 update.

Thanks @mably for the re-roll.

Just happened to me.

@richard.walker.ardc yeah...but one might consider that to be a configuration error too? @TR could decide if they want the module to support such configurations, especially since in your case it's trivially resolved by selecting MimeMail as the sending class.

The last submitted patch, 23: rcf_compliance-3257799.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Marked 🐛 Windows Server 2016+IIS/FastCGI + PHP 7.4.18 or later not compatible Closed: duplicate as a duplicate.

I am having this problem using a mix of MIMEMail, SMTP Authentication and Mail System modules. The SMTP module maintainers have looked into this issue for their module here -- https://www.drupal.org/project/smtp/issues/3308653 🐛 SMTP From address meta issue Fixed

In Mail System settings, I am using MIME Mail Mailer as the formatter and SMTP Mailer as the sender. This combination is changing the $mailer->Sender value from an address like this:

email@address.com

To this:

<email@address.com>

And thus causing the mail to not get sent with an "Invalid address (Sender)" error.

#28 describes my problem exactly, and #23 fixes it. I am using MIME Mail to format the email and SMTP Authentication Support to send it, as configured in the Mail System module.

I moved servers recently and the only variable that changed was that I moved from using PHP 7.4.33 as mod_php to using the exact same version as PHP-FPM.

I need patch #23 to be able to send mails to mail addresses @gmail.com .
Without patch #23 the SPF entry in our domain is not recognized by gmail and the mail is rejected from gmail.

So this patch should be commited as soon as possible.

Hi Team,

I tried patch #23 with 8.x-1.0-alpha5, and its working fine for me.

Thanks

I ran into this issue again yesterday and it's a bit sad that this is still a problem with stock mimemail.

If I can summarise the patches/MR we have in this issue:

• I've added a MR that tries to alliaviate the concerns in #6 by removing the extra < and > if we're about to call the core email sending.
• We've got a patch in #23 that simply stops adding the < and > wrapping around the return-path address. This seems to have widespread support and lots of people saying it works etc. However in #6 TR you outlined why you don't like this solution.

@TR it would be good to know what sort of approach you might be up for committing? And then we can push into getting that working properly.

Here's a patch for the merge request mentioned by @steven-jones in #33. It strikes me as the better approach given the comments by @TR in #6. I'll mark it as needs review to get the testbot involved.

Dear all,

Thank you for your efforts. Patch #23 worked for me, #34 did not.

Best regards,
Mariska

The easiest [return-]path forward is to remove the <> even though it's valid.

I wonder how those other contrib module senders would break without the <> or do they expect it?

I don't want to discount the strong plea in #10 #3257799-10: RfcComplianceException: RFC 2822 Return-Path → and explaination in TR in #3257799-6: RfcComplianceException: RFC 2822 Return-Path → and it really should be solved in core and/or Symfony. I encourage all who is reading this to read through TRs comments (a few times).

There seems to be a core issue that might resolve this that I plan to test out a bit and try to push forward here:
🐛 Setting the "Return-Path" header doesn't follow RFC 5321 Needs work

#3257799-23: RfcComplianceException: RFC 2822 Return-Path → is the reroll of #3 and my current favourite for RTBCing, but I will leave it not RTBC because it really needs to be addressed in core

New plan, stop setting the Return-Path header (and other from/sender headers). Let the sender decide that (which will need to decide how to get it on the envelope for sendmail).

I deprecated the MimeMailFormatHelper::mimeMailHeaders() public method (in case someone is using it because it's public API)

Thoughts?

Hiding the patch in #34 because it's a duplicate of the MR3

joelpittet → changed the visibility of the branch 3257799-rfccomplianceexception-rfc-2822-no-return-path to hidden.

joelpittet → changed the visibility of the branch 3257799-rfccomplianceexception-rfc-2822-no-return-path to active.

I shouldn't have removed the headers outright in my previous commit to MR14. Adding them back just no longer passing them through MimeMailFormatHelper::mimeMailHeaders()

Guys, I'm confused about which patch to apply and when this problem will be solved.
I get an error when using the Mime Mail formatter.

Symfony\Component\Mime\Exception\RfcComplianceException: Email "" does not comply with addr-spec of RFC 2822. in Symfony\Component\Mime\Address->__construct() (line 54 of /vendor/symfony/mime/Address.php).

@DD 85 it looks like you are missing an email from that error, so might be a different issue. We are using MR 14