전달 메일 서버에 SRS 재 작성이 절대적으로 필요합니까?

내 도메인의 Postfix 이메일 서버를 운영하고 있습니다 (예 : mydomain.com). 대부분 전자 메일 전달 서버 역할을합니다. 사용자는 전자 메일 주소 @ mydomain.com을 받지만 일반적으로 외부받은 편지함 (Gmail, Yahoo 등)으로 주소를 전달하도록 선택합니다. 수천 개의 주소가 전달되므로 서버는 상당히 많은 양의 메일 트래픽을 처리합니다.

과거에는 서버가 SRS 재 작성을 사용하지 않았습니다. 이것은 물론 IP 주소가 원래 발신자의 도메인을 대신하여 이메일을 보낼 수있는 기술적 인 권한이 없기 때문에 전달 된 메일이 SPF 검사에 실패한다는 것을 의미했습니다. 그러나 내가 볼 수있는 것에서 중요한 문제는 발생하지 않는 것 같습니다. 일반적으로 Gmail, Yahoo 등의 사용자 불만은 SPF 실패를 무시하고 메시지를 전달할만큼 똑똑하지 않은 것 같습니다.

이를 염두에두고 SRS 재 작성을 활성화해야합니까? 스팸을 활성화하는 것을 고려하고 있지만 주된 관심사는 스팸이 불가피하게 전달 될 때 스팸을 보내기 위해 도메인이 블랙리스트에 추가된다는 것입니다. 다시 쓰면 스팸의 발신자 인 것처럼 보이지 않습니까? (적어도 이것은 메일 서버 전달을위한 Gmail 모범 사례를 읽음으로써 이해 한 것입니다 ).

물론 스팸 발송을 사용하기 전에 SpamAssassin을 사용하여 의심되는 스팸의 제목 줄에 "SPAM"을 추가하거나 높은 신뢰도 (Score 15+) 스팸을 전달하지 않고 스팸 소거 차단 목록을 사용하는 등의 권장 예방 조치를 이미 취하고 있지만 이러한 조치는 적용되지 않습니다. 완벽하지는 않으며 스팸은 여전히 ​​표시되지 않은 상태로 빠져들 수 있습니다.

스패머로 잘못 표시 될 위험이 증가 할 경우 SRS 재 작성을 사용할 수 있습니까? 아니면 그대로두고 SPF 실패를 무시하는 것이 더 안전한가요?

귀하의 질문으로 귀결되는 것은 " 수신 전자 메일의 SPF 레코드를 확인하는 메일 서버 는 몇 개입니까? "입니다. 대부분의 경우 SRS는 전달 서버에 대한 절대 요구 사항입니다. 그 중 하나도 없으면 SRS가 필요하지 않습니다.

불행히도, 나는 이것에 관한 학문적 일에 즉시 손을 댈 수 없습니다. 그러나 수신 전자 메일에서 SPF를 확인한 후 일부 메일 서버가이를 확인 한다고 확신 할 수 있습니다 . -allSRS를 사용하지 않는 한 서버를 내 서버의 계정으로 전달한 모든 클라이언트는 종료해야하는 SPF를 알리는 발신자로부터 전송 된 전자 메일을 잃게됩니다 . 따라서 SRS가 없으면 고객의 이메일 중 일부가 전달되지 않을 것이라고 확신 할 수 있습니다 .

Marc에게 독일어를 읽을 수 없다는 점에 대해 사과드립니다. PDF를 인용하는 PDF가 강력한 논증을하는지 여부는 말할 수 없지만 SRS가 없으면 고객의 이메일 중 일부가 전달되지 않을 것이라고 반복 할 수 있습니다. 나는 그 분수가 무엇인지 말할 수 없지만 0은 아닙니다. 그리고 주어진, 당신이 SRS를 실행하는 것 외에 다른 대안이 없다고 생각합니다.

귀하의 서버가 SPAM을 전달하여 자체적으로 도움이되지 않을 것에 동의합니다. 그러나 제 경험상 대부분의 평판 손상은 envelope-From 도메인이 아닌 IP 주소로 수행됩니다. 이것은 SRS 사용에 관계없이 수행됩니다.

귀하의 질문에 대한 더 깊은 대답은 SPF와 (잘 고려되지 않은 인터넷 차단) 후속 DMARC 사이에서 메일 전달 서비스가 하루를 보낸 것처럼 보입니다. 이미 사용자 중 한 명을 제외한 모든 사용자가 서버에서 최종 배달을하도록 요구했으며, 한 명의 사용자가 2016 년에 변경하거나 떠나야합니다. 요즘 많은 웹 메일 시스템은 서버 외부 메일을 사용하여 여러 사서함을 통해 통합 할 수 있습니다. IMAP 또는 POP 및 많은 메일 클라이언트를 사용하면 여러 IMAP 또는 POP 계정을 단일 통합 INBOX로 표시 할 수 있으므로 전달이 중앙 집중식 판독에 도움이되지 않습니다.

요컨대, 단기적으로는 SRS가 필요하고 장기적으로는 새로운 비즈니스 모델이 필요합니다.

SRS는이 논문에 대한 좋은 아이디어 인 것처럼 보이지만 실제로 Heinlein Support의 사람들에 따르면 실제로는 잘 작동하지 않습니다 (1 억 개 이상의 계정으로 중간 크기의 메일 서비스를 실행하고 있음).

자세한 내용은 독일어로 설명되어 있지만 https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

주된 이유는 SPF가 전자 메일의 일반적인 사용 사례를 잘 다루지 않기 때문에 SRS가 실제로 SPF를 구현하는 데있어 심각한 문제에 대한 작은 패치이기 때문입니다. SRS가 대규모 서버 기반에 배포되어야하는데 이는 합리적 일 수 있습니다. 따라서 대규모 서버에 배포 될 때까지는 전혀 이해가되지 않습니다.

그러나 대형 메일 제공 업체의 문제점은 오늘날 실제 사용자 규모가 크고 점점 더 많은 기술을 구현하고 있다는 것입니다 (DMARC의 후속 제품은 이미 파이프 라인에 있음). 신뢰할 수있는 방식으로 메일을 보내도록 메일 서버 설정.

Gmail, Hotmail 등과 같은 큰 메일 제공 업체에 메일을 더 잘 전달하려면 최소한 DKIM 및 DMARC를 구현해야하지만, 최대한 부드럽게 실패하도록 설정하고 메일 전송시 속도 제한 메커니즘을 구현해야합니다. 당신을 위해 놀라운 일을 할 것입니다.

큰 공급자의이 문제는 오늘날 Mailchimp, Mandrill 또는 Returnpath와 같은 서비스가있는 이유입니다. 해당 제공 업체는 Google & Co에 돈을 지불합니다. 더 나은 배송 품질.

Google에 관한 중요한 사실 인 @MadHatter의 각 단어에 동의합니다.

Gmail에 전달 서비스를 제공하는 경우 SMTP 액세스도 제공 할 수 있으므로 Gmail 사용자가 Gmail이 대신 저장 한 주소를 대신하여 Gmail에서 메일을 보낼 수 있습니다.

이 경우 Gmail은 사용자가이 이메일의 전달자임을 알고 있으며 SPF 확인에 실패하더라도 전달을 스팸으로 표시하지 않습니다.

bill@microsoft.com에서 고객에게 메일을 보낼 수 있습니다. 메시지가 경고없이받은 편지함에 도착합니다! (Microsoft 는 -all spf 레코드를 가지고 있습니다)

확인하고 확인했습니다. 첨부 된 예입니다.

이 메시지는받은 편지함으로 이동했습니다.