답변:
기술적으로 컴퓨터에서 수신자의 SMTP 서버로 직접 이메일을 보낼 수 있습니다.
기록을 보면 원격 SMTP 서버가 다운 된 경우 시스템이 자동으로 서버를 처리하고 다시 시도하기를 원하므로 SMTP 서버가 있습니다. 마찬가지로 예전에는 모든 메일 서버가 항상 연결되어 있지는 않았습니다. 장거리 링크 비용이 많이 들기 때문에 링크가 설정되면 메일이 대기하고 전송됩니다.
인터넷이 저렴한 곳으로 이동하면 서버를 사용할 수없는 경우 전자 메일 전송을 다시 시도하는 메커니즘이 여전히 유용하며이 기능을 MUA (메일 사용자 에이전트 / 최종 사용자 메일 프로그램)에 작성하는 것은 적합하지 않습니다. 이러한 기능은 MTA (메일 서버 / SMTP 서버)에 적합합니다.
그러나 스패머 는 더욱 악화됩니다 . 대부분의 이메일 (80 % 이상)은 스팸입니다. 따라서 메일 제공 업체는이 문제를 줄이기 위해 가능한 모든 조치를 취하며 많은 기술이 이메일 전달 방식을 가정합니다. 다음은 중요한 고려 사항입니다.
그레이 리스팅 : 일부 공급자는 발신자와 수신자가 이전에 통신하지 않은 경우 자동으로 메일 연결을 끊고 SMTP 서버는 항상 스패머가 그렇지 않기 때문에 다시 시도 할 것으로 예상합니다. 이것은 스팸 볼륨을 약 80 % 줄입니다. 그래도이 작업을 수행해야합니다.
평판 : 평판 이 좋고 알려진 SMTP 서버를 통해 전자 메일을 보내는 사람이 야간 서버보다 합법적 일 수 있습니다. 평판을 얻기 위해 공급자는 다음과 같은 여러 가지 작업을 수행합니다.
동적 / 클라이언트 주소 차단 (100 %는 아니지만 많은 인터넷 청크가 매핑되었습니다).
리버스 DNS는 DNS와 일치합니다. 그렇게하기는 어렵지 않지만 일정 수준의 책임과 모범 사례에 대한 지식을 제공하며 많은 클라이언트 주소 블록에는 없습니다.
평판 : 다른 SMTP 서버와 통신 할 때 많은 공급자가 스팸 량과 전송 된 전자 메일 량을 추적하고 연결을 제한하고 이러한 매개 변수를 주시하여 스팸 량을 줄일 수 있습니다. (이 작업을 수행하는 방법에는 여러 가지가 있지만 모두 분명하지는 않지만 알려진 발신자가 필요합니다).
SPF 및 DKIM : 이러한 메커니즘은 DNS 리소스를 도메인 이름에 연결하여 메일을 위조하는 것을 어렵게 만들고 어렵습니다 (단, 메일 프로그램 (MUA)이 발신 메일을 담당하는 경우 배포 할 수는 없습니다). 이미 받아 들여진대로 완료하십시오. 크레딧에 대한 크레딧은 내 마음을 미끄러 뜨렸을 때 아래 포스터로 가야하지만 그럼에도 불구하고 매우 유효합니다)
다른 사소한 문제가있을 수 있지만 이것이 가장 큰 문제 일 것입니다.
메일을 보내려면 왜 중간 SMTP 서버가 필요합니까? 내 클라이언트 (Outlook, Thunderbird)가 수신자의 SMTP 도메인으로 직접 메시지를 보낼 수없는 이유는 무엇입니까?
1991 년, 그리고 대부분의 1990 년대 초와 심지어 초기에, 당신은 당신이 묘사 한 것을 할 수있을 것입니다. 그러나 2015 년의 현실은 기술적으로 메일 서비스가 설치된 모든 컴퓨터에서 기술적으로 전자 메일을 보낼 수있는 반면 SPAM의 세계는이 방법을 효과적으로 쓸모 없게 만들었습니다.
"실제"SMTP 서비스를 사용하는 경우 PTR 레코드, SPF 레코드 및 도메인 키와 같은 목적은 하나의 목적과 목적으로 만 설정됩니다. 메시지를 보내는 SMTP가 합법적임을 보증합니다. 그렇지 않다면? 메시지를 SPAM 폴더 또는 "큰 심연"삭제로 필터링하십시오. 각 항목의 내용은 다음과 같습니다.
PTR (포인터 레코드 / 역 DNS 레코드) : 서버 수준 확인. 여기 에 설명 된 대로 PTR 레코드는 네트워크 인터페이스 (IP)를 호스트 이름에 매핑하는 데 사용됩니다. 123.456.789.0SMTP 서버에 이메일을 보내는 주소가 있다면 smtp.example.com해당 PTR 레코드는 다음과 같습니다 smtp.example.com. 너무 단순 해 보이지만 실제로 PTR 레코드를 설정할 수있는 유일한 사람은 IP 주소의 소유자이고 하드웨어에서만 설정할 수 있기 때문에 작동합니다. 따라서 해당 IP 주소를 누가 소유 / 운영 / 관리하는지에 대한 검증 지점 역할을합니다.
SPF (Sender Policy Framework) : 호스트 이름 DNS 엔트리 레벨 확인. 여기에 설명 된 SPF 레코드 는 기본적으로 도메인 이름 보유자가 설정 한 DNS 레코드로서 해당 도메인 이름에 대한 전자 메일을 보낼 수있는 서버의 IP 주소 및 호스트 이름 목록을 제공합니다. SMTP 서버의 실제 도메인 이름 소유자 만 메일을 보낼 수 있도록하는 또 다른 확인 단계입니다. IP 주소를 가진 서버가에 대한 123.456.789.9이메일을 보내고 있다고 가정 해 보겠습니다 example.com. 우리 는 이미을 smtp.example.com사용 123.456.789.0하지만 SPF 레코드 항목에 대해 example.com“Hey! 123.456.789.9좋은 서버입니다! 그는 합법적입니다! 그의 이메일을 존중하십시오!”
DKIM (DomainKeys Identified Mail) : 전자 메일 메시지 수준 확인 여기 및 Wikipedia 에 설명 된 대로 “DKIM은 도메인에서 들어오는 메일이 해당 도메인의 관리자가 승인하고 전자 메일 (첨부 파일 포함)을 확인할 수있는 메커니즘을 제공하여 전자 메일 스푸핑을 탐지하도록 설계된 전자 메일 유효성 검사 시스템입니다. DKIM은 암호화 해시를 사용하여 메일 자체가 전송 중에 필터링되거나 변조되지 않았는지 확인합니다. 또한 "합법적입니까 아니면 스팸입니까?"체인의 또 다른 검증 지점 역할을합니다.
결국, 무엇이든 가치가있는 공개 SMTP 서버에는 SMTP 서버와 관련 전자 메일이 합법적인지 확인하기 위해 이러한 항목 중 두 개 이상 (PTR 및 SPF)이 설정됩니다. 모든 사람이 DKIM을 사용하는 것은 아니지만 SPAMmer가 SPAM을 전송하려는 노력에서 점점 더 강해짐에 따라 요즘 점점 인기를 얻고있는 또 다른 검증 계층입니다.
대부분의 가정용 ISP는 스팸 네트워크에 참여하지 못하도록 TCP 포트 25 (SMTP)를 차단합니다. PC가 감염되면 PC는 다른 사람의 요청에 따라 스팸을 발산 할 수 있습니다.
다른 답변은 모두 우수하며 스팸은 그와 관련이 있습니다.
그러나 실제로 더 단순하고 더 일반적인 답변이 있습니다. SMTP를 통해 이메일을 보내는 것은 실제로 매우 복잡한 작업입니다. 스팸이 없어도 모든 이메일 클라이언트에서 SMTP 프로토콜의 전체 기능 세트를 구현하고 싶지는 않습니다. 전용 소프트웨어를 사용하는 것이 좋습니다 (Sendmail, postfix 등은 * nix 세계에서는 큰 것이며 Windows 세계에서는 Exchange입니다).
예를 들어, 가장 기본적인 경우라도 "실제"SMTP 서버는 최소한 MX 레코드를 확인할 수 있어야합니다. 그런 다음 기능을 협상해야합니다 (대부분 TLS이지만 다른 기능도 있습니다). 재시도 대기열, 비 배달 보고서 생성 등을 관리해야합니다.
이는 서버가 작동하지 않는 기본적인 필수 기능입니다. 주소 재 작성, 메일러 테이블과 같은 것도 포함하지 않습니다. sendmail 등 UUCP와 같이 지원하는 수십 가지 프로토콜은 말할 것도 없습니다.
Outlook, Thunderbird 등의 SMTP 구현은 최소한으로, sendmail에서 스마트 호스트를 사용하는 것과 거의 같습니다.
관련이 있지만 별도의 문제 : 전자 메일은 보안에 매우 민감한 주제이므로 각 데스크톱에 잠재적으로 수백 또는 수천 개의 개별 서버 대신 하나 이상의 중앙 관리 서버가 전자 메일을 처리하도록 할 수 있습니다.
메일을 보내려면 왜 중간 SMTP 서버가 필요합니까? 내 클라이언트 (Outlook, Thunderbird)가 수신자의 SMTP 도메인으로 직접 메시지를 보낼 수없는 이유는 무엇입니까?
이 작업을 수행하는 전자 메일 프로그램을 만들 수 있으며 다른 사람들도 이전에 전자 메일 프로그램을 수행했거나 시도한 것 같습니다.
기본적으로 MUA (메일 사용자 에이전트) 및 MTA (메일 전송 에이전트) 도구를 하나로 작성해야합니다.
MTA가 "서버 쪽"에있는 MTA를 사용하여이 도구를 전통적으로 다른 도구로 분리 한 이유는 개방형 인터넷을 통해 메일을 보내는 MTA가 쓰기 및 구성이 훨씬 더 복잡하기 때문입니다. 안정적인 "항상 켜져있는"서버.
MTA는 다음을 수행해야합니다.
신뢰할 수 없거나 잘못 작동 할 수있는 서버를 찾아 연결하고 메일을 잃지 않는 합리적인 방법으로 오류 조건을 처리합니다.
다운 된 서버를 처리하고 대체 서버로 라우팅하거나 나중에 다시 시도 할 수 있도록 메일을 대기시킵니다. 이것은 인터넷에 "항상 연결되어있는"서버 프로세스에서 가장 잘 실행됩니다. 또한 메일 전송 에이전트에 대기중인 메일에 대한 자체 저장 영역이 필요하다는 것을 의미합니다.
다양한 서버 기능을 처리하고 수신 서버의 기능에 따라 동작을 조정하십시오.
메일이 유실되지 않도록 오류 상태 또는 메일을 전달할 수없는 경우에 대해 사용자에게 다시보고하십시오.
탁월한 보안 관행을 가지고 있으며 보안에 매우 중점을 둡니다.
이상적으로는 안정적인 IP 주소와 역방향 DNS 항목 (공용 서버에 적합한 인터넷 연결)이있는 항상 연결되어있는 안정적인 서버에 상주하십시오. 이것은 다른 시스템이 스팸으로 보낸 메일을 탐지하지 못하게합니다.
이러한 요구 사항을 감안할 때 SMTP 서버를 공용 서버에 항상 배치하고 해당 작업을 수행하는 데 적합한 도구를 사용하는 것이 좋습니다.
고려해야 할 또 다른 사항은 회신 이메일을받는 것 입니다. 최소한 모든 발신 전자 메일에는 응답을 보낼 수있는 FROM 주소 (알 수없는 사용자, 휴가 회신 등)가 있습니다. 반송 주소를 확인하려면 반송받은 편지함 위치를 가리키는 MX 레코드가 있어야합니다. 고정 IP 주소가 항상 켜져있는 컴퓨터에서 이메일을 보내지 않는 한 이러한 인바운드 메시지를 처리하려면 서버가 필요합니다. 이것은 일반적으로 동일한 서비스에 의해 처리되지만 항상 그런 것은 아닙니다.
GMail, Outlook 365 및 Yahoo Mail은 이메일을 보내는 개인이 사용하는 이메일 서비스의 예입니다. 상업용 전자 메일 전송에는 회사에 대량 전자 메일을 보내고 바운스, 스로틀 및 배달 가능성과 같은 항목을 처리하는 데 유용한 MailChimp, Marketo 및 Eloqua와 같은 서비스가 있습니다.