mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 00:35:51 +03:00
[GH-ISSUE #477] Mailpit issue: "mail: expected comma" when releasing plain text emails with attachments #312
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#312
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Srinath-The-Geek on GitHub (Apr 3, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/477
I have configured SMTP relay using ""smtp.mandrillapp.com" as relay host and port as 25 in mailpit
I could release emails that are:
However, when I try to release email with just Text content with attachments, I get the following error:
"mail: expected comma"
FYI - I'm not using MP_SMTP_RELAY_ALLOWED_RECIPIENTS or MP_SMTP_RELAY_BLOCKED_RECIPIENTS
What could be the problem? See the attachment
@axllent commented on GitHub (Apr 4, 2025):
Hmm, that is very strange. That error message you are receiving is almost certainly being returned by
smtp.mandrillapp.com- I just don't know why. I suspect it may be an issue with Mailchimp's SMTP service more than anything. Mailchimp revolves around HTML messages, so their service may be tripping over the fact that a multi-part message (text + attachments) is being received without actually containing any HTML.Could you manually generate and send a plain text message with attachments directly to
smtp.mandrillapp.comto test whether that returns an error too?@Srinath-The-Geek commented on GitHub (Apr 4, 2025):
Mailchimp's Mandrill is our mainstream SMTP service used in our production and all the 3 lower environments. It currently delivers all the emails including this failing one. Our current configuration is:
ERP application generates email > Sends to Postfix > Postfix relays it to Mandrill.
In one of our lower environments, I have changed it to:
ERP application generates email > Sends to Postfix > Postfix relays it to Mailpit > Mailpit relays to Mandrill
Here is the image showing successful delivery of similar emails from another environment:
@Srinath-The-Geek commented on GitHub (Apr 4, 2025):
I've noticed one more thing. Whenever there is a failed attempt of above mentioned emails, I see the following in the mailpit log file:
e5a9ZiHCWLsb9VPfirZf6n does not contain a date header, using received datetime"
@Srinath-The-Geek commented on GitHub (Apr 4, 2025):
FYI - here are the sample headers of email that can be successfully released and the header of email that I could not release:
Header of successful one:
Bcc: Man_Financials_Testing_Infra@coxautoinc.com
Return-Path: Man_Financials_WF_Infra@coxautoinc.com
Received: from infra-man-iad1-ebsapp1.localdomain (unknown [101.116.63.162])
by e9854ea8660a (Mailpit (infra)) with SMTP
for Man_Financials_Testing_Infra@coxautoinc.com; Wed, 2 Apr 2025 04:18:36 +0000 (UTC)
Received: from man-ebs1.epfininf.coxautoinc.com (localhost [127.0.0.1])
by infra-man-iad1-ebs1.localdomain (Postfix) with ESMTP id CAF53120244
for kris.gotsky@coxautoinc.com; Wed, 2 Apr 2025 00:18:36 -0400 (EDT)
Date: Wed, 2 Apr 2025 00:18:36 -0400 (EDT)
X-MC-Tags: OCI_infra, OCI_man, OCI_ebs
From: Workflow Mailer Man_Financials_WF_Infra@coxautoinc.com
Reply-To: Man_Financials_WF_Infra@coxautoinc.com
To: "GOTSKY, KRIS" kris.gotsky@coxautoinc.com
Message-ID: 893125155.998.1743567516811@coxautoinc.com
Subject: For Your Information: No approver found for Purchase Requisition
3889187
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_908_642243458.1743567515741"
Content-Language: en
X-oracle-workflow-nid: NID[53055950/7549590948501463956859983638707343376729264558580@WFMAIL]
------=_Part_908_642243458.1743567515741
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Language: en
Header of failing email:
Bcc: Manheim_Financials_Testing_Infra@coxautoinc.com
Return-Path: Man_Financials_WF_Infra@coxautoinc.com
Received: from infra-man-iad1-ebs1.localdomain (unknown [101.116.63.162])
by bc3454451be0 (Mailpit (infra)) with SMTP
for Man_Financials_Testing_Infra@coxautoinc.com; Wed, 2 Apr 2025 02:46:17 +0000 (UTC)
Received: from infra-exa-iad1-inx1-db-crnc42.localdomain (unknown [101.116.47.137])
by infra-man-iad1-ebs1.localdomain (Postfix) with ESMTP id 25570120244
for Man_Financials_Testing_Infra@coxautoinc.com; Tue, 1 Apr 2025 22:46:17 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by infra-exa-iad1-inx1-db-crnc42.localdomain (Postfix) with SMTP id 12DA4A000D5
for Susan.Ninna@coxautoinc.com; Wed, 2 Apr 2025 02:46:17 +0000 (UTC)
Date: 02 Apr 25 02:46:17
X-MC-Tags: OCI_infra, OCI_man, OCI_ebs
From: AutoInvoiceFailure@Man.com Man_Financials_WF_Infra@coxautoinc.com
MIME-Version: 1.0
To: Susan.Ninna@coxautoinc.com Susan.Ninna@coxautoinc.com
Subject: Man Alert: SCHEDULED Error Occurred during Auto Invoice Master Program -IMEBS on Wed Apr 02 02:46:17 2025
Content-Type: multipart/mixed;
boundary="-----SECBOUND"
Message-Id: 20250402024617.12DA4A000D5@infra-exa-iad1-inx1-db-crnc42.localdomain
-------SECBOUND
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
@axllent commented on GitHub (Apr 4, 2025):
This looks to me to be related to the failing message's
Date: 02 Apr 25 02:46:17- that is not a valid message Date format which explains the Mailpit warning. Compare that to the successfulDate: Wed, 2 Apr 2025 00:18:36 -0400 (EDT). But, the Date header gets overwritten when you manually relay a message, so I don't think that is the reason your message is getting rejected my MailChimp.I suspect it might be related to the structure of the text email. Have you tried to relay directly from that server's postfix to MailChimp (bypassing Mailpit)? That should at least indicate whether it's the message itself or potentially something else.
@Srinath-The-Geek commented on GitHub (Apr 4, 2025):
"But, the Date header gets overwritten when you manually relay a message, so I don't think that is the reason your message is getting rejected my MailChim"
The log message "e5a9ZiHCWLsb9VPfirZf6n does not contain a date header, using received datetime" is not appearing in the mailpit log for the successfully released email. Please see 3rd message upwards from here. Which means that, the date may not be getting replaced for every message that is being released manually.
"Have you tried to relay directly from that server's postfix to MailChimp (bypassing Mailpit)?"
Yes. In the 4th message upwards from here, I have attached screeshots of how similar emails are successfully delivered when mailpit is not involved.
@axllent commented on GitHub (Apr 5, 2025):
Mailpit's warning message is generated only in debug mode when the message is pulled from the database (eg: opening the message in the web UI). You should not be seeing this message when it is releasing the message as it is processed differently.
I have reviewed the code and cannot see why the Date header would not be replaced with a new date - the code in question will look for any existing header (regardless of the original value) and replace that with the current RFC1123Z date & time, ie: in the format
Mon, 02 Jan 2006 15:04:05 -0700.But this isn't the issue (see below).
OK, so I have just reviewed the code and your headers again and have found the issue. Firstly yes, the error is coming from Mailpit, not Mailchimp. The problem is that Mailpit is tripping up over the syntax of the
From:header.In your first message (working) you have
From: Workflow Mailer <Man_Financials_WF_Infra@coxautoinc.com>which is valid, but in the failed one you haveFrom: AutoInvoiceFailure@Man.com <Man_Financials_WF_Infra@coxautoinc.com>- which is being detected as two separate email addresses, and it is complaining that there is a missing comma between them. This is because, to the best of my understanding, the "display name" contains special characters (in this case@) which according to the RFC must be quoted or encoded.The simple fix here is to quote the display name, so
There is an inconsistency here between the mail parsing library used for relaying (native Go functionality) and the module used to "summarise" the message (third party module) - clearly far more lenience within the third party module, but that's not to say the native Go one is wrong. The RFCs take ages to read, and it's not simple to follow either. I couldn't find any clear explanation for the issue (ie: exactly when should a display name be quoted), but it should be in there somewhere I would think. You may want to research that more if you like.
I have added a more meaningful notification to the error message (ie: the popup you got) to at least provide some direction in debugging the error in future - this will be included in future releases. It doesn't fix or change the behavior, but it'll explain the error is in parsing the From header.
@Srinath-The-Geek commented on GitHub (Apr 8, 2025):
Thanks for coming back with your analysis. Those email IDs are generated by mailer service within the proprietary application. I'll check if that's configurable
@github-actions[bot] commented on GitHub (Apr 16, 2025):
This issue has been marked as stale because it has been open for 7 days with no activity.
@github-actions[bot] commented on GitHub (Apr 20, 2025):
This issue was closed because there has been no activity since being marked as stale.