We are using the Spring org.springframework.mail.javamail.JavaMailSenderImpl class to send vanilla email messages from a Java webapp to the sendgrid SMTP server at smtp.sendgrid.net. We don't add any sendgrid headers to these emails.
A significant number of the messages get bounced with the following message:
Subject: Invalid SMTPAPI Header
SendGrid Support <[email protected]>
Fri 11/6/2020 11:27 AM
A message was received from this address by our systems that had errors in the SMTPAPI header, and cannot be processed due to the following:
- error parsing xsmtpapi header
If you require assistance in working with the SendGrid API, please contact us at [email protected]
Although we don't add sendgrid headers, if I look at the contents of the bounced message I see these headers:
X-SMTPAPI-V3: {"from":{"name":"Error Messages Mailbox","email":"[email protected]"},"display_to":"Exception Mailbox [email protected]","display_from":"Error Messages Mailbox [email protected]","subject":"[Staging:public] Expression has thrown an unchecked exception; see the cause exception.","personalizations":[{"to":[{"email":"[email protected]"}]}],"reply_to":{"name":"Error Messages Mailbox","email":"[email protected]"}}
X-SMTPAPI-V3-CONVERSION: 1
Fortunately the JavaMailSenderImpl class has a debug property you can set as
mailSender.getJavaMailProperties().put("mail.debug", debug);
If I enable that, I can see a dump of my application's communication with the SendGrid SMTP server, and I can see that I am not adding any X-SMTPAPI headers. The log looks like this:
DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: trying to connect to host "smtp.sendgrid.net", port 25, isSSL false
220 SG ESMTP service ready at ismtpd0009p1iad2.sendgrid.net
DEBUG SMTP: connected to host "smtp.sendgrid.net", port: 25
EHLO my_machine
250-smtp.sendgrid.net
250-8BITMIME
250-PIPELINING
250-SIZE 31457280
250-STARTTLS
250-AUTH PLAIN LOGIN
250 AUTH=PLAIN LOGIN
DEBUG SMTP: Found extension "8BITMIME", arg ""
DEBUG SMTP: Found extension "PIPELINING", arg ""
DEBUG SMTP: Found extension "SIZE", arg "31457280"
DEBUG SMTP: Found extension "STARTTLS", arg ""
DEBUG SMTP: Found extension "AUTH", arg "PLAIN LOGIN"
DEBUG SMTP: Found extension "AUTH=PLAIN", arg "LOGIN"
STARTTLS
220 Begin TLS negotiation now
EHLO my_machine
250-smtp.sendgrid.net
250-8BITMIME
250-PIPELINING
250-SIZE 31457280
250-STARTTLS
250-AUTH PLAIN LOGIN
250 AUTH=PLAIN LOGIN
DEBUG SMTP: Found extension "8BITMIME", arg ""
DEBUG SMTP: Found extension "PIPELINING", arg ""
DEBUG SMTP: Found extension "SIZE", arg "31457280"
DEBUG SMTP: Found extension "STARTTLS", arg ""
DEBUG SMTP: Found extension "AUTH", arg "PLAIN LOGIN"
DEBUG SMTP: Found extension "AUTH=PLAIN", arg "LOGIN"
DEBUG SMTP: Attempt to authenticate
AUTH LOGIN
334 XXXXXXX
XXXXXXXX
334 XXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
235 Authentication successful
DEBUG SMTP: use8bit false
MAIL FROM:<[email protected]>
250 Sender address accepted
RCPT TO:<[email protected]>
250 Recipient address accepted
DEBUG SMTP: Verified Addresses
DEBUG SMTP: Exception Mailbox <[email protected]>
DATA
354 Continue
Date: Thu, 14 Jan 2021 17:13:02 -0600 (CST)
From: Development Team <[email protected]>
Reply-To: Development Team <[email protected]>
To: Exception Mailbox <[email protected]>
Message-ID: <296162971.11610665983070.JavaMail.current_user@my_machine>
Subject: ERROR!
==>...
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
A detailed description of an error!
.
250 Ok: queued as ba4KB2HnQMKcKJHM06yeIw
QUIT
221 See you later
Since we don't add these headers, I am assuming they are added by smtp.sendgrid.net, which then bounces the messages on the basis of these same headers(?)
I filed a support ticket with sendgrid 2 months ago and have been met with a wall of non-answers. (Additionally, if you are here with this same question, don't bother with the [email protected] email; it replies with an email yelling to go get help on their support website. I also brought this to their attention 2 months ago.)
Does anyone have any insight as to what in our original vanilla mail might have triggered the generation of the bad SMTPAPI header and what's invalid about it? The documentation is not great, particularly for us who are not using the SMTPAPI directly. Are there any validation tools for these API calls?
