У мене виникають проблеми із системою NAGIOS, що надсилає електронні листи популярній службі електронної пошти до SMS. Послуга електронної пошти до SMS приймає електронні листи з текстом у Subject:рядку та надсилає їх на номер мобільного телефону, закодований у To:полі. Все йде нормально. До жаль, Sendmail (і постфікса перед ним) , здається, вставивши безоплатне CRLF в (обов'язково довгою) Subject:лінії, і це викликає мої SMS повідомлення будуть усічені в CRLF тоді і тільки тоді , колиSubject: рядок містить один або кілька колонів повз безоплатна CRLF
Я впевнений, що повідомлення створюються правильно, але просто для переконання, ось я створюю абсолютно кивчене тестове повідомлення для себе з довгим Subject:рядком:
echo "foo" | mail -s "1234567 101234567 201234567 301234567 401234567 501234567 601234567 701234567 801234567 90123456789" reaper@teaparty.net
Зверніть увагу, що в цьому Subject:рядку немає додаткової двокрапки ; все, що я тут роблю, - це показувати, що на дроті вставлено додатковий CRLF. Ось результат 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
Близько половини шляху вниз (виділені жирним шрифтом + курсивом), між 501234567і 601234567в оригінальному Subject:заголовку, ви можете побачити CRLF вставляється ( 0x0d 0x0aна лівій стороні шістнадцятковий дамп, ..на правій стороні звичайного тексту).
MTA, що приймає, здається радію після обробки, і коли я дивлюся на збережену на диску диска на кінці отримання, я бачу лише рядок LF (0x0a) у рядку Subject:, а рядок аналізується правильно та в його цілісність, наприклад, шляхом alpine. Тим не менш, CRLF є на місці, і між мною та (відмінними) людьми, які підтримують електронну пошту, ми встановили, що це є причиною проблеми.
Отже, моє запитання: чи законно МТА вставляти на провід безплатний CRLF?
Якщо це так, і я можу це довести, то це проблема будинку електронної пошти до SMS, оскільки вони нетерпимі. Якщо це не так, або є, але я не можу цього довести, то це стає моєю проблемою, тому відповідь із посиланнями була б найбільш корисною.
Редагувати : Тепер я можу зрозуміти, що розглядаються послуги електронної пошти на SMS - kapow . Після того, як ця проблема була їм роз'яснена, вони отримали її, працювали зі мною над розробкою та тестуванням виправлення, і розгорнули виправлення. Мої довгі сюжетні рядки з двокрапками зараз правильно передаються в SMS. Я, як правило, не трублю окремі компанії, особливо це стосується SF, але я вважав, що варто зазначити, що kapow зробив правильну річ. (Відмова: Я не маю жодного зв’язку з kapow, окрім як платного клієнта, який радий тому, як вони вирішили його проблему.)