I think I have an idea on the "." problem... After unsuccessful attempts to put debug code everywhere to figure our what was happening, what I was able to do was change the SMTPTerminator value to be a String in the last line of a test email, rather than the "\r\n.\r\n" sequence. When I did this, the email would get through no additional "."s!!! What I suspect is happening is very close to what Anthony described (this is a little scary...bare with me). The MimeMessage gets parsed based on data sent through CharTerminatedInputStream. It continues to parse until you get an EOF, which because of the way the CharTerminatedInputStream works, the MimeMessage actually includes the "\r\n.\r\n" end sequence in the message body. So after parsing this way from the SMTP stream, instead of the body of my email looking like: Hello world! ....it looks like... Hello world! .. Then POP3 server implementation shows a single extra dot when retrieving the message. But now when we are trying remote delivery... well, for SMTP delivery, you can't put leave a "." on a blank line in an email message (because the remote server would consider that the email message terminator), so you are supposed to put ".." in it's place. So what the remote server is sent is... Hello world! ... Now, I'm a bit fuzzy on why/when the mail server should parse a ".." back to single "."... I'd have to review the RFCs and read through how the JavaMail API works. But assuming this is right, I think this accurately (and painfully) describes what is happening. What to do? Make CharTerminatedInputStream not pass the terminator chars... rather than passing \r\n.\r\nEOF, build a small buffer as you read, read ahead if you start matching the terminator, and pass EOF immediately if you find the terminator. Also, it would be nice to finish CharTerminatedInputStream so that it can handle both read() and read(byte[]) for performance reasons. A few weeks ago I wrote a multipart form parser which does something similar to this (you have to scan for the boundary strings and leave the appropriate data in place). I think a replacement for CharTerminatedInputStream that didn't include the terminator string would fix this and give more predictable behavior (I would generally think that a CharTerminatorInputStream would not include the terminator because that's part of the transport, not the input stream I wanted to see). If you wanted this class to still support including the terminator string, you could also have an optional constructor with a boolean parameter. Any preferences? I've also made some changes to the API to support the getRemoteHost and getRemoteAddr (numeric) on Mail (and getting that from SMTPHandler into the Mail object), and I'm not completely happy with what I've had to change to MailServer, but perhaps I can commit once I'm done sorting out these issues and get feedback then. Serge Knystautas Loki Technologies http://www.lokitech.com/ . QUIT ------------------------------------------------------------ To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: <http://java.apache.org/> Problems?: [EMAIL PROTECTED]
