ฉันควรใช้ส่วนหัวตอบกลับเมื่อส่งอีเมลเป็นบริการให้กับผู้อื่นหรือไม่?


112

สมมติว่าเรามีแอปพลิเคชันที่ทำหน้าที่เป็นคนกลางโดยให้ บริษัท A ส่งรายงานไปยังลูกค้าของตน

บริษัท A -> บริษัท B (ฉัน) -> ลูกค้าของ บริษัท A

หลังจากได้รับรายงานแล้วเราจะส่งการแจ้งเตือนทางอีเมลไปยังผู้รับ แต่จำเป็นต้องมาจากที่อยู่อีเมลแจ้งเตือนของ บริษัท ของเราเช่น

joe.bloggs@a.com -> notification@b.com -> peter@c.com

ตอนนี้ลูกค้ามักจะตอบกลับการแจ้งเตือนทางอีเมลโดยต้องการให้พวกเขากลับไปหาใครก็ตามที่ส่งรายงานที่ บริษัท A แต่พวกเขากลับมาที่ที่อยู่ของเราที่ notification@b.com

วิธีแก้ปัญหาง่ายๆคือการเปลี่ยนส่วนหัวการตอบกลับในการแจ้งเตือนที่เราส่งไปยังที่อยู่ บริษัท A ที่เกี่ยวข้องเช่น

joe.bloggs@a.com -> notification@b.com [ตอบกลับ: joe.bloggs@a.com] -> peter@c.com

แต่ความกังวลหลักของฉันคือ:

  • ความคลาดเคลื่อนโดยสิ้นเชิงในที่อยู่อีเมลและโดเมนระหว่างช่องจากและช่องตอบกลับอาจทำให้ตัวกรองสแปมหรือฟิชชิ่งกระตือรือร้นที่จะตั้งค่าสถานะอีเมล
  • ไม่ใช่ไคลเอนต์อีเมลทั้งหมดที่อาจเคารพช่องตอบกลับเมื่อมีคนคลิก "ตอบกลับ" จริงๆและใช้จากแทน ความกังวลน้อยกว่าเว้นแต่จะแพร่หลาย

ความกังวลเหล่านี้เกิดขึ้นหรือไม่? หรือมีข้อกังวลอื่น ๆ ที่ฉันควรมีหรือไม่?

คำตอบ:


92

คุณอาจต้องการพิจารณาใส่ชื่อลูกค้าในFromส่วนหัวและที่อยู่ของคุณในSenderส่วนหัว:

From: Company A <joe.bloggs@a.com>
Sender: notifications@b.com

ผู้ส่งจดหมายส่วนใหญ่จะแสดงเป็น "จากการแจ้งเตือน@b.comในนามของ บริษัท A" ซึ่งถูกต้อง แล้วที่อยู่Reply-Toของ บริษัท A ก็ดูเหมือนจะไม่แปลก

จากRFC 5322 :

ช่อง "จาก:" ระบุผู้เขียนข้อความนั่นคือกล่องจดหมายของบุคคลหรือระบบที่รับผิดชอบในการเขียนข้อความ ช่อง "ผู้ส่ง:" ระบุกล่องจดหมายของตัวแทนที่รับผิดชอบการส่งข้อความจริง ตัวอย่างเช่นหากเลขานุการต้องส่งข้อความหาบุคคลอื่นกล่องจดหมายของเลขานุการจะปรากฏในช่อง "ผู้ส่ง:" และกล่องจดหมายของผู้เขียนตัวจริงจะปรากฏในช่อง "จาก:"


4
ฉันไม่ต้องการให้เจ้าของคำตอบของฉันได้รับการโหวต แต่สิ่งที่ควรค่าแก่การกล่าวถึงคือคำถามและคำตอบที่มีประโยชน์นี้ซึ่งโดยพื้นฐานแล้วก็เป็นการยืนยันคำตอบของ dkarp เช่นกัน: stackoverflow.com/questions/2231897/…
Gavin

1
หากเป็นแบบวงกลมจะใช้ไม่ได้ @a และ @b เป็นโดเมนที่แตกต่างกันเซิร์ฟเวอร์ส่วนใหญ่ไม่อนุญาตให้ส่งในนามของบุคคลจากโดเมนอื่น B จะต้องส่งต่อ แต่คุณสามารถเพิ่มหลายส่วนที่ซ่อนอยู่ได้ตลอดเวลา ทุกคนรู้วิธีส่งต่อไปยังที่อยู่อื่น
Aridane Álamo

2
มีการอัปเดตจากปี 2018 เกี่ยวกับความสามารถในการส่งมอบเมื่อใช้ช่องจากในลักษณะนี้หรือไม่
David Alan Hjelle

160

ฉันทดสอบโซลูชันของ dkarp กับ gmail และถูกกรองเป็นสแปม ใช้ส่วนหัว Reply-Toแทน (หรือนอกจากนี้แม้ว่า gmail จะไม่ต้องการก็ตาม) นี่คือวิธีการเชื่อมโยง:

Sender: messages-noreply@bounce.linkedin.com
From: John Doe via LinkedIn <member@linkedin.com>
Reply-To: John Doe <John.Doe@gmail.com>
To: My Name <My.Name@gmail.com>

เมื่อเปลี่ยนมาใช้รูปแบบนี้ Gmail จะไม่กรองข้อความของฉันว่าเป็นสแปมอีกต่อไป


member@linkedin.com เป็นเพียงที่อยู่ที่รับทั้งหมดทั่วไปหรือควรอ่าน john.doe@linkedin.com ในตัวอย่างของคุณ
ฌอน

6
นี่คือวิธีที่เราเคยใช้ อย่างไรก็ตามตอนนี้เรากำลังมีปัญหากับเซิร์ฟเวอร์บางตัว (... เอ๊ะ .. AOL) ข้อความตีกลับโดยระบุว่าไม่เป็นไปตามนโยบายของพวกเขา คำอธิบายเดียวที่เราได้รับคือส่วนหัวตอบกลับและจากส่วนหัวมีโดเมนที่แตกต่างกันแม้ว่านี่จะเป็นเจตนาที่แท้จริงของการมีส่วนหัวที่แตกต่างกันสองรายการ การพึ่งพาอีเมลสำหรับการสื่อสารแบบ B2B บนแอปที่มีผู้เช่าหลายรายเป็นเรื่องน่าหงุดหงิดมาก
Brian H.

4
@BrianH: AOL และ Yahoo เห็นได้ชัดว่าขณะนี้มีการตรวจสอบ DMARC ที่ก้าวร้าว สิ่งนี้ทำให้ฉันมีปัญหากับที่อยู่ "จาก:" ไปยัง AOL emailonacid.com/blog/details/C4/… .
EML

3
ข้อเสียของวิธีนี้คือสมุดที่อยู่ของผู้รับ (ในไคลเอนต์อีเมลจำนวนมาก) มี "John Doe ผ่าน LinkedIn <member@linkedin.com>" และเมื่อผู้รับที่ไม่รู้ตัวต้องการติดต่อ John Doe อีกครั้งที่อยู่นี้จะปรากฏขึ้นเมื่อเขียนชื่อของเขาในช่องถึงของข้อความใหม่ (ดังนั้น "ผ่าน LinkedIn" จึงมีความสำคัญอย่างมากจากฝั่ง UX)
smhg

1
ลิงก์ที่อัปเดตสำหรับบล็อกโพสต์ @EML ที่เชื่อมโยงกับ: emailonacid.com/blog/article/industry-news/… ... มันจะเข้าลึกบางประเด็นเกี่ยวกับ aol / yahoo.com
Lambart

-3

ที่นี่ใช้งานได้สำหรับฉัน:

Subject: SomeSubject
From:Company B (me)
Reply-to:Company A
To:Company A's customers
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.