Портове, криптиране и вход в системата

Модул 1: Как работи имейлът · Време за четене: 10 минути

Учебна цел: След този урок ще можете да кажете за какво служи всеки пощенски порт, да обясните разликата между STARTTLS и директен TLS, и да обясните съобщение за сертификат или отказан вход.

Ключови понятия: порт 25, 587, 465, 993, 995, 143, 110, STARTTLS, директен TLS (implicit TLS, RFC 8314), сертификат, име на сървър, SMTP удостоверяване (SMTP AUTH), open relay, блокиране на порт 25, парола за приложение, OAuth

Портът е врата

Един сървър има един IP адрес, но много врати. Всяка услуга "слуша" на свой собствен порт, тоест номер. Вашият уеб браузър чука на порт 443, Вашата пощенска програма на порт 993 за да чете поща и на 587 или 465 за да изпраща. Ако изберете грешната врата, никой не отговаря, или отговаря някой, който говори друг език. Това води до неясни съобщения за грешка като "не може да се осъществи връзка" или "сървърът не отговаря".

Пощенските портове накратко:

Защо не просто порт 25 за изпращане?

Преди време в пощенската си програма настройвахте порт 25. Това е отминало по две причини.

Първо: на порт 25 пощенски сървър приема поща от всеки, за собствените си домейни. Не се извършва вход. Сървър, който на порт 25 пренасочва поща от всеки и към чужди домейни, се нарича open relay, и той бива злоупотребен от спамъри в рамките на няколко часа. Затова изпращането на собствената Ви поща до целия свят е станало отделна услуга: submission на порт 587 (и 465), където винаги първо влизате в системата.

Второ: много доставчици на интернет блокират изходящ трафик към порт 25 от домашни връзки. По този начин заразен компютър в дневна стая не може да изпраща спам директно до пощенски сървъри. Последствието за Вас: ако се опитате да изпращате от пощенската си програма през порт 25, може да не работи у дома, а на работа да работи, или обратното.

Запомнете: пощенските програми изпращат през 587 или 465, с вход в системата. Порт 25 е за комуникация между сървъри.

STARTTLS или директен TLS?

Има два начина за криптиране на пощенска връзка.

Директен TLS (implicit TLS): връзката е криптирана от първия байт, точно както уебсайт с https. Това се случва на 465, 993 и 995.

STARTTLS: връзката започва некриптирана. Сървърът казва "мога да криптирам", клиентът отговаря с STARTTLS, и от този момент всичко е криптирано. Това се случва на 587 (и на 25, 143 и 110).

За сигурността няма голямо значение кой от двата метода се използва, стига Вашата програма да изисква STARTTLS задължително. Рискът при STARTTLS е в началото: някой, който се намира между Вас и сървъра, може да премахне предложението "мога да криптирам". Програма, която тогава тихомълком продължава некриптирано, изпраща Вашата парола четливо по линията. Затова RFC 8314 (2018) препоръчва за пощенски програми директен TLS (465, 993, 995) пред STARTTLS. На практика 587 със STARTTLS и 465 със SSL/TLS са еднакво добри, стига да зададете криптирането във Вашата програма на "задължително", а не на "ако е налично".

Често срещана грешка е неправилната комбинация: порт 587 със "SSL/TLS", или порт 465 със "STARTTLS". Тогава програмата очаква нещо различно от това, което прави сървърът, и връзката зависва или не успява. Запомнете двойките: 587 + STARTTLS и 465 + SSL/TLS. Програмите понякога наричат директния TLS "SSL", "SSL/TLS" или "TLS"; STARTTLS понякога също се нарича "TLS". Затова гледайте порта.

Сертификатът и името на сървъра

При всяка криптирана връзка сървърът показва сертификат, който доказва, че е този, за когото се представя. Вашата пощенска програма проверява две неща: дали сертификатът е издаден от доверена страна и все още е валиден, и дали името, което сте въвели като сървър, присъства в него.

Второто е най-честата причина за грешки. Ако въведете mail.example.com, но в сертификата стои само server12.hosting.example, получавате съобщение от рода на "Не може да се потвърди идентичността на сървъра" или "Основното име на целта е неправилно". Самата връзка е криптирана, но Вашата програма не може да е сигурна, че разговаря с истинския сървър.

Не отхвърляйте такова съобщение без да го прочетете. Решението е име на сървър, което присъства в сертификата (вижте урок 2.1). При споделен сървър това често е името на самия сървър, което Вашият доставчик посочва. Друга позната причина: антивирусен скенер, който "сканира" криптирана поща и за целта поставя собствения си сертификат по средата. В съобщението тогава стои името на скенера при "издаден от".

Вход при изпращане

На 587 и 465 трябва да влезете в системата, преди сървърът да изпрати Вашата поща навън. Това се нарича SMTP удостоверяване (SMTP AUTH). Във Вашата програма опцията се нарича "изходящият сървър изисква потвърждение", "изисква се вход" или "удостоверяване: обикновена парола". Обикновено използвате същото потребителско име и парола, както за IMAP.

Ако удостоверяването е изключено, или потребителското име за изходящия сървър е останало празно, можете да четете поща, но не и да изпращате. Сървърът тогава отговаря с нещо като 530 5.7.0 Authentication required или 554 5.7.1 Relay access denied. Това е най-честата причина за "получаването работи, изпращането не".

Втори вид отказ: 535 5.7.8 Authentication failed. Тогава комбинацията от потребителско име и парола не е вярна. Внимание: след няколко неуспешни опита много сървъри блокират IP адреса, от който идват тези опити, за да предотвратят отгатване на пароли. Стар телефон със стара парола може така да блокира целия Ви офис.

Пароли за приложения и OAuth

При големи доставчици като Google и Microsoft входът само с обикновената Ви парола в самостоятелна пощенска програма работи все по-рядко. Те използват OAuth: Вашата програма Ви пренасочва към страница за вход на доставчика, Вие влизате там (евентуално с двустепенна проверка), и програмата получава ключ вместо Вашата парола. Програми, които не поддържат това, понякога получават парола за приложение: отделна, дълга парола, която важи само за тази конкретна програма и която можете да отмените поотделно.

При обикновена пощенска кутия при хостинг компания обикновено влизате с паролата на самата пощенска кутия. Това прави силна и уникална парола допълнително важна (урок 3.4).

На практика: настройките на пощенска кутия

При пощенска кутия на WebOké настройките са: IMAP 993 със SSL/TLS, POP3 995 със SSL/TLS, изпращане 587 със STARTTLS или 465 със SSL/TLS, удостоверяване включено с пълния Ви имейл адрес и паролата на пощенската кутия. При други доставчици работи по сходен начин: портовете са почти навсякъде едни и същи, само името на сървъра се различава. Кое име на сървър да изберете, вижте в урок 2.1.

Обобщение

• Пощенските програми изпращат през 587 (STARTTLS) или 465 (директен TLS), винаги с вход в системата. Порт 25 е за комуникация между сървъри и често се блокира у дома.
• Четенето става през 993 (IMAP) или 995 (POP3), и двата с директен TLS.
• Комбинирайте правилно: 587 + STARTTLS, 465 + SSL/TLS. Задайте криптирането като задължително.
• Съобщение за сертификат обикновено означава: въведеното от Вас име на сървъра не присъства в сертификата. Отхвърлянето му не е решение.
• "Четенето работи, изпращането не" почти винаги означава: удостоверяването за изходящия сървър е изключено или липсва.

Тест

Задача

Задача Z1.4: Портове и сертификат на пощенски сървър. Въведете входящото и изходящото име на сървър, което използвате за собствената си пощенска кутия (ако нямате собствена пощенска кутия, използвайте imap.gmail.com и smtp.gmail.com). За порт 993 (входящ) и портовете 465 и 587 (изходящ) посочете какво очаквате: директен TLS, STARTTLS или недостъпен, и отбележете дали мислите, че името присъства в сертификата. Програмата сама установява връзка с трите порта и поставя резултата до Вашите отговори.

Прочетете още

Стъпките в тези статии важат за панелите на WebOké; при други доставчици работи по сходен начин.

• Ръководство за DirectAdmin 8.1: Всички настройки на едно място: сървъри, портове и защита
• Ръководство за DirectAdmin 8.8: Изпращането или получаването не работи: ето как да го разрешите
• Грешка със сертификата при получаване на поща
• Не мога да изпращам имейли (получаването работи)
• RFC 8314 (директен TLS за пощенски програми), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)