I'm wasting time in an email sent using Java Mail

Question

I am sending newsletters from a Java server, and one of the hyperlinks is missing a period, which makes it useless:

Please print your <a href=3D"http://xxxxxxx.xxx.xx.edu= au//newsletter2/3/InnovExpoInviteVIP.pdf"> VIP invitation</a> for future re= ference and check the Innovation Expo website <a href=3D"http://xxxxxxx.xx= xx.xx.edu.au/2008/"> xxxxxxx.xxxx.xx.edu.au</a> for updates. 

In the above example, the period was lost between edu and au at the first hyperlink.

We determined that the mail body is wrapped with a line, and the packaging breaks the line into a period and that it is illegal to run a line with a period in SMTP email:

http://tools.ietf.org/html/rfc2821#section-4.5.2

My question is: what settings should be used to ensure that packaging is convenient and / or not performed first?

UPDATE: after a lot of testing and debugging, it turned out that our code was in order: the Linux client server was sent with a very old version of Java, and the old Mail classes were still in one of the lib folders and turned out to be different from ours. JDK before 1.2 has this error.

Answer 1

From an SMTP perspective, you can run a line with a period, but instead you need to send two periods. If the SMTP client you are using does not do this, you may run into the problem you are describing.

It might be worth trying an IP sniffer to see where the problem really is. There are probably at least two separate SMTP transactions associated with sending this message.

Answer 2

I had a similar problem in HTML emails: mysterious missing periods, and in one case a weird truncated message. JavaMail sends an HTML email address using an encoded quote that wraps strings anywhere (that is, not just spaces), so that no strings contain 76 characters. (It uses the '=' at the end of the line as a soft carriage return, so the receiver can collect lines.) This can easily lead to the beginning of a line that should be doubled. (This is called “spot padding”). If not, the period will be eaten by the receiving SMTP server or, even worse, if the period is the only character in the string, it will be interpreted by the SMTP server as the end of the message.

I tracked it to GNU JavaMail 1.1.2 implementation (aka classpa thanks javamail). There is no new version of this implementation, and it has not been updated for 4 or 5 years. Looking at the source, it partially implements dot-stamping - it tries to process the period in the line by itself, but there is an error that prevents even this business from working.

Unfortunately, this was the default implementation on our platform (Centos 5), so I believe this is also the default value for RedHat.

The fix on Centos is to install Sun (or should I say Oracle now?) The JavaMail implementation (I used 1.4.4) and use the Centos alternatives command to install it instead of the default implementation. (Using alternatives ensures that installing Centos patches does not lead to a return to GNU implementation.)

Answer 3

Make sure all your content is RFC2045 compatible with quotation marks. Use the MimeUtility class in a method like this.

 private String mimeEncode (String input) { ByteArrayOutputStream bOut = new ByteArrayOutputStream(); OutputStream out; try { out = MimeUtility.encode( bOut, "quoted-printable" ); out.write( input.getBytes( ) ); out.flush( ); out.close( ); bOut.close( ); } catch (MessagingException e) { log.error( "Encoding error occured:",e ); return input; } catch (IOException e) { log.error( "Encoding error occured:",e ); return input; } return bOut.toString( ); }
private String mimeEncode (String input) { ByteArrayOutputStream bOut = new ByteArrayOutputStream(); OutputStream out; try { out = MimeUtility.encode( bOut, "quoted-printable" ); out.write( input.getBytes( ) ); out.flush( ); out.close( ); bOut.close( ); } catch (MessagingException e) { log.error( "Encoding error occured:",e ); return input; } catch (IOException e) { log.error( "Encoding error occured:",e ); return input; } return bOut.toString( ); } 

Answer 4

I have a similar problem, but using ASP.NET 2.0. In application logs, the link in the letter is correct " http://www.3rdmilclassrooms.com/ ', but then the client receives the letter, the link is missing period' http://www3rdmilclassrooms.com '

I did everything I could to prove that the letter was sent with the correct link. My suspicion is that it is software for an email client or spam filter that modifies a hyperlink. Is it possible that email spam filtering software will do this?

Answer 5

I'm not sure, but it is a bit like your email is getting encoding. 0x3D is the hexadecimal character 61, which is the equal sign ('=').

What classes / libraries do you use to send emails? Check encoding settings.

Answer 6

Is the Mime type set to "text / html"? You should have something like this:

 BodyPart bp = new MimeBodyPart(); bp.setContent(message,"text/html"); 

Answer 7

I had a similar problem emailing software to a yahoo account. They will receive one very long line of text and add their own lines to the HTML letter, thinking that this will not cause a problem, but of course it will.

the trick was not to try to send such a long line. Since HTML emails do not care about linear errors, you must add your own every few blocks or just before the offending line to ensure that your URL will not be divided for such a period.

I had to change ASP VB from

 var html; html = "Blah Blah Blah Blah "; html = html & " More Text Here...."; 

to

 var html; html = "Blah Blah Blah Blah " & VbCrLf; html = html & " More Text Here...."; 

And that’s all it takes to clear the output the way it was processed from the end.

Answer 8

As Greg noted, the problem is with your SMTP client, which doesn’t perform dot-mapping (doubling the leading point).

It looks like the email is encoded in quotation marks. Switching to base64 (I assume you can do this with the current java mime implementation) will fix the problem.