У меня проблема с системой NAGIOS, которая отправляет электронные письма в популярный сервис электронной почты. Служба электронной почты в 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 находится на связи, и между мной и (превосходными) сотрудниками службы поддержки электронной почты и SMS мы установили, что это является причиной проблемы.
Итак, мой вопрос: законно ли для MTA вставлять в провод даровой CRLF?
Если это так, и я могу это доказать, то это проблема дома с электронной почтой, потому что они нетерпимы. Если это не так, или это так, но я не могу это доказать, тогда это становится моей проблемой, поэтому ответ со ссылками был бы наиболее полезным.
Изменить : теперь я могу прийти к выводу, что услуга электронной почты для SMS является Kapow . Как только им объяснили эту проблему, они получили ее, вместе со мной разработали и протестировали исправление и развернули исправление. Мои длинные сюжетные линии с двоеточиями теперь правильно передаются в СМС. Обычно я не рекламирую отдельные компании, особенно на SF, но я подумал, что стоит отметить, что kapow сделал правильную вещь. (Отказ от ответственности: я не имею никакого отношения к kapow, кроме как как платящий клиент, который доволен тем, как они справились с его проблемой.)