1 คะแนน โดย GN⁺ 2024-07-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • reactions ของ Outlook อาจถูกส่งมาเป็นอีเมลแยกเมื่ออยู่นอกระบบนิเวศของ Microsoft ทำให้ผู้ส่งได้รับอีเมลแจ้งเตือนที่ไม่ต้องการเพิ่มขึ้น
  • Microsoft มีเฮดเดอร์เฉพาะสำหรับอีเมลขาออกคือ x-ms-reactions: disallow ซึ่งเมื่อใส่แล้วจะยับยั้ง ฟังก์ชันตอบกลับด้วย reaction ของไคลเอนต์
  • แทนการตั้งค่าแยกตามไคลเอนต์ ผู้เขียนใช้ Postfix header_checks เพื่อแทรกเฮดเดอร์นี้อัตโนมัติในอีเมลขาออกทั้งหมด ลดโอกาสตกหล่นตามบัญชีหรืออุปกรณ์
  • จากการทดสอบ พบว่าไคลเอนต์บางตัวแสดงปุ่มต่อไป แต่การส่ง reaction ล้มเหลวที่ฝั่งเซิร์ฟเวอร์ ขณะที่บางสภาพแวดล้อมปุ่มถูกทำให้เป็นสีเทา
  • แม้จะใช้เฮดเดอร์เดียวกัน แต่การแสดงผล UI ในไคลเอนต์ Microsoft แต่ละตัวต่างกัน ผู้ส่งจึงลดอีเมล reaction ได้ แต่ประสบการณ์ของผู้รับยังไม่สม่ำเสมอ

อีเมล Outlook reactions ที่ไม่ต้องการ

  • ในช่วงไม่กี่เดือนที่ผ่านมา มีคำตอบกลับต่ออีเมลที่ส่งไปในรูปแบบ reactions เพิ่มขึ้น
  • ภายในระบบนิเวศของ Microsoft ดูเหมือนจะถูกจัดการคล้ายปฏิกิริยาอย่าง 👍 หรือ ❤️ ใน Signal แต่เมื่อนอกระบบจะมาถึงเป็นอีเมลแยก
  • เนื้อหาอีเมลที่ได้รับมีลักษณะดังนี้
    • like [person] reacted to your message:
  • like เป็นข้อความทดแทน และหากไม่อนุญาตให้โหลด remote content ก็จะไม่เห็นรูปภาพ
  • เนื่องจากไม่ต้องการอีเมล reaction แบบนี้ จึงเพิ่มเฮดเดอร์สำหรับบล็อกลงในอีเมลขาออก

เพิ่ม x-ms-reactions: disallow ใน Postfix

  • Microsoft มีเฮดเดอร์ x-ms-reactions: disallow สำหรับ Outlook reactions
  • เมื่อกำหนดเฮดเดอร์นี้ไว้ สามารถเข้าใจได้ว่าฟังก์ชันตอบกลับด้วย reaction จะถูกยับยั้งในไคลเอนต์ของ Microsoft
  • หากเมลไคลเอนต์/MUA รองรับการเพิ่มเฮดเดอร์ ก็สามารถตั้งค่าแยกในแต่ละไคลเอนต์ได้ แต่ถ้าใช้หลายไคลเอนต์ก็ต้องตั้งค่าแต่ละตัว
  • เพื่อให้มีผลกับอีเมลขาออกทั้งหมด จึงเพิ่มเข้าไปใน การตั้งค่า Postfix
    • มีการตั้งค่าต่อไปนี้ใน /etc/postfix/main.cf
header_checks = pcre:/etc/postfix/header_checks
  • เพิ่มกฎต่อไปนี้ใน /etc/postfix/header_checks
# add header to deal with unwanted Microsoft reactions (2024-07-16)
/^Date:/i PREPEND x-ms-reactions: disallow
  • ตอนแรกใส่ไว้ก่อน Content-Transfer-Encoding แต่เนื่องจากการตั้งค่า mutt ไม่ส่งเฮดเดอร์นั้น จึงย้ายไปไว้ก่อน Content-Type และหลังจากนั้นย้ายมาไว้ก่อนเฮดเดอร์ Date อีกครั้ง
  • หลังรีสตาร์ต Postfix ด้วย sudo service postfix restart ก็ทดสอบกับหลายไคลเอนต์ และพบว่าเฮดเดอร์ใหม่ถูกเพิ่มเข้าไปใน message header อย่างถูกต้อง

ผลการทดสอบในไคลเอนต์ Microsoft แต่ละตัว

  • จากการทดสอบร่วมกับผู้ใช้ Microsoft หลายคน พบว่าในบางสภาพแวดล้อมการทำงานเป็นไปตามเป้าหมาย
  • ในกรณีหนึ่ง แม้จะเพิ่มเฮดเดอร์แล้ว ตัวไคลเอนต์ของผู้ใช้ Microsoft ก็ยังคงแสดงตัวเลือก reaction
    • ผู้ใช้กด reaction ได้ แต่ไม่ไปถึงเมลเซิร์ฟเวอร์ของผู้ส่ง
    • การอัปเดตที่ทำให้ปุ่มเป็นสีเทาในแต่ละไคลเอนต์ทยอยปล่อยด้วยความเร็วต่างกัน และการพยายามส่ง reaction กับอีเมลที่ไม่อนุญาตจะ ล้มเหลวที่ฝั่งเซิร์ฟเวอร์
  • ในสภาพแวดล้อมของผู้ใช้ Microsoft รายอื่น ไอคอน reaction ถูกทำให้เป็นสีเทา และมี hover text แสดงว่า Reactions are disallowed on this message
  • รูปแบบการแสดงผลดูแตกต่างกันไปตามระบบของ Microsoft ดังนั้นในมุมของผู้ส่ง แม้จะบรรลุเป้าหมายในการไม่รับอีเมล reaction แต่ประสบการณ์ของผู้ใช้ก็ยังไม่ถือว่าเหมาะนัก

1 ความคิดเห็น

 
GN⁺ 2024-07-17
ความคิดเห็นจาก Hacker News
  • ถ้าเป็นบริษัทที่ใช้แต่ Outlook อย่างเดียว ฟีเจอร์ reaction ก็ถือว่าเข้าท่าทีเดียว เพราะมันช่วยลดอีเมลแนว “ดีครับ/ค่ะ ขอบคุณครับ/ค่ะ” ลงไปได้เยอะมาก
    แน่นอนว่าเวลารู้สึกขอบคุณจริง ๆ ก็ส่งอีเมลขอบคุณให้เป็นเรื่องเป็นราวได้

    • ตอนที่มีประกาศความสำเร็จหลายอย่างของทั้งองค์กร อีเมล “Congratulations / Congrats” เข้ามาบ่อยและเยอะเกินไป จนถึงขั้นสร้าง ฟิลเตอร์ลบอัตโนมัติ ไว้เลย ถึงอย่างนั้นอีโมจิพลุก็ยังทำให้ทนได้มากกว่ามาก
    • ผม/ฉันไม่ใช่ผู้ใช้ Outlook และเกลียดผลิตภัณฑ์นี้จริง ๆ แต่ฟีเจอร์ที่เขียนแบบ @joel เพื่อดึงความสนใจของใครสักคนในเธรดอีเมลใหญ่ ๆ ที่มีคนอยู่ใน CC เยอะเกินไปนั้น อยากให้ไคลเอนต์อีเมลอื่น ๆ รองรับมากขึ้น
    • ในบริบทแบบนั้น reaction ก็อาจสมเหตุสมผล เพราะมีความเป็นไปได้สูงว่าแต่แรกแล้วการโต้ตอบแบบนี้เป็น สถานการณ์ที่ไม่ควรใช้อีเมล
      ที่เกี่ยวข้อง: https://news.ycombinator.com/item?id=28636536
    • ตามอุดมคติก็คงเป็นแบบนั้น แต่สิ่งที่เห็นจริงต่างออกไป ในองค์กรของเรา คนส่งทั้ง reaction และยังส่งอีเมลตอบกลับทั้งหมดแบบนี้ด้วย สุดท้ายก็แค่มี สิ่งรบกวน เพิ่มขึ้น
    • สงสัยว่าคนเราตอบอีเมลงานแค่ “ดีครับ/ค่ะ ขอบคุณครับ/ค่ะ” กันจริง ๆ จนรบกวนขนาดนั้นเลยหรือ อย่างเช่นกรณีอีเมลที่มีผู้รับจำนวนมาก
  • Apple ก็ใส่ฟีเจอร์เดียวกันใน iMessage/SMS ถ้าข้อความกลุ่มมีแต่ผู้ใช้ Apple ทั้งหมด มันก็ทำงานตามที่คาดไว้ แต่คนโชคร้ายที่อยู่นอก ecosystem จะโดนข้อความถล่มแบบ ‘{person} liked “{message}”
    บางกรณีคนยังไป reaction ต่อ reaction นั้นอีก จนเกิดเป็น chain ข้อความที่ไร้สาระ

    • นึกถึงสมัยที่ Microsoft ออกไคลเอนต์ Microsoft Comic Chat สำหรับ IRC มีคนที่เข้าช่อง IRC พร้อม metadata สารพัดเกี่ยวกับตัวละครของตน สำหรับพวกเขาก็คงโอเค แต่สำหรับทุกคนที่ใช้ไคลเอนต์ทั่วไปมันน่ารำคาญมาก
      คงถูกออกแบบมาให้ใช้กับเซิร์ฟเวอร์ MSN แต่ผู้คนก็เอาไปเชื่อมต่อกับเซิร์ฟเวอร์ “ทั่วไป” ด้วย
      https://en.wikipedia.org/wiki/Microsoft_Comic_Chat
    • ตลกดีที่พูดเป็นอดีตกาล เพราะเรื่องนี้ยังเกิดขึ้นอยู่ตอนนี้ ผม/ฉันอยู่นอกสหรัฐฯ แต่ยังคงเบอร์ Google Voice ไว้ และยังได้รับข้อความแบบนี้ในแชตกลุ่มครอบครัวอยู่เรื่อย ๆ
      อย่างน่าอัศจรรย์คือส่วนใหญ่ย้ายไป Signal กันแล้ว แต่บางทีก็กลับไปใช้ นิสัย SMS เดิม ๆ
    • ในฐานะผู้ใช้ Android มักสงสัยว่าผู้ใช้ Apple รู้ไหมว่าคำตอบของตัวเองดูงี่เง่าแค่ไหนสำหรับผู้ใช้ที่ไม่ใช่ Apple ลังเลอยู่ว่าควรบอกดีไหมหรือปล่อยผ่านไป
  • จำได้ว่าเคยเห็นบางคนในอีเมลบริษัทใส่ตัว J พิมพ์ใหญ่แทนจุด full stop ท้ายประโยค ตอนแรกคิดว่าเพราะรูปทรงตะขอของ J ดูเหมือนหน้ายิ้ม เลยคงเป็นการแสดงมารยาทแบบองค์กรที่ไม่โจ่งแจ้งเกินไป
    ปรากฏว่าค่า J ใน ASCII คือ 0x4A และตำแหน่งนั้นใน Wingdings เป็นหน้ายิ้ม ถึงตอนนี้ก็ยังไม่ค่อยเข้าใจว่าไคลเอนต์อีเมล Outlook รู้ได้อย่างไรว่าควรแปลงอักขระไหนใน UI

    • น่าจะเป็นเพราะแท็กในอีเมล คงต้องเป็น อีเมล HTML: https://devblogs.microsoft.com/oldnewthing/20060523-10/?p=31...
    • ในอีเมลที่แม่ส่งจากที่ทำงาน บางครั้งเห็น J โผล่มา มันตลกมาก ตัวอักษรแรกของชื่อผม/ฉันคือ J เลยคิดว่าแม่หมายถึงเรา แต่จริง ๆ แล้วแม่กำลังส่ง หน้ายิ้ม อยู่
    • การที่อีโมติคอนถูกเปลี่ยนเป็น Wingdings J เกิดขึ้นที่ ระดับเซิร์ฟเวอร์ อีเมลที่ส่งผ่านเซิร์ฟเวอร์ Exchange จาก Mutt แล้วถูกอ้างอิงกลับมาหาผม/ฉัน มีหน้ายิ้ม ASCII ถูกเปลี่ยนเป็น J ไปแล้ว
      Exchange แปลงอีเมลทุกฉบับที่ผ่านเข้ามาเป็น HTML แล้วห่อ J ด้วยแท็กเพื่อเลือก Wingdings การติดตั้ง Exchange บางแห่งไม่ได้ให้สำเนา plain text ของอีเมลที่ผ่านออกไป
    • ในอีเมลอาจมีทั้งรูปแบบ HTML และ plain text และอาจเป็นเพราะตั้งค่าไคลเอนต์ให้ แสดงเฉพาะ plain text ไว้
    • ผม/ฉันเองก็งงกับตัว J นี้อยู่นาน และตอนเริ่มทำงานประจำบริษัทครั้งแรก คิดว่าเป็นวัฒนธรรมองค์กรอะไรสักอย่าง
      ต้องใช้เวลาหลายปีกว่าจะได้รับแล็ปท็อป Windows แล้วเปิดดูอีเมลใน Outlook
  • ฝั่งที่ไม่ชอบ reactions ช่วยอธิบายหน่อยได้ไหมว่าอะไรที่ทำให้ไม่พอใจขนาดนั้น รู้สึกว่าเสียมารยาทเพราะอีกฝ่ายไม่แม้แต่จะพยายามพิมพ์หรือเปล่า? ผมไม่ค่อยเข้าใจว่าปัญหาคืออะไร

    • ผมให้คุณค่ากับ สมาธิ ของตัวเอง ไม่อยากใช้มันไปกับคำตอบที่ถูกสร้างขึ้นมาแบบประดิษฐ์ ถ้าใครอยากสื่อสารกับผม ก็ควรลงแรงขั้นต่ำบ้าง
      ก่อนยุคอีเมล การเขียนจดหมายต้องใช้ความพยายาม และนั่นช่วยกรองการติดต่อที่มีอัตราสัญญาณต่อสัญญาณรบกวนต่ำออกไป ข้อความอย่างสแปม เนื้อหาที่ LLM สร้าง หรือ reactions จะถูกโยนลงถังขยะทันที ผมมองว่าการที่ผู้ส่งทำให้ผมต้องเสียเวลาเห็นข้อความนั้นแล้วกดปุ่มลบ ไม่ใช่เรื่องเสียมารยาทเท่ากับเป็น การกระทำที่ขาดวิจารณญาณ
      อาจฟังดูหยิ่ง แต่บางวันผมได้รับอีเมลเป็นร้อยฉบับ จึงเป็นตัวกรองที่จำเป็น
    • ผมก็เหมือนผู้เขียน คือปิด รูปภาพระยะไกล ในอีเมลไว้ ดังนั้นตั้งแต่แรกก็ไม่ได้รับ “ประสบการณ์ที่ตั้งใจไว้” อยู่แล้ว จริง ๆ แล้วมีใครนอกจากผู้ใช้ Outlook ที่ได้รับประสบการณ์ตามที่ฟีเจอร์นี้ตั้งใจไว้บ้างไหม?
      อย่างที่สอง “reaction” ไม่ได้เป็นส่วนหนึ่งของวัฒนธรรมอีเมลหรือข้อกำหนดมาตรฐานของอีเมล มันเหนือความคาดหมายและดูขัด ๆ
      ดังนั้นโดยทั่วไปไม่ได้เกลียด reactions แต่คัดค้านฟีเจอร์ที่ทำงานได้เฉพาะในแอปเมลของ MS และไปโผล่ในรูปแบบพัง ๆ ที่อื่น
    • ในอีเมล มันกลายเป็นแค่สิ่งน่ารำคาญที่ทำให้กล่องจดหมายบวมขึ้น ไม่ใช่เรื่องใหญ่ แต่ถ้ากรองออกได้ ประสบการณ์จะดีขึ้น
      reactions สมเหตุสมผลกว่าในรูปแบบการสื่อสารอย่าง instant messaging ที่มีการสนทนาแบบเรียลไทม์และความสั้นกระชับสำคัญ ในอีเมลมันไม่ได้เพิ่มอะไรเป็นพิเศษ
    • มีปัญหาอยู่สองอย่าง มันไม่ใช่มาตรฐาน แต่ Microsoft สมมติเอาเองว่าคนส่วนใหญ่ใช้ Outlook แล้วก็ทำไปเลย ไม่ได้สนใจว่ามันจะทำงานอย่างไรกับคนอื่น
      อย่างที่สอง การได้รับ reaction ในอีเมลหมายความว่าอะไร? จะตีความ “ยกนิ้วโป้ง” ว่าเป็นสัญญาณให้เดินหน้าต่อได้ หรือแค่ “เห็นแล้ว ได้รับเมลแล้ว” ก็ไม่ชัดเจน ถ้าเห็นพ้องกันในระดับหนึ่งว่าอีเมลโดยทั่วไปเป็น เครื่องมือทำงานที่สำคัญ ก็ควรสื่อสารให้ชัดเจนและแม่นยำ reactions เป็นสิ่งตรงข้าม และถูกเข้าใจผิดได้ง่ายกว่าโดยขึ้นกับบริบท วัฒนธรรม และอารมณ์ของผู้รับ
      อาจมีกรณีใช้งานอีเมล reactions ที่ยอดเยี่ยมและสมเหตุสมผลมาก ๆ ก็ได้ แต่ยากจะเชื่อจริง ๆ ว่า Microsoft ให้ผู้เชี่ยวชาญ UI/UX ไปศึกษามาอย่างเหมาะสม ได้ข้อสรุปชัดเจน แล้วจึงนำไปใช้งาน พอเห็นว่ามันไม่ใช่มาตรฐาน ก็รู้สึกเหมือนทำขึ้นบ่ายวันศุกร์เพื่อโชว์ว่า “เราทำแบบนี้ได้” วิธีพ่วงไปกับ SMTP header ก็มีกลิ่นของการแฮ็กแบบคลาสสิก
    • การแจ้งเตือนยกนิ้วโป้งกับการตอบว่า “OK” โดยเนื้อแท้ไม่ได้ต่างกันมาก ทั้งสองอย่างรบกวนผมตอนที่กำลังจดจ่อกับงานที่มีความหมาย และแย่งชิงสมาธิอันมีค่าของผมด้วยเสียง การสั่น แบนเนอร์ ป๊อปอัป
      ผมพยายามควบคุมสมาธิมาตลอดชีวิต แต่เหมือนมนุษยชาติทั้งโลกตั้งใจจะเติมสภาพแวดล้อมร่วมกันด้วย สิ่งรบกวนสมาธิ ให้มากขึ้น มันแย่มากและมีลักษณะชักจูงจัดการ อยากให้ปิดได้ อยากให้ปล่อยผมไว้เฉย ๆ ยิ่งไปกว่านั้น อยากให้ช่วยผมจดจ่อกับสิ่งที่ผมให้คุณค่า
  • พอเข้าใจอยู่บ้างว่าทำไมถึงไม่ชอบสิ่งนี้ในอีเมล แต่ใน SMS และ Slack ผมใช้ ฟีเจอร์ reaction อย่างสนุกมาก เพราะมันเป็นวิธีบอกว่า “ได้รับแล้ว มีปฏิกิริยาเชิงบวก และไม่มีอะไรต้องพูดเพิ่ม”
    มันแทนที่การต้องพิมพ์อะไรไร้สาระอย่าง “ดีครับ ไม่มีอะไรเพิ่มเติม” เพื่อให้ดูสุภาพได้มาก และผมเกลียดมากเมื่ออีกฝ่ายส่งการแจ้งเตือนยืนยันกลับมาอีกครั้งต่อการยืนยันของผม

    • เพื่อนคนหนึ่งเคยฝึกงานที่ FAA เมื่อ 20 ปีก่อน เขาบอกว่าที่นั่นมีธรรมเนียมเขียนว่า “Concur without comment.” ผมคิดว่ามันยอดเยี่ยมจริง ๆ
      แน่นอนว่าถ้าผมใช้ในบทสนทนา คงไม่มีใครเข้าใจว่าเป็นคำอ้างอิง แล้วจะมองว่าผมแปลก ๆ ซึ่งก็คงเกิดขึ้นอยู่ดี
    • สำหรับข้อความเล็ก ๆ น้อย ๆ การตอบแบบ Picard ว่า “ACKNOWLEDGED” ควรเป็นที่ยอมรับทางสังคมโดยสมบูรณ์
    • ตอนนี้ Gmail ก็มี emoji reactions แล้ว ตัวอย่างเช่นดูหน้ายิ้มตรงนี้: https://imgur.com/a/0cYSLMQ
      เปิดตัวเมื่อปีที่แล้ว[1]
      [1] https://blog.google/products/gmail/gmail-emoji-reactions/
    • เห็นด้วย ไม่ได้คัดค้าน reactions เอง แต่คัดค้าน reactions ในอีเมล
    • ถ้า reactions ในอีเมลถูกจัดการอย่างงดงามภายในอินทราเน็ตของบริษัทก็โอเค แต่การส่งอีเมลแบบนั้นออกไปยัง อินเทอร์เน็ตสาธารณะ เป็นเรื่องไร้เหตุผล
  • วิธีแก้นี้ทำให้ DKIM พัง เพราะมีการแทรก header ใหม่ของ postfix
    ใน Thunderbird ก็ทำแบบเดียวกันได้โดยเข้าไปที่ตัวแก้ไขการตั้งค่า แล้วเพิ่ม header “x-ms-reactions: disallow” เองตามที่ระบุไว้ใน https://kb.mozillazine.org/Custom_headers

  • ทุกวันมีก้อนมะเร็งรูปแบบใหม่เกิดขึ้น

    • เหนื่อยจริง ๆ ที่เวลาอ่านบทความเทคโนโลยีแล้วรู้สึกว่า “ในวินาทีที่คิดว่าซอฟต์แวร์คงแย่ไปกว่านี้ไม่ได้แล้ว...” บ่อยเกินไป
  • reactions สมเหตุสมผลใน แอปแชต อย่าง MS Teams, Slack หรืออะไรก็ตามที่ดูเหมือนห้อง IRC
    ไม่รู้ว่า Microsoft ตัดสินใจใส่ตัวเลือกนี้ใน Outlook ไปทำไม

    • การใช้ reactions ในแอปแชตเป็นที่นิยมมาก แต่ผมไม่เคยเห็นว่ามันมีวัตถุประสงค์เชิงปฏิบัติอะไร ถึงอย่างนั้นเหตุผลที่ Microsoft ใส่มันลงใน Outlook ก็ดูชัดเจน
      เพราะมันเป็นที่นิยมในแอปแชต ใครบางคนใน Microsoft คงตัดสินใจว่าการใส่ฟีเจอร์ใหม่ยอดนิยมลงไปในของเก่า ๆ น่าเบื่อ ๆ จะดีต่ออาชีพของตัวเอง
  • พูดตรง ๆ ผมชอบไอเดียนี้พอสมควรเลย จะมีทางทำให้เป็น มาตรฐาน แล้วเพิ่มเข้าไปในไคลเอนต์อีเมลอื่น ๆ ได้ไหมนะ? ภายในแล้ว fallback ที่เป็นอีเมลธรรมดาที่คนอ่านได้ก็ถือว่าค่อนข้างเรียบร้อยดี
    แต่สงสัยว่าเขาจัดการกับภาษาที่ไม่ใช่อังกฤษอย่างไร เขารู้ภาษาของอีเมลหรือเปล่า? หรือเป็นอังกฤษเสมอ? ถ้าอย่างนั้นก็ไม่ดี
    ผมกำลังทำไลบรารีคอมโพเนนต์แชต (https://talkjs.com) และรองรับทั้ง emoji reaction กับการแจ้งเตือนทางอีเมลสำหรับข้อความแชตที่พลาดไป ถ้าตอบกลับอีเมลนี้ มันจะแสดงเป็นข้อความแชตในบทสนทนา การใส่การรองรับ reaction ลงในอีเมลด้วยก็ดูเป็นเรื่องธรรมชาติมาก แต่ถ้ามันเป็น UX ที่ยอดเยี่ยมสำหรับผู้ใช้ Outlook และกลายเป็น UX แย่ ๆ ที่มีอีเมล reaction เล็ก ๆ ถาโถมเข้ามาสำหรับคนอื่น ๆ ผมก็ค่อนข้างลังเล

    • ขอคัดสิ่งที่เคยพูดไว้ในเธรดอื่นมาตามเดิม จริง ๆ แล้วมีมาตรฐานสำหรับเรื่องนี้อยู่แล้ว: https://datatracker.ietf.org/doc/html/rfc9078
      น่าเสียดายที่ดูเหมือนจะยังไม่ได้รับการนำไปใช้อย่างแพร่หลาย: https://bugzilla.mozilla.org/show_bug.cgi?id=1724363
  • นึกถึง Microsoft Comic Chat ที่เคยทำให้ข้อความ IRC พังเพื่อส่ง metadata เพิ่มเติม