집에 개인 메일/캘린더 서버를 구축하려고 합니다(네, 어렵다고, 손이 많이 간다는 등의 말을 들었지만 그래도 시도해 보고 싶습니다). 고정 IP 주소를 제공하지 않는 ISP가 있으므로 일종의 DDNS(동적 도메인 이름 서비스)가 해결책인 것 같습니다.
그러나 저는 조사를 해왔고 DDNS를 직접 수행할 수 있음을 설명하는 온라인 리소스를 최소한 두어 개 발견했습니다. IP 주소를 주기적으로 모니터링하고 주소가 변경되는 경우 스크립트/프로그램이 필요합니다. , 그런 다음 스크립트/앱은 홈 서버에 사용 중인 도메인 이름을 업데이트해야 합니다. 만약의 경우를 대비해 호스팅 제공업체에 도메인을 파킹해 두었는데, 제가 이해한 바로는 API 키만 있으면 됩니다. 필요한 도메인/IP 레코드를 프로그래밍 방식으로 조정하기 위해 호스팅 회사에 문의합니다. 내가 틀렸다면 누군가 알려 주시고 더 간단한 방법이 있습니다.
문제는 다음과 같습니다. 위에서 설명한 방식으로 도메인 이름 레코드를 업데이트하면 시스템/세계 전체에 전파하는 데 몇 시간이 걸릴 수 있다는 내용을 읽었습니다(모든 DNS 서버는 업데이트된 주소로 다시 채워야 합니다). ). 그러나 제가 살펴본 여러 유료 DDNS 제공업체에서는 변경 사항이 거의 즉각적으로(또는 적어도 내 DIY 방법보다 더 빠르게) 적용되도록 하는 능력을 홍보하는 것 같습니다. 그게 사실인가요? 내가 놓친 것이 있나요?
또한, 또 다른 우려 사항이 있습니다. DDNS 공급자가 있을 때 간과할 수 있는 보안 문제가 있습니까? 그들이 제공하는 도메인 이름을 통해 흐르는 모든 트래픽을 모니터링할 수는 없을까요? 어떤 방법(유료 vs. DIY)이 더 나을지 의견을 갖고 있는 사람이 있나요?
시간을 내주셔서 감사합니다...감사합니다!
답변1
집에 개인 메일/캘린더 서버를 구축하려고 합니다(네, 어렵다고, 손이 많이 간다는 등의 말을 들었지만 그래도 시도해 보고 싶습니다).
아마도 메일 부분에서는 운이 별로 없을 것입니다. @Alex의 답변을 참조하십시오.
IP 주소를 주기적으로 모니터링하는 스크립트/프로그램이 있어야 하며, 주소가 변경되면 스크립트/앱은 홈 서버에 사용 중인 모든 도메인 이름을 업데이트해야 합니다.
꽤 그렇죠.
필요한 도메인/IP 레코드를 프로그래밍 방식으로 조정하려면 호스팅 회사의 API 키가 필요합니다.
예, 하지만 회사가 일반적인 "모든 것을 호스팅"하는 서비스만 제공하는 경우에는 DNS 관리 API가 전혀 없을 수 있으며(대신 웹 및 메일에 중점을 두고) 도메인을 다른 곳으로 이동해야 할 수도 있습니다.
문제는 다음과 같습니다. 위에서 설명한 방식으로 도메인 이름 레코드를 업데이트하면 시스템/세계 전체에 전파하는 데 몇 시간이 걸릴 수 있다는 내용을 읽었습니다(모든 DNS 서버는 업데이트된 주소로 다시 채워야 합니다). ).
아니요. DNS 호스팅 공급자의 자체 시스템만 업데이트하면 됩니다. 나머지 세계에서는 영구적인 기록을 보관하지 않습니다. 각 (하위)도메인의 "TTL"(Time To Live) 필드에 표시된 기간 동안 개별 조회 결과를 캐시할 뿐입니다.
그러나 제가 살펴본 여러 유료 DDNS 제공업체에서는 변경 사항이 거의 즉각적으로(또는 적어도 내 DIY 방법보다 더 빠르게) 적용되도록 하는 능력을 홍보하는 것 같습니다. 그게 사실인가요? 내가 놓친 것이 있나요?
나는 그들이 동적 도메인에서 매우 낮은 TTL(최소 몇 초)을 구성할 수 있다고 추측합니다. 즉, DDNS 제공자 자체가 더 많은 요청을 받는 대신 모든 캐시에서 매우 빠르게 삭제될 것임을 의미합니다(더 높은 DNS 서버와 데이터베이스에 부하를 주며 더 많은 비용을 청구할 핑계가 됩니다.) 그것만으로는 특별한 것이 아니며 어떤 DIY 방법으로도 구현할 수 있습니다.
그들이 제공하는 도메인 이름을 통해 흐르는 모든 트래픽을 모니터링할 수는 없을까요?
아니요. DNS 서버는 주소(전화번호부와 유사)만 제공하며 추가 통신에는 관여하지 않습니다.
(제공자가 실제로 시도하지 않는 한잘못된 데이터를 반환, 뉴스 웹사이트에서 이에 대해 알게 되는 순간 회사의 TTL이 상당히 단축됩니다.)
즉, API 작동 방식에 주의를 기울이십시오. 물론 서비스에 취약점이 없다고 확신할 수는 없지만, (예를 들어) API가 암호화되지 않은 HTTP를 통해 실행되고 API 키를 눈에 띄게 전송한다면 이는 신뢰할 수 있는 것이 아닙니다.
답변2
고정 IP가 없으면 DDNS 솔루션을 사용하는 경우 메일 서버를 잊어야 합니다. 대부분의 이메일 서버는 모든 동적 IP가 포함되어 있으므로 이메일을 거부하거나 스팸 수준이 가장 높은 이메일에 태그를 지정합니다.PBL기울기. (주거용 IP에 이메일 서버를 두는 것이 좋지 않은 이유에 대한 자세한 내용은 PS 섹션에서 확인할 수 있지만, 중간 저렴한 VPS(가상 사설 서버)를 사용하여 해결 방법이 여전히 있습니다.)
"DDNS yourself"(API를 통해 무료 IP 업데이트를 제공하는 좋은 도메인 등록 기관)와 관련하여 프로그램에서 해야 할 일은 주기적으로 공용 IP를 확인하고 변경된 경우 A(AAAA) 레코드를 업데이트할 등록 기관에 새 IP를 보내는 것입니다. 그런데, 요즘 대부분의 라우터에는 이미 이러한 기능이 있습니다(IP를 감시하고 DDNS 공급자에게 보고).
시스템/세계 전체에 전파하는 데 몇 시간이 걸릴 수 있다는 내용을 읽었습니다.
DNS 제공업체에 따라 다르지만, 존경받는 등록기관에서는 TTL(IP 변경 빈도를 다른 사람에게 알리는 시간)을 5분으로 설정할 수 있습니다. 높은 로딩을 피하기 위해 모든 전달 중간 DNS 서버가 이를 따르는 것은 아니지만 일반적으로 도메인 소유자 TTL을 따르지 않더라도 몇 시간 이상 지속되는 경우는 거의 없습니다. 대부분의 전달자는 도메인 TTL에 설정한 대로 캐시를 업데이트합니다.
DDNS 공급자가 있을 때 간과할 수 있는 보안 문제가 있습니까?
온라인에 접속하면 이미 보안 문제가 발생할 수 있습니다. 반갑지 않은 손님을 피하기 위해 서버를 로컬 네트워크에서 격리하십시오.
어떤 방법(유료 vs. DIY)이 더 나을지 의견을 갖고 있는 사람이 있나요?
DDNS를 사용한다면 시간과 돈을 허비하게 될 것입니다. 요즘에는 한 달에 3~4달러에 괜찮은 VPS(가상 사설 서버)를 얻을 수 있습니다. 일반적으로 많은 공간을 차지하지 않기 때문에 웹 사이트(만약 갖고 있는 경우)를 VPS에서 직접 호스팅할 수 있지만, 서버를 오랫동안 실행하거나 많은 양의 서버를 실행할 것으로 예상되는 경우 이메일 서버가 문제가 될 수 있습니다. 이메일. 일반적으로 20GB의 공간은 오래된 이메일을 삭제하지 않고도 최대 3~5년 동안 중소기업에 충분합니다. 엄청난 양의 이메일이 예상되더라도 nginx집으로 이메일 트래픽을 프록시하는 기능을 사용할 수 있습니다. 따라서 집에서 동적 IP로 기본 이메일 서버를 호스팅할 수 있으며 VPS(고정 IP 포함)는 집으로 들어오고 나가는 트래픽을 프록시 처리합니다. DNS 전파에 대해 걱정할 필요가 없고 도메인은 항상 VPS의 고정 IP를 가리키므로 이러한 구성에서 자신의 VPS를 어려움 없이 사용할 수 있습니다. VPS가 트래픽을 프록시할 위치를 알 수 있도록 VPS에 대한 홈 IP 변경 보고를 관리해야 하지만 훨씬 쉽습니다. VPS에서 일부 URL을 쿼리하고 들어오는 IP 로그를 구문 분석하고 nginx를 조정하면 항상 알 수 있습니다. 당신은 어디에 있습니다.
추신
이 주제는 슈퍼유저에게 흥미로울 것 같아서 좀 더 자세한 내용을 추가하겠습니다.
PBL목록은 일반적으로 동적 IP인 IP 데이터베이스를 보유하므로PBL 이메일 서버 운영자에게 많은 도움이 됩니다. 동적 IP에서 이메일 서버를 허용하지 않는 것은 기술적인 문제이거나 ISP가 악당이 아닙니다. 문제는 동적 IP의 대부분의 이메일 트래픽이 쉽게 감염될 수 있는 엄청난 양의 스팸이나 맬웨어를 보내는 감염된 컴퓨터에서 나온다는 것입니다.DDoS대상인 경우 수신 서버입니다. 일부 ISP는 맬웨어 확산을 방지하기 위해 포트 25로 나가는 연결을 차단하고DDoS, 그러나 일부는 그렇지 않습니다. 실제로 모든 회사 이메일 서버는 단순히 다음에서 오는 연결을 끊습니다.PBL스팸을 크게 줄여주는 목록입니다.
두 번째 효과적인 스팸 방지 솔루션은 DNS에 역방향 PTR 레코드가 없고 도메인의 DNS 레코드와 일치하지 않는 IP에서 연결을 삭제하는 것입니다. PTR 기록이 없는 고정 IP에서 연결이 발생하더라도 일반적으로 설정이 잘못 구성되었거나 대부분 스팸 갱이 실행하는 서버에서 발생합니다(일부 대규모(그러나 부주의한) 공급자에 대한 제외가 있을 수 있지만 수동으로 추가할 수 있음) 화이트리스트에 있음). VPS에서 역방향 PTR 기록을 설정하는 데는 몇 분밖에 걸리지 않지만, ISP에서 얻은 고정 IP와 PTR 설정 프로세스가 일반적으로 PITA인 경우는 그렇지 않습니다(전화해서 확인 후 티켓을 제출해야 함). IP의 원래 소유자이며 때로는 몇 시간, 때로는 며칠 내에 역방향 PTR 레코드를 설정해야 하는 시스템 관리자의 자비를 기다립니다.)
또한, 중요하지는 않지만... 이메일 위조를 방지하기 위해 대부분의 이메일 서버 소유자는 소위SPF(발신자 정책 프레임워크) 도메인을 대신하여 이메일을 보낼 수 있는 DNS 인증 IP 주소를 설정하면 가장 빠른 정책 처리 방법을 지정할 수 있습니다. (인증된 서버를 다음과 같이 지정할 수 있습니다.FQDNMX 레코드를 참조하지만 서버 연결을 위해 DNS를 통한 추가 왕복이 필요합니다) 따라서 DNS에서 유동 IP를 관리하는 것은 재미가 없을 것입니다.
답변3
고정 IP 주소를 제공하지 않는 ISP가 있으므로 일종의 DDNS(동적 도메인 이름 서비스)가 해결책인 것 같습니다.
그것이 하나의 해결책입니다. 또 다른 솔루션의 예로 HurricaneElectric.net IPv6 터널은 이동 가능한 터널 끝점과 함께 고정(IPv6) 주소를 제공합니다. 물론 현재로서는 IPv4가 일반 대중을 대상으로 이러한 기능을 지원하는 것이 더 좋을 것입니다. 그러나 협력할 의사가 있는 컴퓨터를 찾을 수 있다면 기술적으로 IPv4에서도 그러한 기능을 수행할 수 있습니다.
IP 주소를 주기적으로 모니터링하는 스크립트/프로그램이 있어야 하며, 주소가 변경되면 스크립트/앱은 사용 중인 도메인 이름을 업데이트해야 합니다.
이는 기술적으로 탄탄한 계획처럼 들립니다.
필요한 도메인/IP 레코드를 프로그래밍 방식으로 조정하려면 호스팅 회사의 API 키가 필요합니다. 내가 틀렸다면 누군가 알려 주시고 더 간단한 방법이 있습니다.
정확한 세부 사항은 도메인 이름 등록 기관이 이 기능을 구현하는 방법을 어떻게 선택하느냐에 따라 달라집니다. 일부는 일종의 API 키를 사용할 수도 있고, 다른 일부는 자동 업데이트를 위해 웹 인터페이스를 사용할 수도 있습니다. 예전에는 일부 ISP가 이러한 서비스를 제공했지만 요청에 대한 응답으로 수동 변경에 의존했습니다. 따라서 이는 전적으로 귀하에게 서비스를 제공하는 사람에게 달려 있습니다.
문제는 다음과 같습니다. 위에서 설명한 방식으로 도메인 이름 레코드를 업데이트하면 시스템/세계 전체에 전파하는 데 몇 시간이 걸릴 수 있다는 내용을 읽었습니다(모든 DNS 서버는 업데이트된 주소로 다시 채워야 합니다). ).
바하 사기꾼. DNS 전파에는 몇 분, 몇 시간 또는 며칠(예: 72시간)이 걸리는 것으로 알려져 있습니다. 그러나 사람들이 사물을 면밀히 분석한 결과, 그 모호한 "전파" 시간의 대부분은 단지 DNS 호스팅 공급자의 업데이트 속도가 느리기 때문에 발생했다는 사실을 발견했습니다.
더 나은 이론에서는 TTL 값을 기다려야 합니다. 하지만 그 이론에는 문제가 있습니다 ...
그러나 제가 살펴본 여러 유료 DDNS 제공업체에서는 변경 사항이 거의 즉각적으로(또는 적어도 내 DIY 방법보다 더 빠르게) 적용되도록 하는 능력을 홍보하는 것 같습니다. 그게 사실인가요? 내가 놓친 것이 있나요?
좋습니다. 현실은 다음과 같습니다. 업데이트를 완전히 적용하려면 인터넷에서 이전 정보의 활성 캐시를 플러시해야 합니다.
표준에 따르면 캐싱 DNS 서버는 구성할 수 있는 TTL 값으로 지정된 시간 동안 캐시에 의존할 수 있습니다.
그러나 현실은 TTL 값을 완전히 무시하는 것으로 알려진 자체 캐싱 DNS 서버를 실행하는 것으로 알려진 대규모 ISP 중 적어도 일부(그리고 어쩌면 대부분?)가 있다는 것입니다. 그들은 DNS 캐시를 덜 자주 업데이트하면 전반적인 효과가 대역폭이 줄어들고 컴퓨팅 시간도 줄어들 것이라고 느끼기 때문에 이렇게 합니다.
따라서 이러한 DNS 서버에 의존하는 모든 전자 메일 서버가 영향을 받을 수 있으며 DNS 서버가 업데이트될 때까지 업데이트를 알 수 없습니다. 어떤 경우에는 하루나 이틀(또는 삼일?)이 걸릴 수도 있습니다.
그러나 그러한 효과는 점점 더 드물어졌습니다. 실제로 대부분의 DNS 서버는 한두 시간 내에 캐시를 플러시합니다.
일부 캐시는 다른 캐시만큼 빨리 업데이트되지 않기 때문에 인터넷의 일부 장소에서는 새 주소를 사용하는 반면 다른 장소에서는 여전히 이전 주소를 사용하려고 시도하게 됩니다. 몇 시간 안에 대부분의 컴퓨터는 새로운 정보를 가지고 잘 작동할 것입니다. (대부분의 경우 몇 분 내에 작동할 수 있습니다.)
이메일 소프트웨어의 일반적인 동작은 이메일 전송을 시도하는 것입니다. 실패하면 나중에 다시 시도하세요. 전자 메일 서버는 일반적으로 포기하기 전까지 며칠 동안 계속 재시도합니다(약 한 시간에 한 번 정도). 따라서 이메일이 손실되지는 않지만 약간 지연될 가능성이 높습니다.
"모든 동적 IP가 PBL 목록에 있습니다"라는 Alex의 의견은 분명히 잘못된 것입니다. 이 정보는 분산되어 있기 때문입니다(따라서 "모두"라는 단어는 정확하지 않습니다). 그러나 많은 동적 IP가 그러한 목록에 있다는 것은 사실입니다. 이는 이메일과 관련된 일부 컴퓨터/장치가 귀하와 협력하지 않기로 결정할 수 있음을 의미합니다.
또한, 또 다른 우려 사항이 있습니다. DDNS 공급자가 있을 때 간과할 수 있는 보안 문제가 있습니까?
가장 큰 관심사는 업데이트가 안전한 방식으로 처리되는지 여부입니다.
그들이 제공하는 도메인 이름을 통해 흐르는 모든 트래픽을 모니터링할 수는 없을까요?
아니요. DNS 서버의 임무는 도메인 이름에 대한 요청을 받고 응답을 제공하는 것입니다. 전통적인 일반적인 응답은 하나 이상의 IP 주소를 제공하는 것입니다. 다른 DNS 서버나 도메인 이름(예: CNAME 사용) 또는 기타 데이터(예: 최신 DNSSec 표준을 통해 보안 제공에 도움)를 참조하는 등의 다른 응답도 가능합니다.
혹시 의견이 있으신 분 계시나요...
정말로 진지한 이메일 서버를 운영하고 싶다면 최신 이메일 표준을 준수하는 것을 고려해 볼 수 있다는 점을 지적하고 싶습니다. 여기에는 단순히 SMTP 및 DNS 기술 사양을 준수하는 것 이상이 포함됩니다. 많은 사람들이 대규모 공급자를 이용하며 이러한 대규모 공급자는 자신의 기대치를 구현할 수 있습니다.
예를 들어, 나는 몇 년 전에 Debian과 Postgrey로 설정된 이메일 서버를 알고 있습니다. Postgrey는 "그레이리스팅" 스팸 방지 처리 기능을 제공하는 일부 소프트웨어입니다. 그러나 사용되는 Postgrey 버전에서는 전자 메일 서버가 전자 메일을 다시 시도할 때 보내는 전자 메일 서버가 동일한 IP 주소를 사용한다고 가정합니다. Office 365 전자 메일 서버는 여전히 IPv6/64 서브넷 내에 있는 다른 IP 주소에서 전자 메일 보내기를 다시 시도하는 것으로 알려져 있습니다. 포스트그레이는 그것을 좋아하지 않습니다.
점점 더 많은 조직이 Office 365로 전환함에 따라 이는 기존 전자 메일 서버를 사용하는 사람들에게 점점 더 많은 문제가 되고 있습니다. Postgrey 소프트웨어의 최신 버전이 출시되었지만 이러한 소프트웨어를 설치하는 쉬운 방법은 해당 운영 체제의 공식 소프트웨어 저장소를 사용하는 것입니다. 따라서 실제로 해당 소프트웨어를 업데이트하는 현명한 방법은 운영 체제를 업그레이드하는 것입니다.
"mail"로 시작하는 DNS 이름을 갖는 것과 같은 다른 규칙도 있습니다. 이로 인해 설정이 어느 정도 신뢰할 수 있는 것으로 판단될 수 있습니다. 이는 장치가 귀하를 비준수 스패머로 취급하는지, 아니면 통신할 가치가 있는 장치로 취급하는지에 영향을 미칠 수 있습니다.
물론, 공식 기술 사양에 대해 매우 엄격하게 말하면 거대 조직에서는 사용되는 프로토콜의 기술 사양이 포함된 RFC 문서에서 요구하는 최소 요구 사항과 다른 일부 작업을 수행하고 있을 수도 있습니다. 그러나 더 큰 규모의 인터넷 커뮤니티와 통신하려는 경우 일부 주요/대형 플레이어가 부과하는 몇 가지 추가 표준이 있습니다. 이러한 기준을 잘 충족할 준비를 하세요. 그렇지 않으면 문제에 직면할 수도 있습니다.
시간이 지남에 따라 변경될 수 있기 때문에 이러한 모든 표준이 정확히 무엇인지에 대해서는 약간 모호합니다.
기존 데비안 운영 체제를 업그레이드해야 하는 기존 전자 메일 서버와 관련하여 어쨌든 사람들은 운영 체제를 더 자주 업그레이드해야 할 것입니다. 하지만 내가 말하려는 요점은 많은 전자 메일 주소에서 일반적으로 사용되는 새로운 동작으로 인해 수년 동안 완벽하게 작동했던 소프트웨어 설정이 이제 손상되었다는 것입니다. 속도가 느린 인터넷 제공업체에서 동적 DNS를 사용하는 등 특이한 작업을 시도하는 경우 그 과정에서 몇 가지 추가 문제가 발생할 가능성이 더 높습니다. 당신이 야심차게 들린다면, 아마도 당신은 그것에 노력을 투자할 수 있을 것입니다. 나는 단지 당신이 그렇게 할 필요가 있다는 것을 준비하라고 경고하는 것뿐입니다.
... 어떤 방법(유료와 DIY)이 더 나을까요?
다른 사람들이 지적했듯이 유료는 훨씬 쉬울 것이며 대부분의 사람들에게 매우 경제적입니다. 대규모 제공은 MX 레코드가 가리키는(이메일이 그곳으로 이동하도록) 안정적인 IP 주소를 제공할 가능성이 높으며 특히 더 나은 대역폭을 제공할 수 있습니다.
DIY는 경험을 쌓고 사물이 어떻게 작동하는지 배우고 대기업의 구현에만 의존하지 않기로 결정하는 데 더 좋습니다. 구현을 더 효과적으로 제어할 수 있으면 훨씬 더 빠르게 중요한 사용자 정의 변경을 수행할 수 있습니다.
어느 것이 "더 나은지"는 개인의 목표에 따라 다르므로 결론은 귀하에게 맡기겠습니다.
답변4
다른 답변에서는 이미 DDNS 부분을 설명했습니다.
내가 설명할게왜이메일을 보내려면 별도의 서버를 사용해야 합니다(@Alex의 간단한 설명이 불완전하므로).
가장 중요한 것은 이메일을 보내려면 유효한 역방향 PTR 레코드가 필요하다는 것입니다. IP 주소에 대한 역방향 DNS 레코드가 보낸 사람 도메인과 일치하지 않으면 많은 이메일 서버가 이를 확인하고 메일을 반송합니다. 이 기록은 IP 주소 소유자(예: ISP)가 제공합니다.
이제 어떻게든 유효하고 동적으로 역방향 DNS를 업데이트했다고 상상해 봅시다(하하). 귀하의 도메인이 합법적이고 보내는 이메일이 스팸이 아니라는 점을 모든 사람에게 확신시켜야 합니다.
@Alex가 설명했듯이 소규모 메일 호스팅 업체는 스팸하우스 및 기타 온라인 블랙리스트를 사용하는 것을 좋아합니다. 그러나 나는 그 기업 관리자들이 다른 멍청한 일들(Gmail/Hotmail에서 오지 않는 모든 이메일을 차단하는 것과 같은)을 많이 하는 것을 보았습니다. 실제로는 일부 "기업 관리자"만이 아닙니다.소스포지합법적인 회사 이메일 도메인의 등록을 차단합니다. "우리는 이유를 모르지만 스팸 필터에서는 귀하가 나쁜 사람이라고 생각하기 때문입니다." 그냥 무시하세요. 하늘 아래 모든 사람과 조화를 이룰 수는 없습니다.
요즘 대규모 메일 호스팅 업체는 스팸하우스나 기타 PBL에 의존하지 않습니다. 그들은 귀하의 신뢰성을 스스로 추적합니다. 발신자 평판(적어도 대부분)은 IP에 연결됩니다. 스패머는 종종 호스팅 업체로부터 부팅을 받기 때문에 강제로 IP를 점프해야 하기 때문입니다. Gmail의 관점에서 최근 생성된 도메인/IP는 일반적인 스패머와 다르지 않습니다. 이메일을 보내기 시작하면 평판이 낮아집니다(기본적으로 스팸 발송자로 처리됩니다!). 보내는 이메일의 대부분은 스팸으로 표시됩니다. 누군가가 귀하의 이메일에 답장하거나 특히 해당 이메일을 합법적인 것으로 표시하면(이메일 제공업체의 웹 인터페이스에서 해당 버튼을 눌러) 귀하에 대한 신뢰가 약간 높아질 것입니다. 보시다시피 발신자 평판을 높이려면 수년에 걸쳐 동일한 IP에서 동일한 도메인을 사용해야 합니다. 동적 IP로는 안정적으로 수행할 수 없습니다.
호스터로부터 VPS를 임대하면 홈 서버를 동적 IP로 유지하는 것이 훨씬 쉬워집니다. TTL이 매우 낮은 VPS를 자체 DDNS 서버로 사용할 수 있습니다. DNS를 포기하고 다른 수단(예: HTTP 리디렉션)을 사용하여 홈 박스의 IP 변경을 처리할 수도 있습니다. 홈 IP가 다운되었거나 최근 변경된 경우 선택적으로 VPS로 대체하여 홈 박스로 직접 이메일을 받을 수 있습니다.