เหตุผลที่ถูกต้อง SMTP“ อีเมลจาก:” จะไม่ตรงกับ“ จาก:” ส่วนหัวใน DATA

มีเหตุผลที่ถูกต้องหรือไม่สำหรับฟิลด์“ MAIL FROM:” SMTP ที่ไม่ตรงกับฟิลด์“ จาก:” ในส่วนข้อมูลของข้อความนอกเหนือจากรายชื่ออีเมล

จาก/programming/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-mean :

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

ปัญหาของบรรทัดของตรรกะนี้อยู่ที่นี่:“ ความอนุเคราะห์ต่อผู้รับ” การรวมที่อยู่“ จาก:” ในอีเมลผ่าน SMTP ไม่ได้เป็นมารยาท จำเป็นถ้าผู้รับสามารถส่งคำตอบได้

จาก: วิธี จำกัด ส่วนหัว From ให้ตรงกับ MAIL FROM ใน postfix ได้อย่างไร :

“ แต่ถ้าคุณต้องการให้แน่ใจว่าจาก: และอีเมลจากนั้นคุณต้องใช้ header_checks เพื่อให้ Return-Path: ตรงกันจาก:”

ความหมายของการทำเช่นนี้มีอะไรบ้าง เห็นได้ชัดว่าการส่งจดหมายจะเป็นปัญหา มีการใช้งานที่ถูกกฎหมายอื่น ๆ ของข้อมูลส่วนหัว“ MAIL FROM:” และ“ From:” ที่แตกต่างกันหรือไม่?

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

สาเหตุหลักที่ทำให้ข้อความที่ส่งจากเมลไคลเอ็นต์ของผู้ใช้อาจมีความแตกต่างจากที่อยู่จะถูกส่งต่อเมล จากนั้นเนื้อหาของอีเมลควรซื่อสัตย์ต่อต้นฉบับ แต่ในกรณีที่มีข้อผิดพลาดในการจัดส่งควรรายงานผู้ใช้ที่ส่งต่ออีเมลไม่ใช่ผู้ส่งดั้งเดิม

นอกเหนือจากส่วนหัวของ SMTP แล้วยังมีส่วนหัว MIME ที่หลากหลายซึ่งโปรแกรมต่าง ๆ ใช้เพื่อพยายามแยกแยะความแตกต่างระหว่างผู้ส่งต้นฉบับและผู้ส่งระดับกลางและ / หรือที่อยู่ที่ต้องการเพื่อรายงานข้อผิดพลาดไปยังตอบกลับไปยังผู้ส่ง , Errors-To, etc, แต่ละอันมีความหมายต่างกัน บางส่วนมีการสนับสนุนมาตรฐานในขณะที่อื่น ๆ อีกมากมายไม่ได้ทำ แต่อาจมีการใช้งานอยู่แล้ว วิธีการทำงานของโปรแกรมอีเมลต่าง ๆ นั้นแตกต่างกันมาก

แนะนำให้เลือกว่าจะใช้วิธีการจัดการกับจดหมายหรือไม่เป็นเรื่องที่แตกต่างไปจากการใช้อีเมลว่า "ถูกกฎหมาย" หรือไม่ หากคุณกำลังพิจารณาความถูกต้องที่นี่ในแง่ของนโยบายการจัดการสแปมที่อาจเกิดขึ้นได้ฉันไม่คิดว่าคุณจะสามารถแยกความแตกต่างได้ง่ายด้วยวิธีนี้

ลองนึกถึงการเซ็นชื่ออีเมล DKIM และการรับรองความถูกต้อง SPF ของเซิร์ฟเวอร์อีเมลสำหรับโดเมนอีเมล หากคุณกำลังส่งจดหมายจำนวนมากอาจเป็นสิ่งสำคัญที่จะสามารถตรวจสอบสิทธิ์จดหมายของคุณด้วยวิธีการเหล่านี้และอาจมีผลกระทบต่อการกำหนดที่อยู่ของจดหมายจากส่วนหัวเนื่องจากคุณสามารถรับรองความถูกต้องของจดหมายที่เกี่ยวข้องกับโดเมนที่คุณมีสิทธิ์เท่านั้น .

-

ขยายตามคำขอ:

ส่วนหัว 'Reply-To' ของ MIME จะนำ MUA (ตัวแทนผู้ใช้จดหมายโดยปกติจะเป็นไคลเอ็นต์อีเมลของบุคคล) เพื่อส่งการตอบกลับไปยังที่อยู่อื่นแทนที่จะเป็นที่อยู่ MIME สิ่งนี้ไม่ได้ถูกใช้โดย MTA (Mail Transport Agent) สำหรับสิ่งต่าง ๆ เช่นข้อผิดพลาด

โดยทั่วไปแล้ว MTA จะใช้ที่อยู่อีเมล 'SMTP MAIL' เพื่อส่งข้อผิดพลาดไปยังที่อยู่ SMTP สามารถแก้ไขได้ด้วยส่วนหัว 'Errors-To' ของ MIME ซึ่งเป็นคำสั่ง MTA ไม่ใช่ MTA ทั้งหมดที่จะให้เกียรติดังนั้นจึงเป็นกลไกที่ด้อยกว่าในการตั้งค่าที่อยู่ซองจดหมายของ SMTP แต่มีหลายกรณีที่อาจเป็นไปได้ที่จะตั้งค่า MIME Headers เป็นข้อความ เช่นซอฟต์แวร์ที่ทำงานในสภาพแวดล้อมการโฮสต์ที่ใช้ร่วมกันอาจพบว่าตัวเองอยู่ในสถานการณ์นี้

'ผู้ส่ง' นั้นมีความกำกวมมากกว่าคำสั่งสำหรับตัวแทนซอฟต์แวร์ แต่ระบุว่าใครหรือสิ่งใดที่ส่งอีเมลในกรณีที่แตกต่างจากที่อยู่จากซึ่งมีลักษณะคล้ายกับผู้ส่งอีเมลในนามของ เช่นเมื่อคุณกรอกแบบฟอร์มจดหมายออนไลน์นักการเมืองของคุณมันจะเหมาะสมมากสำหรับอีเมลที่เป็นผลลัพธ์เพื่อใช้อีเมลของคุณในส่วนหัวจาก แต่มีที่อยู่ผู้ส่งที่เกี่ยวข้องกับองค์กรที่ตั้งค่าแบบฟอร์ม

'เดิม - มาจาก' ถูกใช้โดยซอฟต์แวร์ MUA บางอย่างเมื่อส่งต่อจดหมายพร้อมที่อยู่ของผู้ส่งที่ใช้สำหรับส่วนหัว 'จาก' MUAs อื่น ๆ จะปล่อยให้อยู่จากคนเดียวและใช้ส่วนหัว 'Resent-From' ไม่ว่า MUAs จะได้รับอีเมลส่วนหัวที่หลากหลายเหล่านี้ตีความว่าส่วนหัวเป็นประโยชน์หรือแม้กระทั่งแสดงว่าเป็นตัวแปรที่ค่อนข้าง เมื่อตอบกลับจดหมายที่ส่งต่อถึงคุณการตอบกลับควรไปที่ใคร อาจเป็นการดีที่สุดหากตั้งค่าส่วนหัว "ตอบกลับ"

พฤติกรรมของ MUAs นั้นแตกต่างกันไปและมีการกำหนดไว้ไม่ดีแม้ว่ามันจะดูเหมือนจะดีขึ้นเมื่อเวลาผ่านไปก็ตาม ในทางตรงกันข้ามความหมายของซองจดหมายนั้นมีความชัดเจนมากกว่า โดยทั่วไปแล้วจะมีสถานะที่แข็งแกร่งที่ MTAs ไม่ควรเกี่ยวข้องกับส่วนหัว MIME แต่เนื่องจาก MTA มีหน้าที่รับผิดชอบเนื้อหาอีเมลมากขึ้น (เช่นดูค่า SPF และมาตรฐาน DMARC ที่เกิดขึ้นใหม่) จึงมีแรงกดดันให้ความชัดเจนของตำแหน่งนั้นลดลง กลไกอันยาวนานเช่นข้อผิดพลาด - ยังขัดแย้งกับแนวคิดของ MTA ที่ไม่ได้ดูเนื้อหาส่วนหัวซึ่งเป็นส่วนหนึ่งของสาเหตุที่กลไกเหล่านั้นถูกนำมาใช้อย่างไม่สอดคล้องกันเสมอ ปรัชญาของผู้เขียนซอฟต์แวร์แตกต่างกันไป

คุณอาจพบว่ามีประโยชน์ในการตรวจสอบhttp://tools.ietf.org/html/rfc4021#section-2แต่โปรดจำไว้ว่าการปฏิบัติที่แท้จริงของซอฟต์แวร์จดหมายจำนวนมากนั้นแตกต่างกันไปในวิธีที่ไม่จำเป็นต้องได้รับพรมาตรฐาน

การพยายามคิดปรัชญาที่ชัดเจนว่าควรใช้จดหมายอย่างไรดี แต่อย่าคาดหวังว่าคนอื่นจะทำในสิ่งที่คุณคิดว่าควรจะเป็น

การประมวลผลอัตโนมัติเป็นเหตุผลสำคัญ คุณต้องการที่จะสามารถส่งการตีกลับ / autoreplies / ข้อผิดพลาดใด ๆ ที่จะดำเนินการแยกต่างหากมิฉะนั้นข้อความเหล่านั้นหายไปหรือได้รับการละเว้นหรือ SAP ไม่ดีบางคนต้องขุดผ่านพวกเขา ใช่การเพิ่มส่วนหัว X- สำหรับการประมวลผลเป็นไปได้ แต่มีเวลามากในการตีกลับ / ฯลฯ จะไม่รวมอีเมลต้นฉบับหรือเพียงบางส่วนของมันและคุณจะไม่สามารถรับที่มา

ตัวอย่างเช่นสมมติว่ามีคนลงชื่อสมัครใช้บนเว็บไซต์ของคุณและคุณส่งอีเมลถึงพวกเขาเพื่อขอบคุณสำหรับการสมัคร MAILFROM และ From ของคุณอาจมีลักษณะเช่นนี้:

MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>

วิธีนี้ผู้ใช้จะเห็น "เป็นมิตรจาก" ในเมลไคลเอ็นต์ แต่หากผู้ใช้ไม่มีอยู่ MTA ของพวกเขาจะส่งข้อความตีกลับไปที่:

user-signup-123123123@bounces.example.com

และกระบวนการอัตโนมัติสามารถดึงหมายเลขผู้ใช้ (ส่วน 123123123) และส่วนของระบบที่สร้างการตีกลับ (ส่วนที่ลงทะเบียน) จากส่วนหัวและลบ / ทำเครื่องหมายผู้ใช้ว่าปิดการใช้งานได้อย่างง่ายดาย

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

อีเมลที่ไม่ควรสร้างการตีกลับควรตั้งค่าผู้ส่งที่ว่างในซองจดหมายตัวอย่างเช่นใบเสร็จรับเงินที่ส่งคืนมักจะมี: mail from:<>โดยใช้ชื่อผู้ใช้ในส่วนหัวจาก:

สถานการณ์อื่นคือที่ที่เมลเซิร์ฟเวอร์ใช้ BATV เพื่อปฏิเสธการตีกลับที่ปลอม อีเมลจาก: จะอยู่ในรูปแบบ prvs=tag-value=mailbox@example.com

ถ้าฉันไม่ได้อ่านส่วนหัวหรือคำถามถูกต้องอีเมลจาก BlackBerry ของฉันจะถูกส่งจากเซิร์ฟเวอร์ BlackBerry และโดยทั่วไปแล้วไม่มีฟิลด์ใดที่ตรงกัน ฉันรู้เพียงไม่กี่เปอร์เซ็นต์ของผู้ใช้ ฉันได้ดูสิ่งนี้เมื่อเร็ว ๆ นี้ในการประเมินเมลเซิร์ฟเวอร์ของฉัน ด้านล่างเป็นอีเมลที่ไม่ระบุชื่อที่ส่งจาก BlackBerry ของฉันไปยังบัญชี Gmail ของฉัน:

Delivered-To: recipientusername@gmail.com
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
        Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
        by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
        for <recipientusername@gmail.com>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
    by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
    by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: senderusername@example.com
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <recipientusername@gmail.com>
From: senderusername@example.com
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T