Score:0

โดยทั่วไปเซิร์ฟเวอร์ SMTP จำเป็นต้องคัดลอก MAIL FROM จากเซสชันไคลเอ็นต์-เซิร์ฟเวอร์หรือไม่

ธง br

เซิร์ฟเวอร์ SMTP ในระหว่างการสื่อสารเซิร์ฟเวอร์ (STMP) เซิร์ฟเวอร์ถึง (SMTP) จำเป็นต้องคัดลอก MAIL FROM จากเซสชันไคลเอนต์เซิร์ฟเวอร์หรือไม่ ฉันได้ตรวจสอบอย่างชัดเจนแล้วว่าเซิร์ฟเวอร์ของผู้ให้บริการอีเมลบางรายแสดงพฤติกรรมนี้จริง แต่ดูเหมือนว่าจะไม่เป็นข้อกำหนดที่บังคับใช้โดย https://datatracker.ietf.org/doc/html/rfc5321 . นอกจากนี้ฉันไม่รู้ว่าการปฏิบัตินี้เป็นที่นิยมเพียงใด (หากไม่ใช่มาตรฐาน)

อัปเดตให้เจาะจงมากขึ้น: ฉันสนใจเป็นหลักในกรณีของข้อความอีเมลทั่วไป แบบบุคคลต่อบุคคล โดเมนบนสองเซิร์ฟเวอร์ที่แตกต่างกัน

Rowan Hawkins avatar
us flag
จะเป็นการดี เพราะอย่างน้อยคำตอบหนึ่งข้อดูเหมือนจะตอบคำถามของคุณ เพื่อให้คุณทำเครื่องหมายว่าเป็นคำตอบและจะกลายเป็นข้อมูลอ้างอิงสำหรับผู้อื่น
Tom Johnson avatar
br flag
มีสองคำตอบที่ (เกือบ) ตอบคำถามของฉันโดยตรง ทั้งสองคำตอบนั้นดีพอๆ กัน (IMO) เป็นไปได้ไหมที่จะเลือกหนึ่งในนั้นแบบสุ่มและทำเครื่องหมายว่ายอมรับ
Score:1
ธง jp

The RFC 5321, 3.3 tells what the MAIL FROM:<reverse-path> is for:

The <reverse-path> portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors (see Section 4.2 for a discussion of error reporting).

The originator fields in the Internet Message Format headers (RFC 5322, 3.6.2) have more specific purposes to distinguish the author (From:) from the agent responsible for the actual transmission of the message (Sender):

For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field.

The RFC 5321 envelope sender has merely a technical purpose. It is typical in mail forwarding and mailing list scenarios to rewrite the MAIL FROM to match the forwarding domain/server or the mailing list operator. This has two benefits:

  • The error reports will get back to the mailing list operator who should take care of removing erroneous addresses from the list.
  • Rewriting the envelope sender does not break the SPF policy of the original domain (Shevek (2004): The Sender Rewriting Scheme).

On the other hand, such practices are slightly against RFC 5321, 3.7.5:

3.7.5. Envelopes in Gatewaying

Similarly, when forwarding a message from another environment into the Internet, the gateway SHOULD set the envelope return path in accordance with an error message return address, if supplied by the foreign environment. If the foreign environment has no equivalent concept, the gateway must select and use a best approximation, with the message originator's address as the default of last resort.

I do not see this as a problem, because the SMTP protocol has not been updated (except for the SMTP 521 and 556 Reply Codes, RFC 7504) since 2008, but the practices including email forgery prevention have evolved since.

Tom Johnson avatar
br flag
ฉันทราบเรื่องนี้แล้ว แต่ขอบคุณสำหรับข้อมูล แต่คำถามของฉันแตกต่างออกไปเล็กน้อย - ไคลเอ็นต์ SMTP ให้ "MAIL FROM: ... " ระหว่างการสื่อสาร MUA - MTA โดยทั่วไปเซิร์ฟเวอร์จะคัดลอก "MAIL FROM: ..." นี้ในระหว่างการสื่อสาร MTA - MTA สำหรับข้อความนี้หรือไม่ จากสิ่งที่ฉันพบจนถึงตอนนี้ เซิร์ฟเวอร์ SMTP ขาออกโดยทั่วไปนั้นไม่มีค่าใช้จ่าย (ตาม RFC5321) ในการสร้าง "MAIL FROM: ..." ในแบบของเขาเอง ซึ่งสามารถนำมาจาก "จาก: ", "ผู้ส่ง: " , "MAIL FROM: ..." หรือแม้กระทั่งตั้งเป็นค่าที่ไม่ได้มาตรฐาน (แม้ว่าโดยปกติแล้วจะไม่สมเหตุสมผลมากนักเมื่อถ่ายโอนข้อความปกติ)
Tom Johnson avatar
br flag
แต่บางทีเซิร์ฟเวอร์ SMTP อาจทำงานในลักษณะเฉพาะบางอย่างโดยเป็นเพียงพฤตินัย ไม่ใช่มาตรฐานอย่างเป็นทางการ
Tom Johnson avatar
br flag
อันที่จริง คำตอบของคุณตอบคำถามเดิมของฉันสำหรับกรณีการส่งต่อจดหมายและรายชื่อผู้รับจดหมาย แต่จริงๆ แล้วฉันสนใจมากกว่าว่าหน้าตาเป็นอย่างไรในกรณีของข้อความปกติ ฉันอัปเดตข้อความต้นฉบับเล็กน้อยเพื่อให้สะท้อนถึงสิ่งนั้น
jp flag
ในสถานการณ์ง่ายๆ จดหมายจะส่งโดยตรงจากเซิร์ฟเวอร์จดหมายของผู้ส่งไปยังเซิร์ฟเวอร์จดหมายของผู้รับ ดังนั้นจึงไม่มีที่สำหรับเขียนอะไรใหม่ก่อนเซิร์ฟเวอร์ถัดไป หากโครงสร้างพื้นฐานในการรับมีความซับซ้อนมากกว่านั้น ก็สามารถทำทุกอย่างที่เหมาะสมกับวัตถุประสงค์ของมันเอง มาตรฐานไม่ได้จำกัดว่าในทางใดทางหนึ่ง
Tom Johnson avatar
br flag
ขอบคุณ. แม้ว่าการสื่อสารเซิร์ฟเวอร์ SMTP โดยตรง - ถึง - เซิร์ฟเวอร์ SMTP นั้นหายาก แต่โดยทั่วไปแล้วจะมี MTA อยู่ด้านหน้าสุดของทุกสิ่ง ตกลง ดังนั้นฉันคิดว่าสามารถยอมรับได้อย่างสมเหตุสมผลว่าเมื่อมีการส่งจดหมายปกติและผ่านเซิร์ฟเวอร์ SMTP ขาออกตามปกติไปยังเซิร์ฟเวอร์ SMTP ขาเข้าปกติ เราคาดหวังได้ว่า "เส้นทางย้อนกลับ" จะถูกนำมาจากต้นฉบับ " MAIL FROM:" หรือจาก "ผู้ส่ง:" หรือจากส่วนหัวของ "จาก:" แม้ว่าเราจะไม่สามารถบอกล่วงหน้าได้ว่าเซิร์ฟเวอร์ SMTP ใดใช้ส่วนหัวนี้ในส่วนหัวใด และไม่รับประกันว่าจะมีส่วนหัวใด
Tom Johnson avatar
br flag
"มี MTA นั่งอยู่ด้านหน้าสุดของทุกสิ่ง" - ฉันหมายถึง MUA
jp flag
ฉันได้เพิ่มการอ้างอิงถึงบทหนึ่งใน RFC 5321 ที่แนะนำว่าอย่าแก้ไขตัวส่งเอนเวโลป แต่หาเหตุผลเข้าข้างตนเองว่าสิ่งนี้ล้าสมัยได้อย่างไร แม้ว่าจะอยู่ในข้อกำหนดโปรโตคอลปัจจุบันก็ตาม
Tom Johnson avatar
br flag
หลังจากอ่านเพิ่มเติมเกี่ยวกับ RFC 5321 ฉันไม่แน่ใจว่าคุณพูดถูกหรือไม่ว่า "การปฏิบัติดังกล่าวขัดกับ RFC 5321, 3.7.5" เล็กน้อย เนื่องจากส่วนที่คุณยกมาเกี่ยวข้องกับเมลเกตเวย์ และดูเหมือนว่าเกตเวย์และ โดยทั่วไปแล้ว Mailing List Bombers นั้นเป็นสองสิ่งที่แตกต่างกัน ฉันอ้างจาก RFC เดียวกัน: "เมื่อมีข้อความ ส่งหรือส่งต่อไปยังแต่ละที่อยู่ของแบบฟอร์มรายการที่ขยาย, the ที่อยู่ผู้ส่งกลับในซอง ("MAIL FROM:") ต้องเปลี่ยนเป็น ที่อยู่ของบุคคลหรือนิติบุคคลอื่นที่ดูแลรายการ"
Score:1
ธง us

เซิร์ฟเวอร์มีหน้าที่ต้องเปิดเส้นทางส่งคืน วิธีที่ง่ายที่สุดในการทำเช่นนี้คือการคัดลอกต้นฉบับ จดหมายจาก: ที่อยู่และใช้ซ้ำในการส่ง SMTP ขาออก แต่นี่ไม่ใช่วิธีเดียวที่จะตอบสนองความต้องการดังกล่าว

โดยทั่วไปจะทำอย่างนั้น แต่บางเซิร์ฟเวอร์ดำเนินการอื่นเช่นการปรับใช้ แบตทีวี, สสจ หรือรูปแบบอื่นของ เวอร์พี.

ดังนั้นจึงปลอดภัยที่จะคาดหวังว่าอีเมลที่ส่งถึงผู้ส่งที่ถูกกล่าวหาจะไปถึงบุคคลที่รับผิดชอบในการสร้างข้อความ แต่อาจเป็นไปได้ว่าผ่านทางคนกลางตั้งแต่หนึ่งรายขึ้นไปที่กู้คืนที่อยู่ผู้ส่ง SMTP ก่อนหน้า

Tom Johnson avatar
br flag
ขอบคุณสำหรับคำตอบของคุณ "เซิร์ฟเวอร์มีหน้าที่ต้องเปิดเส้นทางขากลับไว้" - เป็นเรื่องที่สมเหตุสมผลอย่างแน่นอน แต่มันเป็นข้อกำหนดที่เป็นทางการหรือเป็นเพียงแนวทางปฏิบัติเท่านั้น หากเป็นทางการ คุณช่วยระบุลิงก์ไปยังข้อกำหนดดังกล่าวได้ไหม
us flag
SMTP (RFC5321) กล่าวถึงเส้นทางการย้อนกลับและความสำคัญต่อการทำงานที่ราบรื่นของระบบอีเมล การอ้างสิทธิ์ของฉันส่วนใหญ่โดยปริยายจากสิ่งนั้น
Score:0
ธง in

จดหมายจาก:<reverse-path> ตามที่ชื่อพารามิเตอร์บอกเป็นนัย จะใช้ในกรณีที่เซิร์ฟเวอร์ต้องการ "ส่งกลับ" อีเมล เช่น ข้อผิดพลาดหรือปัญหาอื่นๆ และไม่จำเป็นต้องเหมือนกับผู้ส่งอีเมลต้นฉบับ

เซิร์ฟเวอร์จำนวนมากตรวจสอบฟิลด์นี้และใช้สำหรับสแปม แต่ไม่มีข้อกำหนดสำหรับสิ่งนี้

Tom Johnson avatar
br flag
ขอบคุณสำหรับคำตอบ แม้ว่าฉันจะรู้เรื่องนี้ แต่ฉันก็อัปเดตคำถามเดิมเพื่อให้สะท้อนถึงสิ่งที่ฉันต้องการทราบได้ดียิ่งขึ้น ดูความคิดเห็นของฉันใต้คำตอบของ Esa Jokinen
in flag
คำตอบคือ ไม่ควร อย่างน้อยไม่ควรใส่ไว้ในส่วนหัว หรือเก็บไว้ในหน่วยความจำเพื่อถ่ายโอนไปยัง "เซิร์ฟเวอร์ถัดไป" เซิร์ฟเวอร์ไม่เคยเขียนส่วน RFC822 จริงใหม่ หากทำ DKIM แล้วเพื่อนจะพัง

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา