por - java mail java
Estoy perdiendo periodos en un correo electrónico enviado con Java Mail (8)
¿Estás configurando el tipo de Mime en "text / html"? Deberías tener algo como esto:
BodyPart bp = new MimeBodyPart();
bp.setContent(message,"text/html");
Estoy enviando boletines desde un servidor Java y uno de los hipervínculos está faltando un punto, por lo que es inútil:
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.
En el ejemplo anterior, el período se perdió entre edu y au en el primer hipervínculo.
Hemos determinado que el cuerpo del correo está siendo alineado y el ajuste divide la línea en el período, y que es ilegal comenzar una línea con un punto en un correo electrónico SMTP:
http://tools.ietf.org/html/rfc2821#section-4.5.2
Mi pregunta es: ¿qué configuraciones debo usar para asegurarme de que el envoltorio sea amigable para el período y / o no se realice en primer lugar?
ACTUALIZACIÓN: después de muchas pruebas y depuración resultó que nuestro código era correcto: el servidor Linux del cliente se había enviado con una versión Java muy antigua y las antiguas clases de Mail todavía estaban en una de las carpetas de lib y se seleccionaban con preferencia a la nuestra. JDK anterior a 1.2 tiene este error.
Asegúrate de que todo tu contenido sea compatible con RFC2045 en virtud de la opción "imprimible entre comillas". Usa la clase MimeUtility en un método como este.
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( );
}
Desde una perspectiva de SMTP, puede comenzar una línea con un punto pero en su lugar debe enviar dos períodos. Si el cliente SMTP que está utilizando no hace esto, puede encontrar el problema que describe.
Podría valer la pena probar un sniffer IP para ver dónde está realmente el problema. Es probable que haya al menos dos transacciones SMTP separadas involucradas en el envío de ese correo electrónico.
No estoy seguro, pero parece un poco como si tu correo electrónico estuviera siendo codificado. 0x3D es el carácter hexadecimal 61, que es el carácter igual (''='').
¿Qué clases / biblioteca está usando para enviar los correos electrónicos? Verifique la configuración relacionada con la codificación.
Como señaló Greg, el problema es con su cliente SMTP, que no tiene relleno de puntos (doblando el punto inicial).
Parece que el correo electrónico está codificado en imprimible entre comillas. Cambiar a base64 (supongo que puedes hacerlo con la implementación actual de jaime mime) solucionará el problema.
Tengo un problema similar, pero estoy usando ASP.NET 2.0. Según los registros de la aplicación, el enlace en el correo electrónico es correcto '' http://www.3rdmilclassrooms.com/ '', sin embargo, luego el cliente recibe el correo electrónico que falta en el enlace un período '' http://www3rdmilclassrooms.com ''
He hecho todo lo posible para demostrar que el correo electrónico se envía con el enlace correcto. Mi sospecha es que es el cliente de correo electrónico o el software de filtro de correo no deseado el que está modificando el hipervínculo. ¿Es posible que un software de filtrado de correo no deseado haga eso?
Tuve un problema similar al enviar el correo electrónico mediante programación a una cuenta de Yahoo. Tendrían una línea de texto muy larga y agregarían sus propios saltos de línea en el correo HTML, pensando que eso no causaría un problema, pero por supuesto que sí.
el truco no era intentar enviar una línea tan larga. Debido a que los correos electrónicos HTML no se preocupan por los saltos de línea, debe agregar los suyos propios cada pocos bloques, o justo antes de la línea ofensiva, para asegurarse de que su URL no se divida en un período como ese.
Tuve que cambiar mi ASP VB de
var html;
html = "Blah Blah Blah Blah ";
html = html & " More Text Here....";
a
var html;
html = "Blah Blah Blah Blah " & VbCrLf;
html = html & " More Text Here....";
Y eso es todo lo que se necesitó para limpiar la salida que se estaba procesando en su extremo.
Tuve un problema similar en los correos electrónicos HTML: misteriosos períodos faltantes y, en un caso, un mensaje extrañamente truncado. JavaMail envía correo electrónico HTML utilizando la codificación imprimible entre comillas que envuelve las líneas en cualquier punto (es decir, no solo en espacios en blanco) para que ninguna línea exceda los 76 caracteres. (Utiliza un ''='' al final de la línea como un retorno de carro suave, por lo que el receptor puede volver a ensamblar las líneas.) Esto puede resultar fácilmente en una línea que comience con un punto, que se debe duplicar. (Esto se denomina ''relleno de puntos''). De lo contrario, el servidor SMTP receptor consumirá el período o, peor aún, si el período es el único carácter en una línea, será interpretado por el servidor SMTP como el final del mensaje.
Lo rastreé hasta la implementación de GNU JavaMail 1.1.2 (también conocido como classpathx javamail). No hay una versión más nueva de esta implementación y no se ha actualizado durante 4 o 5 años. Al observar la fuente, implementa parcialmente el relleno de puntos: trata de manejar el período en línea por sí mismo, pero hay un error que impide que ese caso funcione.
Desafortunadamente, esta fue la implementación predeterminada en nuestra plataforma (Centos 5), así que imagino que también es la predeterminada en RedHat.
La solución para Centos es instalar la implementación JavaMail de Sun (¿o debería decir ahora Oracle?) (Utilicé la versión 1.4.4) y usar el comando Alternativas de Centos para instalarlo en lugar de la implementación predeterminada. (El uso de alternativas asegura que la instalación de parches Centos no provocará una reversión a la implementación de GNU).