Что состоит в том, чтобы проверить лучший способ, является ли сервер SMTP поддерживающим SSL или нет?

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

Но можно хотеть проверить pstools программу pslist, также от Sysinternals. Можно перечислить процессы, работающие на другой машине. pslist является инструментом командной строки, как бы то ни было.

Обновление:

BTW, необходимо работать в режиме диспетчера задач для получения % ЦП, например, pslist \\имя компьютера-s

6
задан 11 September 2009 в 11:08
4 ответа

Это зависит, имеете ли Вы в виду SSL или TLS.

  • SSL имеет свой собственный выделенный порт в TCP/465. Лучший способ протестировать, поскольку это - присутствие, состоял бы в том, чтобы использовать замечательный s_client OpenSSL, который согласует обман SSL для Вас.

    openssl s_client -connect localhost:465
    

    Если Ваш сервер не связывается с localhost, затем, очевидно, заменяют это IP или именем хоста.

  • Взгляды TLS точно так же, как нормальный SMTP сначала. Шифрование согласовывается от и сверху протокола простого текста. Можно протестировать, доступно ли это путем издания запроса EHLO к серверу. Можно использовать Netcat или клиенты Telnet для этого.

    $ nc -v localhost 25
    localhost [127.0.0.1] 25 (smtp) open
    220 mail.example.com ESMTP Exim 4.69 Fri, 11 Sep 2009 09:25:20 +0100
    ehlo test
    250-mail.example.com Hello localhost [127.0.0.1]
    250-SIZE 10485760
    250-PIPELINING
    250-STARTTLS
    250 HELP
    

    Важная строка является предпредпоследней, который рекламирует возможность STARTTLS.

Чтобы сказать, как включить SSL/TLS для Вашего почтового сервера, необходимо будет сказать нам, какую почтовую посылку Вы используете.

16
ответ дан 3 December 2019 в 00:03
  • 1
    Можно использовать openssl для TLS также, если Вы добавляете-starttls smtp –  grawity 11 September 2009 в 13:19
  • 2
    Я действительно имел в виду SSL.Спасибо! Но don' t удаляют часть с TLS; I' d, вероятно, относятся к этому потоку снова когда I' m контакт с TLS уже. –  Randell 11 September 2009 в 16:03

При выполнении CentOS Вы, вероятно, используете Sendmail. Установите пакет Sendmail-мГц. В/etc/mail/sendmail.mc некоторые директивы для Вас для изучения для TLS:

dnl # Rudimentary information on creating certificates for sendmail TLS:
dnl #     cd /usr/share/ssl/certs; make sendmail.pem
dnl # Complete usage:
dnl #     make -C /usr/share/ssl/certs usage
dnl #
dnl define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl
dnl define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.crt')dnl
dnl define(`confSERVER_CERT', `/etc/pki/tls/certs/sendmail.pem')dnl
dnl define(`confSERVER_KEY', `/etc/pki/tls/certs/sendmail.pem')dnl

После того как у Вас есть та работа, можно включить Sendmail по SSL с чем-то как так:

DAEMON_OPTIONS(`Addr=142.46.200.221, Port=465, Name=SSA, M=Eas')

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

Когда я сделал это, я должен был почти всегда выполнять три экземпляра sendmail:

  • один с TLS включил на порте 587 с различными конфигурациями SMTP-AUTH (таким образом, аутентифицируемые удаленные пользователи могут отправить произвольную почту);
  • один с SSL включил на порте 465 с различными конфигурациями SMTP-AUTH (та же причина, различные клиенты (спасибо Microsoft Outlook "Экспресс"); и
  • один с TLS включил, но никакой AUTH, заблокированный вниз так, чтобы он только получил почту для допустимых локальных получателей (удаленные отправители могут использовать TLS или не, как им нравится).

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

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

0
ответ дан 3 December 2019 в 00:03

In my mind the answers given on this page are simply wrong.

The reason is that SSL/TLS + SMTP can mean two different things.

One is where you wrap the socket in SSL/TLS. If the server wants to service both unencrypted and encrypted traffic then it needs two ports for this purpose, one for each type of traffic. By convention SMTP servers normally uses port 25 for unencrypted traffic and port 465 for encrypted traffic. By use of external tools such as stunnel this can actually be implemented in such a way so that both the client and the server are unaware that the actual traffic travels on an encrypted socket. So you can implement this approach even if your SMTP server does not support SSL/TLS .. but servers like sendmail and postfix do support this so no need for an external tool.

The other approach is that STARTTLS is used. This is an extension to the SMTP protocol and thus requires both the server and the client to support it. Using STARTTLS the server can serve both encrypted traffic and unencrypted traffic over the same socket, i.e. you can use port 25 for both. You can see if a SMTP server has STARTTLS enabled by connecting to it on port 25 and issuing the EHLO command as Dan explains elsewhere on this page.

Both SSL and TLS are just encryption protocols, TLS being the successor to SSL.

I've got my info from here.

The confusion between the two approaches is accelerated by the terminology used by SMTP servers. Think of Postfix's parameters smtpd_tls_security_level and smtpd_use_tls and their associated documentation. These parameters deal with STARTTLS, not as such with TLS. Other SMTP servers does an equally great job at confusing the terminology.

0
ответ дан 3 December 2019 в 00:03

Для этого есть простой инструмент. Вы отправляете им электронное письмо, и они отвечают с кучей подробностей:

https://www.checktls.com/perl/TestSender.pl

1
ответ дан 3 December 2019 в 00:03

Теги

Похожие вопросы