Me encuentro con un problema con un sistema NAGIOS que envía correos electrónicos a un servicio popular de correo electrónico a SMS. El servicio de correo electrónico a SMS toma correos electrónicos con texto en la Subject:línea y los envía al número móvil codificado en el To:campo. Hasta aquí todo bien. Lamentablemente, sendmail (y postfix antes) parecen estar insertando un CRLF gratuito en la línea (necesariamente larga) Subject:, y eso hace que mis mensajes SMS se trunqueen en el CRLF si y solo si la Subject:línea contiene uno o más dos puntos más allá del gratuito CRLF.
Estoy seguro de que los mensajes se están creando correctamente, pero solo para estar seguro, aquí estoy creando un mensaje de prueba completamente tonto para mí, con una larga Subject:línea:
echo "foo" | mail -s "1234567 101234567 201234567 301234567 401234567 501234567 601234567 701234567 801234567 90123456789" reaper@teaparty.net
Tenga en cuenta que no hay dos puntos adicionales en esta Subject:línea; Todo lo que estoy haciendo aquí es mostrar que se inserta un CRLF adicional en el cable. Aquí está el resultado de sudo ngrep -x port 25:
44 61 74 65 3a 20 46 72 69 2c 20 33 31 20 4d 61 Date: Fri, 31 Ma
79 20 32 30 31 33 20 31 30 3a 34 33 3a 35 35 20 y 2013 10:43:55
2b 30 31 30 30 0d 0a 54 6f 3a 20 72 65 61 70 65 +0100..To: reape
72 40 74 65 61 70 61 72 74 79 2e 6e 65 74 0d 0a r@teaparty.net..
53 75 62 6a 65 63 74 3a 20 31 32 33 34 35 36 37 Subject: 1234567
20 31 30 31 32 33 34 35 36 37 20 32 30 31 32 33 101234567 20123
34 35 36 37 20 33 30 31 32 33 34 35 36 37 20 34 4567 301234567 4
30 31 32 33 34 35 36 37 20 35 30 31 32 33 34 35 01234567 5012345
36 37 0d 0a 20 36 30 31 32 33 34 35 36 37 20 37 67.. 601234567 7
30 31 32 33 34 35 36 37 20 38 30 31 32 33 34 35 01234567 8012345
36 37 20 39 30 31 32 33 34 35 36 37 38 39 0d 0a 67 90123456789..
55 73 65 72 2d 41 67 65 6e 74 3a 20 48 65 69 72 User-Agent: Heir
6c 6f 6f 6d 20 6d 61 69 6c 78 20 31 32 2e 34 20 loom mailx 12.4
37 2f 32 39 2f 30 38 0d 0a 4d 49 4d 45 2d 56 65 7/29/08..MIME-Ve
72 73 69 6f 6e 3a 20 31 2e 30 0d 0a 43 6f 6e 74 rsion: 1.0..Cont
65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 ent-Type: text/p
6c 61 69 6e 3b 20 63 68 61 72 73 65 74 3d 75 73 lain; charset=us
A mitad de camino hacia abajo (marcado en negrita + cursiva), entre el 501234567y el 601234567en el Subject:encabezado original , puede ver que se inserta un CRLF ( 0x0d 0x0a, en el volcado hexadecimal del lado izquierdo, ..en el texto plano del lado derecho).
El MTA receptor parece feliz de procesar esto, y cuando miro el correo almacenado en el disco en el extremo receptor, solo veo un LF (0x0a) en la línea Asunto: y la línea se analiza correctamente y en su totalidad por, por ejemplo, alpine. Sin embargo, el CRLF está allí en el cable, y entre mí y la (excelente) gente de soporte de correo electrónico a SMS, hemos establecido que estos son la causa del problema.
Entonces mi pregunta es: ¿ es legal que un MTA inserte un CRLF gratuito en el cable?
Si es así, y puedo probarlo, entonces es el problema de la casa de correo electrónico a SMS, porque son intolerantes. Si no lo es, o lo es, pero no puedo probarlo, entonces se convierte en mi problema, por lo que una respuesta con referencias sería muy útil.
Editar : ahora puedo aclarar que el servicio de correo electrónico a SMS en cuestión es kapow . Una vez que se les explicó este problema, lo entendieron, trabajaron conmigo para desarrollar y probar una solución, y han implementado la solución. Mis largas líneas de asunto con dos puntos ahora se transmiten correctamente a los SMS. Normalmente no hago alarde de las compañías individuales, especialmente no en SF, pero pensé que es digno de mención que kapow hizo lo correcto. (Descargo de responsabilidad: no tengo ninguna conexión con kapow, excepto como un cliente que paga y está contento con la forma en que trataron su problema).