- 🇬🇧United Kingdom steven jones
@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.- Status changed to Needs work
over 1 year ago 11:21pm 24 March 2023 - 🇺🇸United States tr Cascadia
Marked 🐛 Windows Server 2016+IIS/FastCGI + PHP 7.4.18 or later not compatible Closed: duplicate as a duplicate.
- 🇨🇦Canada endless_wander
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.
- last update
over 1 year ago 3 pass, 1 fail - last update
over 1 year ago Patch Failed to Apply - 🇺🇸United States pixel5
#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.
- 🇦🇹Austria drupalfan2
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.
- 🇮🇳India aadeshvermaster@gmail.com
Hi Team,
I tried patch #23 with 8.x-1.0-alpha5, and its working fine for me.
Thanks
- 🇬🇧United Kingdom steven jones
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.
- I've added a MR that tries to alliaviate the concerns in #6 by removing the extra
- Status changed to Needs review
about 1 year ago 10:50pm 14 October 2023 - last update
about 1 year ago Patch Failed to Apply - 🇺🇸United States rclemings
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.
- last update
about 1 year ago Patch Failed to Apply - 🇳🇱Netherlands mariskath
Dear all,
Thank you for your efforts. Patch #23 worked for me, #34 did not.
Best regards,
Mariska - last update
about 1 year ago Patch Failed to Apply - 🇨🇦Canada joelpittet Vancouver
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
- Open on Drupal.org →Core: 9.5.5 + Environment: PHP 7.3 & MySQL 5.7last update
10 months ago Not currently mergeable. - last update
10 months ago 4 pass, 1 fail - last update
10 months ago 27 pass - 🇨🇦Canada joelpittet Vancouver
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?
- 🇨🇦Canada joelpittet Vancouver
Hiding the patch in #34 because it's a duplicate of the MR3
- 🇨🇦Canada joelpittet Vancouver
joelpittet → changed the visibility of the branch 3257799-rfccomplianceexception-rfc-2822-no-return-path to hidden.
- last update
10 months ago 27 pass - 🇨🇦Canada joelpittet Vancouver
joelpittet → changed the visibility of the branch 3257799-rfccomplianceexception-rfc-2822-no-return-path to active.
- 🇨🇦Canada joelpittet Vancouver
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()
- 🇷🇺Russia DD 85
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).
- 🇨🇦Canada joelpittet Vancouver
@DD 85 it looks like you are missing an email from that error, so might be a different issue. We are using MR 14
- 🇵🇱Poland pawel.traczynski Warsaw
I have tried many ways to successfully send an email using mime mail but ended up commenting out the line code in MimeMailFormatHelper class:
if (!isset($headers['Return-Path']) || $headers['Return-Path'] == $default_from) { // $headers['Return-Path'] = '<' . static::mimeMailAddress($from, TRUE) . '>'; // @see https://www.drupal.org/files/issues/2024-11-20/3488497-1-fix-error-email-not-comply-RFC-2822.patch // @see https://www.drupal.org/project/mimemail/issues/3257799 }
With this everything works, except another hack that I had to implement in the same file, which allowed MimeMail to properly send out emails with Date heade set.
// Run all string headers through UnstructuredHeader() to convert non-ASCII // characters to an RFC compliant string. foreach ($headers as $field_name => $field_body) { // Drupal uses Symfony\Component\Mime\Header\Headers class, where not // all headers are expected/required to be strings (e.g. 'Date' header // is required to be DateTime object). Because of it, skip processing // header body if it is not string. if (!is_string($field_body)) { continue; } $headers[$field_name] = (new UnstructuredHeader($field_name, $field_body))->getBodyAsString(); }
https://www.drupal.org/project/mimemail/issues/3408278#comment-15358107 🐛 Mimemail runs all http headers through UnstructuredHeader() while it should not Active
I am providing this info here because the issue affects the same file. Maybe it helps someone.