Имеются два eToken для шифрования переписке, есть sendmail как почтовый агент, письма пишуться в outlook-e.
при шифровке писем должены добавляться три строчки s-mime в загаловок. при отправке из мозиловской птицы добавляеться две из них, а из оутлука ни одной. в итоге письма шифруются, а почтовый клиент этого не знает. сетевики говорят, что это все потому, что sendmail просто не умеет пересылать такие письма.
подскажите, как доказать им обратное?

думается, и так понятно, что самому с подобным сталкиваться не приводилось, но все равно извеняюсь если глупость спрошу:
нужно ли доустанавливать модуль s/mime для sendmail для обработки таких сообщений?
нужно ли доустанавливать "модуль" openssl и ручками прописывать порядок передачи шифрованных писам? если да, то могла ли мозиловская птица выполнять команды openssl самостоятельно?

кто-нибудь, кто настраивал sendmail, отзовитесь, хотя бы через личку пообщаемся, уж больно требуется в крайчайшие сроки разобраться

пытаюсь искать, извеняюсь за предыдущие глупые вопросы. на данный момент созрели следующие:
правильно ли я понимаю -- ставится openssl, в файле sendmail.cf прописывають вызовы его с ключами, в последствии, когда пользователь пишет письмо, sendmail его получает, применяя прописанные команды шифрует и отправляет. ничего не попутал?
тогда вопрос -- создается ли при этом ssl сессия, если да, то когда, когда клиент стучиться к sendmail-у, тот приходит, создает сессию, формирует письмо, отсылает и закрывает сессию?
возможна ли подпись письма сертификатом без ssl, по идее нет, значит отсутсвие информации о защифрованности письма в заголовке это не корректная настройк sendmail.cf?

грубо говоря, нет строчки в заголовке письма, что письмо зашифровано s-mime type: что-то там, как добиться ее появления?

и по прежнему актуально

поддержка добавлений S/MIME - свойство, поддерживаемое MUA, т.е. бёрдой или аутглюком.

значит почтовый сервер, в данном случае sendmail, никак не может удалить из заголовка строчки с информацией s-mime?
то есть, письмо, зашифрованное и отправленное в последствии отображаемое в отправленных как защифрованное, и полученное хоть и фактически зашифрованным, но без пометки об этом, ведет себя так из-за настроек почтового клиента? а почтовом сервере можно и не вспоминать?

насчет поддерживающих клиентов посмотри тут

Сервер не "не может", а "не должен".
Ровно также как и не должен стирать атачменты, 
но многие фирмы ставят у себя на серверах модифицированные настройки которые:

• ограничивают величину прикрепленных данных
• ограничивают тип прикрепленных данных (напр. разрешается только PDF)
• ограничивают количество прикрепленных данных

В работе с S/MIME самая большая проблема - корпоративные сервера, фильтрующие информацию, и неподдерживающие клиенты.

Корпоративные сервера можно понять: если пропускать шифрованную инфу, есть 2 пути:
1. нет контроля над тем, что приходит и уходит. 
2. все ключи хранить на сервере, и фактически у работников нет никакой конфиденциальности.
(Для таких случаев работают просто в VPN. внутри ничего не шифруют, а VPN шифрует данные от перхвата и быстрого понимания. перехватить можно всегда.)

Я не знаю что именно есмь eToken, но по идее Thunderbird умеет работать с S/MIME, и OutLook тоже.

удачи.

eToken -- железка, usb брилок, помимо всего прочего -- хранит пару ключей и сертификаты

теперь несколько подробней: получили мы эти eToken из управляющей компании, но настроить их не смогли, когда это поручили мне, то в ходе экспериментов выяснилось, что если письмо подписывать (тобишь сертификат прикреплять) то все работает отлично, но если шифровать, то оно шифруется (текст и прикрепляемые файлы шифруются DES-ом, посредством ключа с eToken-а, результат помещается, как положено, в файл smime.p7m и с этим файлом письмо уходит), в папке отправленные письмо помечено как зашифрованное и не читается без eTokena, но к получателю (даже если самому себе отправлять) письмо приходит без пометки о шифровании. поэтому outlook его игнорирует, а thunberbird распознает (расшифровует), хоть тоже не помечает как зашифрованное.
постучавшись в яндекс узнал, что зашифрованное письмо должно иметь три строчки, точно сейчас не помню, но такие s-mime-application: что-то\pkcs7 (у нас семь, цифра может быть другой), s-mime-content: что-то и s-mime-type: что-то. первая говорит как зашифрованно и/или подписано, вторая -- где результат (указывается s7m файл), а третья указывает, подписанно письмо и/или зашифрованно. так-вот, в оутлуке эти строчки куда-то пропадают, или есть, но написано в них не то, что надо, а вот в птице есть только первые две. кстати, появляется одна строчка, которой, вроде как, быть не должно, точно не припомню, но там что-то-message-id: строчка случайных букв и цифр, что это может быть?
была мысль, может sendmail как-то неккоректно обрабатывает base64, но не смог придумать как это может выглядеть.
посему есть два предположения -- может sendmail не поддерживает это самое pkcs7, где-то встречал, что он хорошо обрабатывает pkcs10, а вот седьмой -- любимый майкрософтом стандарт, и с ним какие-то проблемы. если это так, то как их можно подружить?
второе -- может sendmail как-то плохо понимает способ приатачивания того самого файла p7m, ибо его можно найти в письме, но оутлук пишет, что нет приатаченных файлов.

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

и еще -- производитель упомянутой железки www.aladdin.ru, связывался с ними, но они меня направили на страничку википедии о s/mime

Это сообщение отредактировал(а) aleksh - 10.11.2008, 08:46

я вот это не понял. что значит "получили" ?
вам их просто принесли и сказали "если поучится - попробуй заюзать ?" или это реально внедрение технологии ?
документация есть ? своя, внутренняя ?

если это так, то все аттачи не должны были корректно приходить. не только s/mime

a каким именно их продуктом вы пользуетесь ?
и каким именно способом вы с ними связывались ?
думаю наиболее эффективно - узнать через того, от кого получили - на каких условиях получили, какая имеется поддержка.
а потом - позвонить. пояснить, что вы не частное лицо, а фирма, дать реквизиты фирмы, возможно есть "номер клиента"

как-то всё ... непонятно у вас там...

и еще есть момент - всей инфраструктуры - т.е. публичного ключа CA - не достаточно, надо чтобы в клиенте был установлен и ключ CA, и специальный ключ пользователя, который при создании был сконфигурирован "для шифрования".
внутри ключа есть разные данные, и один из них - можно ли этим ключом шифровать, или только подписывать.

Добавлено через 4 минуты
и залогившись можно видеть эти пдф-ки:
http://www.aladdin.ru/support/download/category188

там вроде как то что вам надо.

согласен, но не с моей должности внедрять изменения, а уйти пока не могу -- не исчерпан лимит лояльности, хоть и знаю, что ее японцы придумали чтобы денег не платить...

теперь по сути

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

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

в чем, собственно, проблема -- шифрование то, само, работает. если переписываться через мозиловскую птицу -- то она увидит шифровку, пнет железку, и та все расшифрует. вот в чем беда -- письмо не индентифицируется как шифрованное, хоть таково на самом деле, поэтому нет обращения к железке, поэтому его нельзя прочитать, а с ключами все в порядке. пользоваться этими брелками будет руководство, причем не только наше, поэтому объяснить им, что оутлук это сакс, а мозилла рулит и есть правильная почта не получится

сетевики наши с нашим почтовым клиентом знакомы мало (те, кто его настраивал уже сменили место работы), они теперь уперлись и сказали, что пока им не купят последний ms exchange ничего у нас работать не будет, ну и прочее, посему это уже вопрос принципа...

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

касательно почтового клиента -- вот нашел один мануальчик, все уже давно сделано как там написано, посему продолжаем грешить на sendmail, ибо сетевики божатся, что больше к письмам никто не притрагивается. касательно совместимости -- находил утверждение, что sendmail s/mime поддерживает, вот только без подробностей, нужны ли специфические настройки или как...

не понял, но по звуку - оффтоп

не понял, но по звуку - оффтоп

не понял, но по звуку - 90% оффтоп.
так много лирики... а тема-то прагматичная.

у вас чей CA - свой внутренний, или какой-то VeriSign ?
он в клиентские приложения внедрен ДО установки пользовательского сертификата ?

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

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

не понял, что значит "до"?

я же сказал, ранее, что когда создаётся CA, если его некорректно создали, сам req файл, то такой CA не позволяет создавать шифровальные сертификаты, т.е.
в сертификате, в файле .pem или .pks7, там солжно быть указано, что данный сертификат  можно использовать для:
1. подписывания текста
2. шифрования текста.

Если сертификат создан БЕЗ опции шифрования, то не бует он позволять с ним шифроваться.
вопрос, если у вас все клиенты, т.е. пользователи всех сертификатов не могут шифровать, или могут, но только с птицей.


"до", это в смысле "перед", по времени, и потом он должен отображаться в списке CA сертификатов птицы или аут-глюка.

в моем серте в Details есть:

как видим написано Signing, т.е. подписывание. Для шифровки нужен специальный ключ, и в результирующем сертификате
нужно чтобы было написано не только "E-mail protection", но и что-то связанное с Email Encryption или Email Encipherment
вот.
всё это свойства сертификата, которые определяются:

• типом CA (что он хочет и что может давать)
• свойствами certificate request-а

если я понимаю о чем говорю ;-)

сами сертификаты зашиты в железке, если его экспортировать, то в назначении будет указано "Цифровая подпись, Шифрование ключей (a0)"
пока писал увидел второй пост -- что написано в корневом сейчас посмотреть не могу, завтра гляну

на данный момент брилков две штуки, ведут себя одинаково -- в оутлуки и птице, шифрованное отмечаеться иконкой-замком и не доступно для предварительного просмотра, необходимо его (письмо) открыть (дабл-клик), тогда просыпается железка запрашивает пароль и дешифрует. так вот -- ведут себя так только письма написанные и отправленные (помещенные в соответствующую папку), а полученные, без иконки и с доступным предпросмотром, вот только птица после дабл-клика железку будит, а оутлук нет

отоброжается