Mailpit issue: "mail: expected comma" when releasing plain text emails with attachments

[Srinath-The-Geek]

I have configured SMTP relay using ""smtp.mandrillapp.com" as relay host and port as 25 in mailpit
I could release emails that are:

with just text content
HTML content with attachments

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]

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.com to test whether that returns an error too?

[Srinath-The-Geek]

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]

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]

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]

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 successful Date: 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]

"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]

"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.

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).

"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.

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 have From: 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

From: "AutoInvoiceFailure@Man.com" <Man_Financials_WF_Infra@coxautoinc.com>

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]

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]

This issue has been marked as stale because it has been open for 7 days with no activity.

[github-actions]

This issue was closed because there has been no activity since being marked as stale.