none
Длина Темы в 255? RRS feed

  • Вопрос

  •  

    После перехода на Exchange стало заметно что тема писем обрубается на 255 симовлов.

    т.е.

    Пример (все символы в одну строку):

    Code Snippet

    =?utf-8?B?UDcgV29yayBJdGVtIENoYW5nZWQ6IERlZmVjdCAyNjI3MCAtINCSINCy0LXQsdC1INC/0YDQuCDQvtGC0LrRgNGL0YLQuNC4INC00LXRgNC10LLQsCDQuNC30LzQtdGA0LXQvdC40Lkg0L/QvtGP0LLQu9GP0LXRgtGB0Y8g0L3QsNC00L/QuNGB0YwgItCX0LDQs9GA0YPQt9C60LAuLi4iINC40LvQuCAiRGF0YSBsb2FkaW...

     

     

    Ошибка исправится, если в конце темы добавить символы =?=

    Как будет выглядеть после этого:

    Code Snippet

    P7 Work Item Changed: Defect 26270 - В вебе при открытии дерева измерений появляется надпись "Загрузка..." или "Data load

     

     

    тема отрезана ровно до 255(или 256) символов

    Похоже exchange режет все темы сообщений как ASCII вне зависимости от их кодировки и не заканчивает кодированные темы.

    я так понимаю длина в 255 это требование RFC, но как поправить данную ситуацию?

    (ответ типа создавать тему меньше по длине, некатит Sad )

    • Перемещено Hengzhe Li 11 марта 2012 г. 12:54 forum merge (От:Exchange Server 2007)
    29 октября 2008 г. 5:40

Ответы

  •  Всетаки додавили мы этот вопрос. Пришлось обратиться к платной тех. поддержке Microsoft.
    После долгих боданий проблему признали и описали возможный вариант решения.
    Протестировали - работает. Охотно делюсь им со всеми пользователями Exchange 2007.
    Привожу полный ответ и описание проблемы:

    Данное поведение Exchange 2007 не является ошибкой.

    Оно заложено изначально разработчиками продукта и соответствует стандарту RFC2047 (http://www.ietf.org/rfc/rfc2047.txt)

    Exchange 2003 был более лоялен к данному стандарту, поэтому в случае отсылки письма с mail.ru Тема письма не искажалась.

    Соответственно, сам сервер mail.ru также не следует всем рекомендациям, описанным в RFC2047.

     

    В качестве решения проблемы Вы можете использовать решение предложенное в разделе Workaround.

     

    Technical Analysis

    ==================

    First I tried to reproduce the problem. I was able to reproduce it without any problem.

    The issue is related to the Exchange version and not to the client.

    With Exchange 2003 there was no problem, but with Exchange 2007 the problem occurred.

     

    Example 1.

     

    Initial data:

    - Sender's mail client - free mail service MAIL.RU

    !!==>   Subject: contains 81 (!!!) character in Russian encoding.

               This was only the letters without any characters, spaces, digits, etc.

    - Recipient's mail client: OLK 2007 (12.0.6316.5000) SP1.

    - Mailbox server:  Exchange 2007 SP1

    !!==>   Field Subject shows CORRECTLY in Outlook 2007.

    Subject: =?koi8-r?Q?=C6=CC=C4=C4=D0=C1=CF=CC=C4=C1=D7=D0=DB=DD=C5=CB=D6=C4=CD=D9=D7=CF=D0=DA=DD=D5=CB=C4=D9=CC=D7=CF=D0=CC=C1=D0=CF=C4=CC=D7=C1=CF=C4=CC=D9=D7=CF=C1=DB=DD=D5=C1=CF=D7=D9=C4=C1=CC=CF=CB=D5=C3=C4=DB=C1=C4=CC=D0=D2=CC=C1=CF=D0=D5=C3=C4=CB=CF=DB=C9?=

     

    Conclusion:

    -------------------

    The main part is:

    =?koi8-r?Q?=C6=CC=C4=C4=D0=C1=CF=CC=C4=C1=D7=D0=DB=DD=C5=CB=D6=C4=CD=D9=D7=CF=D0=DA=DD=D5=CB=C4=D9=CC=D7=CF=D0=CC=C1=D0=CF=C4=CC=D7=C1=CF=C4=CC=D9=D7=CF=C1=DB=DD=D5=C1=CF=D7=D9=C4=C1=CC=CF=CB=D5=C3=C4=DB=C1=C4=CC=D0=D2=CC=C1=CF=D0=D5=C3=C4=CB=CF=DB=C9?=

    the subject part contains 254 character

     

    Example 2.

     

    Initial data:

    - Sender's mail client - free mail service MAIL.RU

    !!==>   Subject: contains 82 (!!!) character in Russian encoding.

               This was only the letters without any characters, spaces, digits, etc.

    - Recipient's mail client: OLK 2007 (12.0.6316.5000) SP1.

    - Mailbox server:  Exchange 2007 SP1.

    Subject: =?koi8-r?Q?=C1=C1=D7=D7=C1=C4=D0=C1=CF=CC=C4=C1=D7=D0=DB=DD=C5=CB=D6=C4=CD=D9=D7=CF=D0=DA=DD=D5=CB=C4=D9=CC=D7=CF=D0=CC=C1=D0=CF=C4=CC=D7=C1=CF=C4=CC=D9=D7=CF=C1=DB=DD=D5=C1=CF=D7=D9=C4=C1=CC=CF=CB=D5=C3=C4=DB=C1=C4=CC=D0=D2=CC=C1=CF=D0=D5=C3=C4=CB=CF=DB?=

    !!==>   Field Subject shows INcorrectly in Outlook 2007.

     

    Conclusion:

    ---------------------

    The main part is:

    =?koi8-r?Q?=C1=C1=D7=D7=C1=C4=D0=C1=CF=CC=C4=C1=D7=D0=DB=DD=C5=CB=D6=C4=CD=D9=D7=CF=D0=DA=DD=D5=CB=C4=D9=CC=D7=CF=D0=CC=C1=D0=CF=C4=CC=D7=C1=CF=C4=CC=D9=D7=CF=C1=DB=DD=D5=C1=CF=D7=D9=C4=C1=CC=CF=CB=D5=C3=C4=DB=C1=C4=CC=D0=D2=CC=C1=CF=D0=D5=C3=C4=CB=CF=DB?=

    the subject part contains 257 character

     

     

    The following RFC describe how the message header should be for Non-ASCII Text

    MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text

    http://www.faqs.org/rfcs/rfc2047.html

     

    encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

     

         An 'encoded-word' may not be more than 75 characters long, including

       'charset', 'encoding', 'encoded-text', and delimiters.  If it is

       desirable to encode more text than will fit in an 'encoded-word' of

       75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may

       be used.

     

       While there is no limit to the length of a multiple-line header

       field, each line of a header field that contains one or more

       'encoded-word's is limited to 76 characters.

     

       The length restrictions are included both to ease interoperability

       through internetwork mail gateways, and to impose a limit on the

       amount of lookahead a header parser must employ (while looking for a

       final ?= delimiter) before it can decide whether a token is an

       "encoded-word" or something else.

     

    encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

       charset = token    ; see section 3

       encoding = token   ; see section 4

       token = 1*<Any CHAR except SPACE, CTLs, and especials>

       especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "

                   <"> / "/" / "[" / "]" / "?" / "." / "="

       encoded-text = 1*<Any printable ASCII character other than "?"

                         or SPACE>

     

    Conclusion:

    ---------------------

    MAIL.RU does not follow the RFC2047, as the line should not be longer than 75 character.

     

    The following example shows how a large line should be:

     

    Content-Type: text/plain; name=
    "=?iso-2022-jp?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9JD8bKEI=?=
    =?iso-2022-jp?B?GyRCJEEkRCRGJEgkSiRLJEwkTSROJE8kUiRVJFgkWyReJF8bKEI=?=
    =?iso-2022-jp?B?GyRCJGAkYSRiJGQkZiRoJGkkaiRrJGwkbSRvJHIkcyMxIzIbKEI=?=
    =?iso-2022-jp?B?GyRCIzMjNCM1IzYjNyM4IzkjMBsoQi50eHQ=?="

     

    Exchange was designed and written to follow the RFC’s as strict as possible.

    But during the Exchange 2007 beta program many customer complained about

    wrong attachment/subject names, so the Product Group decided to increase (while decoding header line) the default 75 character to 256.

    This is why the first example was OK, and the second was grabbed.

     

    (for outgoing mails of course the Exchange 2007 follows the RFC2047 any time)

     

    Other interesting question is why it worked in Exchange 2003?

    This problem is not seen in Exchange 2003 as we are not very strict on RFC 2046's interpretation for line length.

    The Exchange 2007 behavior is more strict, and more correct about RFC’s. Exchange 2003 was much more lenient about it.

    This is the reason why it worked under Exchange 2003, and why it is not working under E2K7.

    The RFC expected behavior is what we have now in Exchange 2007. (but we made Exchange 2007 more lenient too: increasing the line length from 75 to 256)

     

     

    So to summary: this behavior is as by design in Exchange 2007.

    MAIL.RU does not follow RFC2047. Exchange 2007 was prepared (till line length 256) to cooperate with non-RFC conform sender side.

     

    So is there any workaround?

    ---------------------------------

    Yes there is: There is an option to increase the built in 256 to 4096 character.

     

    1. Go to the Exchange 2007 Hub server which is accepting the emails from the application

    2. Locate the bin folder in the Exchange Installation Directory

    3. You will see a file named EdgeTransport.exe.config

    4. Make a copy of the file and save it in a safe location

    5. Open this file with notepad

    6. The original file will look like the below:

     

    <configuration>

    <runtime>

    <gcServer enabled="true" />

    </runtime>

    <appSettings>

    <add key="AgentLogEnabled" value="true" />

    <add key="ResolverRetryInterval" value="30" />

    ……………..

    </configuration>

     

    7. Add the below lines in between the <configuration> and the <runtime> lines (Don’t need to modify the version field. Value 4096 means we are increasing the value to 4096 bytes)

     

    <configSections>

    <section name="CTS" type="Microsoft.Exchange.Data.Internal.CtsConfigurationSection, Microsoft.Exchange.Data.Common, PublicKeyToken=31bf3856ad364e35, version=8.0.681.0, culture=neutral"/>

    </configSections>

    <CTS>

    <MimeLimits>

    <MaximumEncodedWordLength Value="4096"/>

    </MimeLimits>

    </CTS>

     

    8. Restart the Exchange Transport Service on the server

     

    • Помечено в качестве ответа kkvkkv 5 февраля 2009 г. 4:30
    4 февраля 2009 г. 19:32

Все ответы

  • При использовании почтового клиента Outlook или OE для отправки по smtp проблема сохраняется? При использовании кодировки, отличной от utf-8 проблема сохраняется?

    29 октября 2008 г. 7:14
  • почту шлет TFS , проблема только с ним Sad

    29 октября 2008 г. 7:19
  • Я бы на вашем месте открыл инцидент технической поддержки, потому что оба продукта выпущены компанией Microsoft. Возможно это помогло бы решить не только вашу проблему

    29 октября 2008 г. 9:10
  •  Pavel Dugaev написано:

    Я бы на вашем месте открыл инцидент технической поддержки, потому что оба продукта выпущены компанией Microsoft. Возможно это помогло бы решить не только вашу проблему

     

    Павел , у вас же проблема была подобного рода - сервер принимает сообщение , но затем при конвертации в mapi - обрезает до 256 символов

    31 октября 2008 г. 12:05
  •  kkvkkv написано:

     

    (ответ типа создавать тему меньше по длине, некатит )

     

    не катит , но придется

    31 октября 2008 г. 12:07
  •  Sergey Krylov написано:

    не катит , но придется

    а может агента сделать ? или павило чтобы дописывать нелостающий символ вручную? вот только как я не знаю еще
    31 октября 2008 г. 12:19
  •  kkvkkv написано:

     Sergey Krylov написано:

    не катит , но придется

    а может агента сделать ? или павило чтобы дописывать нелостающий символ вручную? вот только как я не знаю еще

     

    О каком правиле идет речь ?

     

    А что собственно должнен делать агент ? агенты не работают на уровне конвертации сообщений в mapi формат , по которому собственно сообщения в базу и ложатся

    31 октября 2008 г. 12:47
  • как пример..

    когда писмьо идет с user001@mydomain.ru и в тема начинается с =?utf-8?B? то оставить 255 символов и в конце сделать =?= если этого там нет.

     

    1 ноября 2008 г. 4:51
  •  kkvkkv написано:

    как пример..

    когда писмьо идет с user001@mydomain.ru и в тема начинается с =?utf-8?B? то оставить 255 символов и в конце сделать =?= если этого там нет.

     

     

    в таком уж случае оставлять 252 -)

    1 ноября 2008 г. 10:00
  •  Sergey Krylov написано:
     kkvkkv написано:

    как пример..

    когда писмьо идет с user001@mydomain.ru и в тема начинается с =?utf-8?B? то оставить 255 символов и в конце сделать =?= если этого там нет.

     

     

    в таком уж случае оставлять 252 -)

     

    ну вы поняли же идею.. вопрос как ее в жизнь реализовать?

    1 ноября 2008 г. 12:07
  • писать SmtpReceiveAgent

     

    1 ноября 2008 г. 12:44
  •  Sergey Krylov написано:
    писать SmtpReceiveAgent

     

    значит реально всетаки....

    подскажите тогда где поглядеть примеры Smile или кто видел статьи..

    2 ноября 2008 г. 7:10
  •  kkvkkv написано:
     Sergey Krylov написано:
    писать SmtpReceiveAgent

     

    значит реально всетаки....

    подскажите тогда где поглядеть примеры или кто видел статьи..

     

    SDK скачайте да смотрите

    5 ноября 2008 г. 9:45
  • Все, что удалось найти по теме ломаного загаловка, так это параметр MaxMimeSubjectLength - это ограничение определяет максимально возможное число текстовых знаков в теме сообщения. Данный параметр имеет значение 255. А вот как изменить этот параметр непонятно. Может кто-то знает как ограничение увеличить хотябы до 512 символов? Или это неизменяемо???

     

    Спасибо.

    3 января 2009 г. 9:23
  •  Petrovich1 написано:

    Все, что удалось найти по теме ломаного загаловка, так это параметр MaxMimeSubjectLength - это ограничение определяет максимально возможное число текстовых знаков в теме сообщения. Данный параметр имеет значение 255. А вот как изменить этот параметр непонятно. Может кто-то знает как ограничение увеличить хотябы до 512 символов? Или это неизменяемо???

     

    Спасибо.

    выяснили чего?

    11 января 2009 г. 19:44
  • Отец-создатель Exchange 2007 и его свита с приближенными упорно отмалчиваются по этой теме. Тайные силы электричества...

     

    11 января 2009 г. 20:48
  •  Petrovich1 написано:
    Отец-создатель Exchange 2007 и его свита с приближенными упорно отмалчиваются по этой теме. Тайные силы электричества...

     

     

    Да "глухого" молчания все ж нет  http://technet.microsoft.com/ru-ru/library/bb397226.aspx

    12 января 2009 г. 15:12
  • MaxMimeSubjectLength
    увеличить можно?.. я этого не понял из статьи.. какого его максимальный размер?
    13 января 2009 г. 10:15
  •  kkvkkv написано:
    MaxMimeSubjectLength
    увеличить можно?.. я этого не понял из статьи.. какого его максимальный размер?

     

    Чисто теоретически возможно все - другое дело что для сего действа придется переписывать формат базы + MAPI + клиентов и еще остального немного до кучи

    13 января 2009 г. 11:25
  • значит никак. ясно.
    14 января 2009 г. 15:51
  •  Всетаки додавили мы этот вопрос. Пришлось обратиться к платной тех. поддержке Microsoft.
    После долгих боданий проблему признали и описали возможный вариант решения.
    Протестировали - работает. Охотно делюсь им со всеми пользователями Exchange 2007.
    Привожу полный ответ и описание проблемы:

    Данное поведение Exchange 2007 не является ошибкой.

    Оно заложено изначально разработчиками продукта и соответствует стандарту RFC2047 (http://www.ietf.org/rfc/rfc2047.txt)

    Exchange 2003 был более лоялен к данному стандарту, поэтому в случае отсылки письма с mail.ru Тема письма не искажалась.

    Соответственно, сам сервер mail.ru также не следует всем рекомендациям, описанным в RFC2047.

     

    В качестве решения проблемы Вы можете использовать решение предложенное в разделе Workaround.

     

    Technical Analysis

    ==================

    First I tried to reproduce the problem. I was able to reproduce it without any problem.

    The issue is related to the Exchange version and not to the client.

    With Exchange 2003 there was no problem, but with Exchange 2007 the problem occurred.

     

    Example 1.

     

    Initial data:

    - Sender's mail client - free mail service MAIL.RU

    !!==>   Subject: contains 81 (!!!) character in Russian encoding.

               This was only the letters without any characters, spaces, digits, etc.

    - Recipient's mail client: OLK 2007 (12.0.6316.5000) SP1.

    - Mailbox server:  Exchange 2007 SP1

    !!==>   Field Subject shows CORRECTLY in Outlook 2007.

    Subject: =?koi8-r?Q?=C6=CC=C4=C4=D0=C1=CF=CC=C4=C1=D7=D0=DB=DD=C5=CB=D6=C4=CD=D9=D7=CF=D0=DA=DD=D5=CB=C4=D9=CC=D7=CF=D0=CC=C1=D0=CF=C4=CC=D7=C1=CF=C4=CC=D9=D7=CF=C1=DB=DD=D5=C1=CF=D7=D9=C4=C1=CC=CF=CB=D5=C3=C4=DB=C1=C4=CC=D0=D2=CC=C1=CF=D0=D5=C3=C4=CB=CF=DB=C9?=

     

    Conclusion:

    -------------------

    The main part is:

    =?koi8-r?Q?=C6=CC=C4=C4=D0=C1=CF=CC=C4=C1=D7=D0=DB=DD=C5=CB=D6=C4=CD=D9=D7=CF=D0=DA=DD=D5=CB=C4=D9=CC=D7=CF=D0=CC=C1=D0=CF=C4=CC=D7=C1=CF=C4=CC=D9=D7=CF=C1=DB=DD=D5=C1=CF=D7=D9=C4=C1=CC=CF=CB=D5=C3=C4=DB=C1=C4=CC=D0=D2=CC=C1=CF=D0=D5=C3=C4=CB=CF=DB=C9?=

    the subject part contains 254 character

     

    Example 2.

     

    Initial data:

    - Sender's mail client - free mail service MAIL.RU

    !!==>   Subject: contains 82 (!!!) character in Russian encoding.

               This was only the letters without any characters, spaces, digits, etc.

    - Recipient's mail client: OLK 2007 (12.0.6316.5000) SP1.

    - Mailbox server:  Exchange 2007 SP1.

    Subject: =?koi8-r?Q?=C1=C1=D7=D7=C1=C4=D0=C1=CF=CC=C4=C1=D7=D0=DB=DD=C5=CB=D6=C4=CD=D9=D7=CF=D0=DA=DD=D5=CB=C4=D9=CC=D7=CF=D0=CC=C1=D0=CF=C4=CC=D7=C1=CF=C4=CC=D9=D7=CF=C1=DB=DD=D5=C1=CF=D7=D9=C4=C1=CC=CF=CB=D5=C3=C4=DB=C1=C4=CC=D0=D2=CC=C1=CF=D0=D5=C3=C4=CB=CF=DB?=

    !!==>   Field Subject shows INcorrectly in Outlook 2007.

     

    Conclusion:

    ---------------------

    The main part is:

    =?koi8-r?Q?=C1=C1=D7=D7=C1=C4=D0=C1=CF=CC=C4=C1=D7=D0=DB=DD=C5=CB=D6=C4=CD=D9=D7=CF=D0=DA=DD=D5=CB=C4=D9=CC=D7=CF=D0=CC=C1=D0=CF=C4=CC=D7=C1=CF=C4=CC=D9=D7=CF=C1=DB=DD=D5=C1=CF=D7=D9=C4=C1=CC=CF=CB=D5=C3=C4=DB=C1=C4=CC=D0=D2=CC=C1=CF=D0=D5=C3=C4=CB=CF=DB?=

    the subject part contains 257 character

     

     

    The following RFC describe how the message header should be for Non-ASCII Text

    MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text

    http://www.faqs.org/rfcs/rfc2047.html

     

    encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

     

         An 'encoded-word' may not be more than 75 characters long, including

       'charset', 'encoding', 'encoded-text', and delimiters.  If it is

       desirable to encode more text than will fit in an 'encoded-word' of

       75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may

       be used.

     

       While there is no limit to the length of a multiple-line header

       field, each line of a header field that contains one or more

       'encoded-word's is limited to 76 characters.

     

       The length restrictions are included both to ease interoperability

       through internetwork mail gateways, and to impose a limit on the

       amount of lookahead a header parser must employ (while looking for a

       final ?= delimiter) before it can decide whether a token is an

       "encoded-word" or something else.

     

    encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

       charset = token    ; see section 3

       encoding = token   ; see section 4

       token = 1*<Any CHAR except SPACE, CTLs, and especials>

       especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "

                   <"> / "/" / "[" / "]" / "?" / "." / "="

       encoded-text = 1*<Any printable ASCII character other than "?"

                         or SPACE>

     

    Conclusion:

    ---------------------

    MAIL.RU does not follow the RFC2047, as the line should not be longer than 75 character.

     

    The following example shows how a large line should be:

     

    Content-Type: text/plain; name=
    "=?iso-2022-jp?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9JD8bKEI=?=
    =?iso-2022-jp?B?GyRCJEEkRCRGJEgkSiRLJEwkTSROJE8kUiRVJFgkWyReJF8bKEI=?=
    =?iso-2022-jp?B?GyRCJGAkYSRiJGQkZiRoJGkkaiRrJGwkbSRvJHIkcyMxIzIbKEI=?=
    =?iso-2022-jp?B?GyRCIzMjNCM1IzYjNyM4IzkjMBsoQi50eHQ=?="

     

    Exchange was designed and written to follow the RFC’s as strict as possible.

    But during the Exchange 2007 beta program many customer complained about

    wrong attachment/subject names, so the Product Group decided to increase (while decoding header line) the default 75 character to 256.

    This is why the first example was OK, and the second was grabbed.

     

    (for outgoing mails of course the Exchange 2007 follows the RFC2047 any time)

     

    Other interesting question is why it worked in Exchange 2003?

    This problem is not seen in Exchange 2003 as we are not very strict on RFC 2046's interpretation for line length.

    The Exchange 2007 behavior is more strict, and more correct about RFC’s. Exchange 2003 was much more lenient about it.

    This is the reason why it worked under Exchange 2003, and why it is not working under E2K7.

    The RFC expected behavior is what we have now in Exchange 2007. (but we made Exchange 2007 more lenient too: increasing the line length from 75 to 256)

     

     

    So to summary: this behavior is as by design in Exchange 2007.

    MAIL.RU does not follow RFC2047. Exchange 2007 was prepared (till line length 256) to cooperate with non-RFC conform sender side.

     

    So is there any workaround?

    ---------------------------------

    Yes there is: There is an option to increase the built in 256 to 4096 character.

     

    1. Go to the Exchange 2007 Hub server which is accepting the emails from the application

    2. Locate the bin folder in the Exchange Installation Directory

    3. You will see a file named EdgeTransport.exe.config

    4. Make a copy of the file and save it in a safe location

    5. Open this file with notepad

    6. The original file will look like the below:

     

    <configuration>

    <runtime>

    <gcServer enabled="true" />

    </runtime>

    <appSettings>

    <add key="AgentLogEnabled" value="true" />

    <add key="ResolverRetryInterval" value="30" />

    ……………..

    </configuration>

     

    7. Add the below lines in between the <configuration> and the <runtime> lines (Don’t need to modify the version field. Value 4096 means we are increasing the value to 4096 bytes)

     

    <configSections>

    <section name="CTS" type="Microsoft.Exchange.Data.Internal.CtsConfigurationSection, Microsoft.Exchange.Data.Common, PublicKeyToken=31bf3856ad364e35, version=8.0.681.0, culture=neutral"/>

    </configSections>

    <CTS>

    <MimeLimits>

    <MaximumEncodedWordLength Value="4096"/>

    </MimeLimits>

    </CTS>

     

    8. Restart the Exchange Transport Service on the server

     

    • Помечено в качестве ответа kkvkkv 5 февраля 2009 г. 4:30
    4 февраля 2009 г. 19:32
  • значит играя с параметром
    <MaximumEncodedWordLength Value="4096"/>
    можно указывать длину?



    5 февраля 2009 г. 4:30
  • НУ что же. у меня тоже все заработало как надо
    11 февраля 2009 г. 9:43
  • <section name="CTS" type="Microsoft.Exchange.Data.Internal.CtsConfigurationSection, Microsoft.Exchange.Data.Common, PublicKeyToken=31bf3856ad364e35, version=8.0.681.0, culture=neutral"/>
    там где выделенно надо менять?
    12 февраля 2009 г. 16:09
  • тоже помогло. Инициатором проблемы была 1С :).

    PS: на последний вопрос ответ - нет. Ни надо менять ни чего.


    Regards, Dmitriy Ilyin
    19 октября 2009 г. 13:21
  • Спасибо! ) Помогло! (сейчас стоит Exchange 2007 экспериментально, собираемся переходить на 2010 и эксплуатировать его в боевом режиме)

    Только не понятно, что за строчка с версией, почему её нельзя менять, и PublicKeyToken откуда берется и зачем он нужен.

    Однако, хорошо, что всё работает, так что не задумываюсь по этим тонкостям.

    3 февраля 2010 г. 13:35
  • в 2010 тоже ?
    12 марта 2010 г. 14:26
  • в 2010 тоже ?

    судя по http://technet.microsoft.com/ru-ru/library/bb397226.aspx - аналогично
    Exchange MVP. _ This posting is provided "AS IS" with no warranties, and confers no rights.
    12 марта 2010 г. 15:20
  • а как быть если такое происходит не с темой, а с именем отправителя, для примера:

    =?UTF-8?q?=D0=A4=D0=BE=D1=80=D1=83=D0=BC_=D0=92=D1=81=D0=B5=D1=80=D0=BE=D1=81=D1=81=D0=B8=D0=B9=D1=81=D0=BA=D0=BE=D0=B3=D0=BE_=D0=9A=D0=BB=D1=83=D0=B1=D0=B0_SUZUKI_-_=D0=9A=D0=BB=D1=83=D0=B1_=D0=A1=D1=83=D0=B7=D1=83=D0=BA=D0=BE=D0=B2=D0=BE=D0=B4=D0=BE=D0=B2-=D0=A1=D0=9E=D0=AE=D0=97_=D0=94=D0=A0=D0=A3=D0=97=D0=95=D0=99?=@host.kks-telecom.ru

    тут даже не в дине вроде дело, т.к. последовательность ?= есть в конце енкодированного текста...

    14 сентября 2010 г. 6:42
  • А как решать в 2010? подобный способ не помогает
    15 ноября 2011 г. 7:50