Почему SMTP-серверы просто не требуют аутентификации всех отправителей перед приемом почты? [закрыто]
The mail submission protocol (RFC4409) does exactly what you ask (it requires both encryption and authentication) and is used by most ISPs, but it's probably not what you mean as it's outbound-only.
For inbound it's harder. There can't be a user/pass mechanism because any server in the world could be sending you something legitimately without advance notice, so the receiving server needs to investigate the sender. There are several protocols to allow this to work within SMTP, in particular: SPF, DKIM and DMARC. SPF has a chequered history that wasn't helped by Microsoft's SenderID protocol that really confused things and wasn't helpful.
SPF sets out to authorise sources of email via IP address or hostname using DNS entries. Unless rules result in outright PASS or FAIL results, it's not really effective, and imposes limits on user settings (e.g. preventing users from using ISP's mail servers to send from their company's domain). Its effectiveness is limited, however it is supported by many larger ISPs.
DKIM sets out to prove that message contents has not been tampered within transit by providing a cryptographic hash of messages headers and bodies. It has parallels with S/MIME signatures, but at a different level in the stack.
SPF and DKIM work well together, but they lack management oversight as to what to do on failure - no mechanismss are provided to report contraventions, and most failures just end up lost in log files. DMARC sets out to solve that by defining reporting mechanisms. As such, DMARC removes the guesswork as to what to do with SPF and DKIM failures that is otherwise required.
In answer to your question, SPF is easy to implement (it's just a DNS record), but deciding what to put in it can be messy. DKIM is complicated and integration with mail servers can be difficult. DMARC relies on both of them being implemented. Taken together, that's why many domains do not implement any of them.
There are possible alternatives like DJB's IM2000 protocol which shifts the burden of storage and authentication to the sender, but it would involve replacing the entire world of SMTP servers, so it's more an academic exercise than anything else.
Какую проблему вы пытаетесь решить?
Допустим, каждому SMTP-серверу требуется имя пользователя и пароль. Теперь вам нужно будет поддерживать имя пользователя и пароль для каждого человека, который может когда-либо отправить электронное письмо любому из ваших пользователей. Это невозможно. Однако представьте себе, что это возможно. Затем спамер просто создаст новое имя пользователя и пароль и отправит вам спам. Если вы отключите учетную запись, они создадут новое имя пользователя и пароль. Это не лучше, чем если бы вы заблокировали их IP-адрес; они перемещаются на новый IP-адрес.
Допустим, вы принимали только электронную почту, подписанную GPG, чтобы вы знали, кто отправил сообщение. Это еще одна форма аутентификации, но она не требует установки имени пользователя и пароля для каждого пользователя в мире. Спамеры просто подписывали весь свой спам. Это немного замедлит их, и вы поймете, что да, этот спам абсолютно исходит от определенного человека. Однако вам все равно придется заблокировать этого человека, который затем сгенерирует новый ключ GPG, и цикл повторится.
SMTP - это «федеративная служба». Каждая система электронной почты является автономной, но федерация (совокупность всех SMTP-серверов в Интернете) может взаимодействовать друг с другом. Проблема такой большой федерации в том, что она должна работать на доверии; а спамеры подрывают это доверие. Доверие - это социальная проблема. Вы не можете решить социальные проблемы с помощью технологий.