คำถามติดแท็ก email-client


4
พฤติกรรมที่แตกต่างระหว่างเส้นทางกลับ, การตอบกลับและจากคืออะไร
ในใบสมัครทางไปรษณีย์ของเราเรากำลังส่งอีเมลโดยมีส่วนหัวดังต่อไปนี้: FROM: marketing@customer.com TO: subscriber1@domain1.com Return-PATH: bouncemgmt@ourcompany.com ปัญหาที่เราเผชิญคือเซิร์ฟเวอร์อีเมลบางแห่งจะเด้งกลับข้อความทันทีและใช้เส้นทางจากหรือย้อนกลับเส้นทาง (marketing@customer.com) แทนเซิร์ฟเวอร์เด้ง mgmt ของเรา เราต้องการทราบว่าเราปรับเปลี่ยนในส่วนหัวตอบกลับเป็นเหมือนเส้นทางกลับถ้าเราจะสามารถจับการตีกลับทั้งหมด ยินดีต้อนรับแนวคิดอื่นใดบ้าง เราใช้เอกสารต่อไปนี้เป็นข้อมูลอ้างอิง: VERP RFC Bounce Messages การแยกบันทึก SMTP เพื่อรับการตีกลับ แก้ไข 1: ข้อมูลอีกสองสามบิตเพื่อดูว่าเราจะได้รับการแก้ไขนี้หรือไม่ เราต้องการทราบว่าจุดใดที่เซิร์ฟเวอร์อีเมลที่ส่งข้อความจะเลือกใช้การตอบกลับกับเส้นทางย้อนกลับ เราสังเกตว่าเมื่อเซิร์ฟเวอร์ smtp แรกที่ส่งข้อความถูกปฏิเสธมันจะส่งไปยังการตอบกลับ แต่เมื่อมันเกิดขึ้นหลังจากหนึ่ง hop มันจะส่งไปยัง return-path
162 email  smtp  rfc  email-client  bounce 

4
การสนับสนุน Data URI ในซอฟต์แวร์ไคลเอนต์อีเมลหลักคืออะไร
URI ข้อมูลเป็นวิธีมาตรฐานในการฝังรูปภาพและข้อมูลไบนารีอื่น ๆ ใน HTML และการสนับสนุนเบราว์เซอร์ได้รับการบันทึกไว้อย่างดีบนเว็บ (IE8 เป็นเวอร์ชันแรกของ IE ที่รองรับ Data URI โดยมีขนาดสูงสุด 32 KB ต่อ URI เบราว์เซอร์หลักอื่น ๆ รองรับได้นานกว่า) คำถามของฉันเกี่ยวกับซอฟต์แวร์ไคลเอ็นต์อีเมลเดสก์ท็อปและเว็บเมล เมื่อสร้างอีเมล HTML แนวปฏิบัติมาตรฐานคือการรวมรูปภาพเป็นไฟล์แนบหรือโหลดจากภายนอก (เช่นการติดตามรูปภาพ) ทั้งสองอย่างนี้มีข้อเสีย (ไคลเอนต์บางรายแสดงรายการไฟล์ที่แนบมาทั้งหมดเหล่านี้ในขณะที่หลายไฟล์ปิดกั้นอย่างถูกต้องหรือต้องการให้ผู้ใช้ดำเนินการเพื่อดูรูปภาพภายนอก ดังนั้น Data URI จึงดูเหมือนเป็นวิธีที่ดี แต่ก็ต่อเมื่อผู้อ่านอีเมลรองรับเท่านั้น ใครมีลิงค์ไปยังการศึกษาล่าสุดเกี่ยวกับการสนับสนุนสำหรับคุณลักษณะนี้หรือไม่? หรือสอบสวนเรื่องนี้เลย? ตัวอย่างต่อไปนี้เป็นภาพรวมของการสนับสนุน CSS ซอฟต์แวร์ไคลเอ็นต์ที่ฉันสนใจ ได้แก่ : เดสก์ท็อป (รวมถึงข้อมูลเวอร์ชัน): Outlook, Apple Mail, Thunderbird, Evolution, Lotus Notes, AOL, Eudora …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.