Question

We have a batch program that incorporates JavaMail 1.2 that sends emails. In our development environment, we haven’t got the chance to encounter the above mentioned exception. But in the client’s environment, they had experienced this a lot of times with the following error trace:

javax.mail.MessagingException: 550 Requested action not taken: NUL characters are not allowed.   at com.sun.mail.smtp.SMTPTransport.issueCommand (SMTPTransport.java: 879)   at com.sun.mail.smtp.SMTPTransport.finishData (SMTPTransport.java: 820)   at com.sun.mail.smtp.SMTPTransport.sendMessage (SMTPTransport.java: 322)   ... 

I’m not sure if this is connected to my problem, https://bugs.java.com/bugdatabase/view_bug?bug_id=4697158. But trying JavaMail 1.4.2, I see that the content transfer encoding of the email is still 7bit, so I’m not sure if using JavaMail 1.4.2 could solve the problem. Please take note that I could only do testing in our development environment that hasn’t been able to replicate this.

With the above exception, how would i know if this is from the sender or the receiver side? What debugging steps could you suggest?

EDIT: Here is a DEBUG of the actual sending (masked some information):

DEBUG: not loading system providers in &lt;java.home&gt;</a>/lib  DEBUG: not loading optional custom providers file: /META-INF/javamail.providers  DEBUG: successfully loaded default providers    DEBUG: Tables of loaded providers  DEBUG: Providers Listed By Class Name: {com.sun.mail.smtp.SMTPTransport=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc], com.sun.mail.imap.IMAPStore=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun Microsystems, Inc], com.sun.mail.pop3.POP3Store=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Sun Microsystems, Inc]}  DEBUG: Providers Listed By Protocol: {imap=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun Microsystems, Inc], pop3=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Sun Microsystems, Inc], smtp=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]}  DEBUG: not loading optional address map file: /META-INF/javamail.address.map    DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]  DEBUG SMTP: useEhlo true, useAuth false    DEBUG: SMTPTransport trying to connect to host "nnn.nnn.n.nnn", port nn    DEBUG SMTP RCVD: 220 xxxx.xxxxxxxxxxx.xxx SMTP; Mon, 23 Mar 2009 15:18:57 +0800    DEBUG: SMTPTransport connected to host "nnn.nnn.n.nnn", port: nn    DEBUG SMTP SENT: EHLO xxxxxxxxx  DEBUG SMTP RCVD: 250 xxxx.xxxxxxxxxxx.xxx Hello    DEBUG SMTP: use8bit false  DEBUG SMTP SENT: MAIL FROM:<a href="newmsg.cgi?mbx=Main&to=[e-mail]">&lt;[e-mail]&gt;</a>  DEBUG SMTP RCVD: 250 <a href="newmsg.cgi?mbx=Main&to=[e-mail]">&lt;[e-mail]&gt;</a>... Sender ok    DEBUG SMTP SENT: RCPT TO:&lt;[e-mail]&gt;  DEBUG SMTP RCVD: 250 &lt;[e-mail]&gt;... Recipient ok    Verified Addresses  &nbsp;&nbsp;[e-mail]  DEBUG SMTP SENT: DATA  DEBUG SMTP RCVD: 354 Enter mail, end with "." on a line by itself    DEBUG SMTP SENT:   .  DEBUG SMTP RCVD: 550 Requested action not taken: NUL characters are not allowed. 

Answer 1

You can try to enable debugging messages, if this is not a security risk:

session.setDebug(true); 

Then, I would also be interested to know the following: the content of the mail and the recipient. If you log these, you can try to reproduce the behavior from your machine. It could just be that some email servers reject mails with NUL characters.

Edit: Based on the debug information I believe that most probably the remote mail server rejects the mail with NUL characters. In order to verify this, try to send the exact same mail to the same recipient with some other means. Also, try to send a test email to the same recipient that doesn’t contain NUL characters.