Saya mengalami masalah dengan sistem NAGIOS mengirim email ke layanan email-ke-SMS yang populer. Layanan email-ke-SMS mengambil email dengan teks di Subject:
baris, dan mengirimkannya ke nomor ponsel yang disandikan di To:
lapangan. Sejauh ini baik. Sayangnya, sendmail (dan postfix sebelum) tampaknya akan memasukkan CRLF serampangan ke dalam (tentu panjang) Subject:
line, dan yang menyebabkan pesan SMS saya terpotong di CRLF yang jika dan hanya jika para Subject:
baris berisi satu atau lebih titik dua masa lalu yang serampangan CRLF.
Saya yakin bahwa pesan tersebut dibuat dengan benar, tetapi untuk memastikan, inilah saya membuat pesan pengujian sepenuhnya mengangguk untuk diri saya sendiri, dengan Subject:
garis panjang :
echo "foo" | mail -s "1234567 101234567 201234567 301234567 401234567 501234567 601234567 701234567 801234567 90123456789" reaper@teaparty.net
Perhatikan tidak ada titik dua tambahan di Subject:
baris ini ; semua yang saya lakukan di sini menunjukkan bahwa CRLF tambahan dimasukkan pada kabel. Inilah hasil dari 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
Sekitar setengah jalan ke bawah (ditandai dengan huruf tebal + miring), antara 501234567
dan 601234567
di Subject:
header asli , Anda dapat melihat CRLF sedang dimasukkan ( 0x0d 0x0a
, di sisi kiri hex dump, ..
di sisi kanan teks biasa).
MTA penerima tampaknya senang memprosesnya, dan ketika saya melihat mail yang tersimpan di disk di ujung penerima, saya hanya melihat LF (0x0a) di baris Subjek:, dan saluran diuraikan dengan benar dan di dalamnya keseluruhan oleh, misalnya alpine
,. Namun demikian, CRLF ada di sana, dan antara saya dan orang-orang dukungan email-ke-SMS (luar biasa), kami telah menetapkan bahwa ini adalah penyebab masalah.
Jadi pertanyaan saya adalah: apakah sah bagi MTA untuk memasukkan CRLF gratis pada kabel?
Jika ya, dan saya bisa membuktikannya, maka itu masalah rumah email-ke-SMS, karena mereka tidak toleran. Jika tidak, atau itu tapi saya tidak bisa membuktikannya, maka itu menjadi masalah saya, jadi jawaban dengan referensi akan sangat berguna.
Sunting : Saya sekarang dapat mengetahui bahwa layanan email-ke-SMS yang dimaksud adalah kapow . Setelah masalah ini dijelaskan kepada mereka, mereka mendapatkannya, bekerja dengan saya untuk mengembangkan dan menguji perbaikan, dan telah menyebarkan perbaikan. Baris subjek panjang saya dengan titik dua sekarang bisa diteruskan dengan benar ke SMS. Saya biasanya tidak terompet perusahaan individu, terutama tidak pada SF, tetapi saya pikir patut dicatat bahwa kapow Melakukan Hal yang Benar. (Penafian: Saya tidak memiliki koneksi dengan kapow kecuali sebagai pelanggan yang membayar yang senang dengan cara mereka menangani masalahnya.)