메일 클라이언트, SMTP 서버 및 전체 온라인 메일 시스템이 작동하는 방식에 대해 더 많이 알게되면 중간 SMTP 서버가 필요한 이유가 궁금 할 수 있습니다. 이를 염두에두고 오늘의 수퍼 유저 Q & A 게시물에는 호기심 많은 독자의 질문에 대한 답변이 있습니다.
오늘의 질문 및 답변 세션은 커뮤니티 중심의 Q & A 웹 사이트 그룹 인 Stack Exchange의 하위 부문 인 SuperUser가 제공 한 것입니다.
사진 제공 : David Schroeder (Flickr) .
질문
수퍼 유저 독자 Tobia는 메일을 보내기 위해 중간 SMTP 서버가 필요한 이유를 알고 싶어합니다.
메일을 보내기 위해 중간 SMTP 서버가 필요한 이유는 무엇입니까? 내 메일 클라이언트 (Outlook 또는 Thunderbird)가 수신자의 SMTP 도메인에 직접 메시지를 보낼 수없는 이유는 무엇입니까?
예를 들어 다음 주소로 메일을 보내야하는 경우 [email protected] 내 Gmail 계정을 사용하여 smtp.gmail.com 섬기는 사람; 이 서버는 내 메시지를 MX 서버로 보냅니다. example.com .
메일을 보내는 데 중간 SMTP 서버가 필요한 이유는 무엇입니까?
대답
수퍼 유저 기여자 인 davidgo가 우리에게 답을 제공합니다.
기술적으로는 컴퓨터에서받는 사람의 SMTP 서버로 직접 메일을 보낼 수 있습니다.
기록 기준으로 살펴보면 원격 SMTP 서버가 다운 된 경우 시스템이 자동으로이를 처리하고 계속 재 시도하기를 원하므로 SMTP 서버가 있습니다. 마찬가지로 예전에는 모든 메일 서버가 항상 연결되지 않았기 때문에 (장거리 링크는 비용이 많이 들었습니다) 링크가 설정되면 메일이 대기열에 추가되고 전송되었습니다.
인터넷 서비스가 저렴한 곳으로 넘어가더라도 서버를 사용할 수없는 경우 메일을 다시 보낼 수있는 메커니즘이 있으면 여전히 유용합니다. 이 기능을 MUA (메일 사용자 에이전트 / 최종 사용자 메일 프로그램)에 기록하는 것은 이상적이지 않습니다. 이러한 기능은 MTA (메일 서버 / SMTP 서버)에 적합합니다.
하지만 스패머는 더욱 악화됩니다. 대부분의 메일 (80 % 이상)은 스팸입니다. 메일 공급자는이 문제를 줄이기 위해 최선을 다하고 있으며 많은 기술을 통해 메일 전달 방식을 가정합니다. 다음은 중요한 고려 사항입니다.
1. 그레이 리스팅 : 일부 공급자는 보낸 사람과받는 사람이 이전에 통신하지 않은 경우 자동으로 메일 연결을 끊고 두 번째 시도를 기대합니다. 스팸 발송자는 SMTP 서버가 항상 사용하는 동안 재 시도하지 않는 경우가 많습니다. 이렇게하면 스팸의 양이 약 80 % 감소하지만이 작업을 수행해야하는 것은 짜증납니다.
2. 평판: 평판이 좋고 알려진 SMTP 서버를 통해 메일을 보내는 사람이 날아 다니는 서버에 비해 합법적 일 가능성이 훨씬 더 높습니다. 평판에 대한 느낌을 얻기 위해 공급자는 다음과 같은 여러 가지 작업을 수행합니다.
- 동적 / 클라이언트 주소를 차단합니다 (100 %는 아니지만 인터넷의 큰 청크가 매핑 됨).
- 역방향 DNS가 정방향 DNS와 일치하는지 확인하십시오. 별로 어렵지는 않지만 모범 사례에 대한 어느 정도의 책임과 지식을 보여줍니다 (많은 클라이언트 주소 블록에없는 것).
- 평판을 확인하십시오. 다른 SMTP 서버와 통신 할 때 많은 공급자가 스팸의 양과 전송 된 메일의 양을 추적합니다. 연결을 제한하고 이러한 매개 변수를 주시하여 스팸의 양을 줄일 수 있습니다. 이 작업을 수행하는 방법에는 여러 가지가 있으며 모두 명확하지는 않지만 알려진 보낸 사람이 필요합니다.
- SPF 및 DKIM. 이러한 메커니즘은 DNS 리소스를 도메인 이름에 연결하여 메일 위조를 어렵게 만들고 어렵지만 메일 프로그램 (MUA)이 보내는 메일을 담당하는 경우 배포가 반드시 불가능하지는 않습니다.
아마도 다른 사소한 문제가있을 수 있지만 이것이 주요 문제 일 것입니다.
설명에 추가 할 것이 있습니까? 댓글에서 소리를 내십시오. 기술에 정통한 다른 Stack Exchange 사용자의 답변을 더 읽고 싶으신가요? 여기에서 전체 토론 스레드를 확인하십시오. .
