고객의 도메인을 대신하여 이메일을 보내는 가장 좋은 방법은 무엇입니까?


15

메일 서버가 고객의 도메인을 대신하여 이메일을 보내도록 허용하는 최선의 방법을 알고 싶었습니다.

나는 여기 , 여기여기에 다른 질문을 읽었 지만 가능한 모든 솔루션을 탐색하지는 않습니다. 다음은 비교하고 싶은 몇 가지 가능성입니다.

ㅏ.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>  # mymailserver.com same IP as myapp.com
DATA
  From: <res@client.com>
  Sender: <do-not-reply@myapp.com>

질문 : 이것이 gmail이하는 일입니다. 봉투 발신자가 아닌 다른 도메인을 가진 msg 헤더 "보낸 사람 :"입니다.
emailclients가 표시됩니다 : "do-not-reply@myapp.com를 통해 res@client.com에서" 또는 "res@client.com의 대신에 do-not-reply@myapp.com에서"없는 문제 나를 위해.
이제 이것이 내 도메인의 평판에 나쁜 영향을 미치나요? 헤더 "From :"이 다른 도메인을 가지고 있다는 사실입니까? (그리고 구글이 아니라면 누가하는지.)

비.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>
DATA
   From: <res@client.com>
   # same as A, but no "Sender:"

구글은 한 번 이런 짓을하고 실수를 불리는 것 같습니다 http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf + of % 22 & pli = 1
버그가 메시지에서 "Sender :"를 제거했으며 "via" 가 이메일 클라이언트에 나타나지 않았습니다. RFC는 "보낸 사람 :"과 같지 않으면 반드시 존재해야한다고 말합니다.

씨.

HELO mymailserver.com
MAIL FROM<res@client.com>
DATA 
  From: <res@client.com>

마치 client.com이 메시지를 보내는 것과 같습니다 (MAIL FROM도 "스푸핑되었습니다"). 그러나 client.com 도메인이 잘 알려져 있거나 DNS에 SPF 항목이있는 경우 mymailserver.com이 자신을 대신하여 메시지를 보낼 수 있도록 해당 DNS를 변경해야합니다. , 고객 및 일부 내 고객은 도메인을 제어 할 수 없습니다 (예 : @ gmail.com을 직접 사용하고 있음)

디.

HELO mymailserver.com    
MAIL FROM<do-not-reply@myapp.com>
DATA 
  From: <do-not-reply@myapp.com>
  Reply-to: <res@myclient.com>

질문 : 이것은 가장 간단한 것입니다. "답장 :"헤더 만 추가합니다. 이것이 이메일 클라이언트에 의해 항상 고려됩니까? 이 도메인도 스푸핑으로 인식되어 "Reply-to"헤더에 다른 도메인을 추가하여 내 도메인의 평판에 나쁜 영향을 줄 수 있습니까?
-RFC는 "답장 필드가 존재하는 경우 회신은 보낸 사람 필드에 표시된 주소가 아닌 해당 필드에 표시된 주소로 이동해야합니다" 라고만 말합니다.
- "보낸 사람 :"헤더 레이블 만 "스푸핑":
"보낸 사람 : myclient.com (myapp.com 사용) <do-not-reply@myapp.com>"


RFC를 읽을 때 'SHOULD'는 매우 강력한 추천을 의미합니다. 대부분의 경우 클라이언트가하지 않는 유일한 이유는 RFC가 작성된 이후 클라이언트가 오래되었고 업데이트되지 않았기 때문입니다. 표준 정의에 대해서는 RFC 2119를 참조하십시오 ietf.org/rfc/rfc2119.txt
매튜 Scharley에게


불행히도 2018 년 현재 많은 전자 메일 클라이언트는 여전히 회신 헤더를 무시합니다. meta.discourse.org/t/…
Martin Meixger

답변:


2

훌륭한 질문입니다. 방금 몇 시간 동안 같은 것을 연구했습니다.

이메일 양식에 옵션 C 를 사용하는 (주로 순진하지 않은) 수많은 웹 사이트를 이전에 배포 했지만 배달 문제가 점점 늘어나고 있습니다. 이메일 제공 업체는 점차 강화하고 있습니다. 예를 들어 Yahoo는 최근 DMARC 정책변경하여 수신자에게 유효한 DKIM 서명없이 모든 이메일From: ____@yahoo.com거부 하도록 요청했습니다 . DMARC (Gmail, 아마도 Hotmail / Outlook.com 및 Yahoo 포함)를 따르는 SMTP 서버를 수신하면 이러한 메시지가 제대로 반송되지 않습니다 . eBay와 Paypal은 피싱을 줄이기위한 비슷한 엄격한 정책을 가지고 있습니다. 불행히도 "보내기"헤더를 지정해도 도움이되지 않습니다.

(Yahoo 별칭을 "보낸 사람"에게 보낼 때 Gmail이이 문제를 어떻게 해결하는지 궁금합니다.

"보낸 사람"전자 메일에 엄격한 DMARC 정책이없는 경우 옵션 A 가 더 나은 옵션입니다 (단순한 DNS 쿼리를 통해이를 확인할 수 있음).

시각적으로 가장 매력적이지는 않지만 옵션 D는 실제로 가장 안전 하며 향후 대부분의 프로젝트에 권장됩니다. PayPal은 이전에 옵션 A를 사용했지만 이제는 옵션 D로 전환 했다는 점에 주목할 가치가 있습니다.

신뢰성을 높이고 배송 기회를 늘리기 위해 SPF 및 / 또는 DKIM을 구현하는 방법을 살펴 보겠습니다. 이것들과 다른 것들이 내가 도움이되는 Google 대량 발송자 가이드 라인에 언급되어 있습니다.


1

당신이 원하는 것이 확실하지 않습니다. 원하는 것을 수행하는 "안전한"또는 "안전하지 않은"방법은 없습니다.

나는 항상 D를 선호합니다). 또한 SPF 레코드를 추가합니다. 그러나 내가 말했듯이 이것은 다른 것보다 안전하거나 안전하지 않습니다 (당신이 의미하는 바는 무엇이든).

답장 헤더는 평판에 영향을 미치지 않습니다. 고객에게 답장을 위해 해당 주소를 사용하도록 조언합니다 (Duh, 아마도 이름이 유래 한 곳일까요?!). 클라이언트가이 권장 사항을 따르는 경우 보장되지 않습니다.


"안전한"이란 내가 선택한 솔루션으로 인해 실수로 스 푸퍼 / 스팸으로 간주되는 도메인을 그레이리스트에 올릴 가능성을 최소화한다는 의미입니다. 예, D와 함께 사용하면 도메인에 SPF 항목을 추가하고 DKIM을 사용하여 메시지에 서명하는 것을 고려할 수 있습니다.
dgaspar

내 질문을 편집하고 명확하게하려고했습니다 ..
dgaspar

@dgaspar Greylisting은 봉투를 기반으로합니다. 따라서 귀하의 콘텐츠 (보낸 사람 :, 보낸 사람 :, ...)는 완전히 무시됩니다. 모든 사람이 모든 메일 주소를 발신자로 쓸 수 있으므로 모든 발신자 주소는 스푸핑 된 것으로 간주됩니다. SPF 또는 DKIM으로 메일에 서명하는 것을 제외하고.
mailq

0

두 가지 신뢰할 수있는 솔루션 :

  1. 고객에게 SPF 도메인 레코드에 메일 서버를 추가하도록 요청
  2. 고객에게 전자 메일 계정 자격 증명 (메일 서버 IP, 사용자 이름, 암호)을 요청하고 응용 프로그램 내부에서 전자 메일 계정에 연결하여 전자 메일을 보내도록 요청합니다 (실제로 응용 프로그램 내에 전자 메일 클라이언트를 만듭니다).
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.