When Grok Bot sends email through the Gmail connector, a strict recipient sees raw MIME text instead of the message. The recipient sees: “–null / Content-Type: text/plain; charset=UTF-8 / Hello / --null / Content-Type: text/html; charset=UTF-8 / Content-Transfer-Encoding: quoted-printable /
Hello
/ --null–”. In Gmail’s own Sent folder the message looks fine (one plain-text body, no HTML part), so the problem only shows with a recipient that parses MIME more strictly than Gmail (in my case an email relay for a classifieds site). Sending HTML-only instead arrives as a blank message. Both the new-message and the reply functions do this. It looks like a two-part message is built with a broken boundary named “null”.
Steps to Reproduce
Connect a Gmail account to Grok Bot.
Ask Grok Bot to send a one-line plain-text email (new message or reply) to a recipient that parses MIME strictly, for example a classifieds-site email relay address.
Open the message as the recipient sees it. The raw boundary and Content-Type lines appear in the body.
Check Gmail’s Sent folder: it looks normal there.
Expected Behavior
A single plain-text message, or a correctly formed multipart/alternative with a valid boundary and closing boundary. A plain-text-only send option would also solve it for my use. This blocks automated replies to buyers, so a fix or workaround would be very welcome.
Hey, thanks for the detailed report and for the exact text you’re seeing.
One thing stands out right away. In your Sent copy, there’s only a plain-text body, but the recipient sees a two-part message with an HTML version that wasn’t in the sent email. This suggests the message might be getting repackaged on the way to the recipient. To figure out where that happens, please do a couple quick checks:
In Gmail on the web, open the Sent folder and open one of the emails that Grok Bot sent to the relay address.
Click the three-dot menu in the top-right of the email, then choose Show original.
Look at the Content-Type: line at the top, then press Ctrl+F and search the page for null.
Now in Gmail web directly, not via Grok Bot, compose a new email with a single line, Hello, and send it to the same relay address.
Check if the recipient also sees --null or raw Content-Type lines in this manual email.
Please send:
The Content-Type line from step 3
Whether you found null anywhere
The result of step 5
You can redact email addresses.
If the manual Gmail web email arrives fine, but the Grok Bot email is broken, that narrows it down to our side, and we’ll pass it to the team. Let me know how it goes.
Thanks, I tested it. The manual Gmail email arrives fine and the Grok Bot email is broken, so it is on the Grok Bot side.
Grok Bot email (Show original in Gmail, Sent copy): Content-Type is text/plain; charset=“UTF-8”. The word “null” does not appear anywhere. There is no boundary and no multipart. The body is one clean line. In-Reply-To and References hold the Gmail thread ID (not a real Message-ID). It was sent via gmailapi.google.com (HTTPREST).
Manual Gmail email (same thread, same relay address, typed by hand): Content-Type is multipart/alternative with a normal random boundary, plain and html parts, and the real Message-ID in References.
What the receiver shows: the manual one arrives clean (“Test, please ignore.”). The Grok Bot one, sent again just now as a plain-text-only reply, arrives as: --null Content-Type: text/plain; charset=UTF-8 Test, please ignore. --null Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Test, please ignore.
--null–
So Gmail’s saved copy looks clean, but what the receiver gets has a “null” boundary. It looks like the extra parts are added when the message is built or sent, after what Gmail stores. Still on Grok Bot 0.66.0. Sending is off on my side until this is fixed.
Hey, thanks for running the test, it really clarified things.
If we put together what Show original shows:
Your Sent copy is a clean single-part email (text/plain, no boundary, not multipart, no “null” anywhere), sent via gmailapi.google.com.
A manual email from Gmail web is multipart/alternative with a normal random boundary, and it arrives clean.
But the Grok Bot version arrives re-packed into a two-part multipart with a literal null boundary and an HTML part that wasn’t in the sent email.
So the --null shows up later in the chain. The recipient’s relay (the classifieds site’s email relay) is re-packing your single-part text/plain email and is inserting the boundary incorrectly. The manual email doesn’t break because Gmail web sends a ready-made multipart/alternative, and the relay passes it through as-is.
Practical takeaway on our side: if Grok Bot sent a proper multipart/alternative with a valid boundary (like Gmail web does), the relay wouldn’t need to re-pack anything and the issue wouldn’t happen. I shared this with the team as a direction for improving the send path. I can’t give a timeline, but I’ll reply in the thread if there’s an update.
Honestly about a workaround: while the send path outputs single-part text/plain, this specific strict relay will likely keep re-packing it, so there’s no clean workaround on your side right now. If you can test anything else on the same relay, send it here and I’ll pass it to the team.