views:

361

answers:

1

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, http://bugs.sun.com/bugdatabase/view_bug.do?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&[email protected]">&lt;[email protected]&gt;</a>

DEBUG SMTP RCVD: 250 <a href="newmsg.cgi?mbx=Main&[email protected]">&lt;[email protected]&gt;</a>... Sender ok



DEBUG SMTP SENT: RCPT TO:&lt;[email protected]&gt;

DEBUG SMTP RCVD: 250 &lt;[email protected]&gt;... Recipient ok



Verified Addresses

&nbsp;&nbsp;[email protected]

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.
+1  A: 

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.

kgiannakakis
i have done what you have suggested and updated my post with the DEBUG log
rizza