怎么用英文回复客户这封邮件？

Posted 2023-04-17

) B/L : Copy of B/L not mentioned 14 days free Container detention at destination Port. ( As per confirmation of draft Copy of B/L free Period is mentioned. ) Please mention on Original B/L 14 days free Period OR Arrange 14 days free Period Certificate from Shipping line.

2) Com. Inv : Rcd. Copy of Com. Inv. Advance Payment is not deducted. Please deduct advance Payment from Inv. &send us revised Copy of Com. Inv.

我的回复“1、我已经申请了14天免堆，但是这家船公司不会显示在提单正本上，等收到船公司关于14天免堆确认的邮件我会第一时间转发给你
2、下周一我会将修改的发票发给你。
请及时安排支付余款，这对我们很有帮助。

谁帮我用英语回复一下这个邮件，回复的内容意思如上所述。回答的好可以追加分。
在线等。。。

参考技术A OK!!I will prepare for it!!

是否有“无回复”电子邮件标题？

【中文标题】是否有“无回复”电子邮件标题？

【英文标题】：Is there a "no-reply" email header?

【发布时间】：2012-03-24 08:45:32

【问题描述】：

我经常看到自动发送的电子邮件后缀有类似

亚马逊：

*请注意：这封电子邮件是从一个不能接受来电的地址发出的。如果您需要就同一问题再次与我们联系，请使用上面的链接。

推特：

请不要回复此消息；它是从一个不受监控的电子邮件地址发送的。此消息是与您使用 Twitter 相关的服务电子邮件。

谷歌结帐：

需要帮助吗？访问 Google Checkout 帮助中心。请不要回复此消息。

在此警告的正下方，Gmail 向我显示了一个回复输入字段。在我看来，应该有某种标题可以附加到这样的自动电子邮件中，告诉收件人的电子邮件客户端不允许回复。

有这样的标题吗？如果没有，控制电子邮件格式的小组是否曾讨论过它？

【问题讨论】：

这个链接是关于转发的，但还有一个选项可以禁用回复或回复所有收件人：makeuseof.com/tag/prevent-emails-forwarded-outlook-gmail - 有人知道它在下面是如何工作的（电子邮件标题？）

【参考方案1】：

有这样的头吗？

没有。我很确定没有这样的事情。即使有，它也是非标准的，也没有得到广泛支持，所以目前它几乎没用。即使它成为标准，任何这样的标题也可能只是信息性的；并且为了向后兼容，电子邮件客户端的支持必须完全是可选的。 客户端实现它的速度会很慢，而且许多用户仍然使用旧版本的邮件客户端。

如果没有，控制电子邮件格式的小组是否曾讨论过这个问题？

大概吧。人们已经有很长时间通过电子邮件提出各种建议，但我的直觉是它永远不会被实施。好吧...除非电子邮件的设计目的发生根本性转变，否则不会。 我敢肯定，如果你在给你发邮件时甚至没有“回复”按钮，谷歌会更开心，所以如果有人在推动它，那将是那些已经从donotreply@...发送邮件的人

电子邮件旨在从真实邮箱发送。 RFC 2822 和 RFC 5322 说：

在所有情况下，“发件人：”字段不应包含任何邮箱 不属于消息的作者。

对我来说，这清楚地表明电子邮件被设计为一种对话方式，而不是广播。

任何改变的最大杀手可能是那条线上方的一点点，需要完全重新定义；这将导致比解决的问题更多的问题：

发起人字段还提供了以下情况所需的信息 回复消息。当“回复：”字段存在时，它 表示消息作者建议的地址 发送回复。在没有“回复：”字段的情况下， 默认情况下，回复应该发送到指定的邮箱 “发件人：”字段，除非撰写人另有说明 回复。

【讨论】：

我强烈反对您认为邮箱应该属于邮件作者的解释。不回复电子邮件属于作者，期待没有对话......

【参考方案2】：

不，没有no-reply 标头。

但是，您可以添加一个空的reply-to 标头：

reply-to: <>

根据RFC 5322, Section 3.6.2 有效。不幸的是，RFC 从未真正指定空的reply-to 字段的含义。我认为大多数电子邮件客户端都会忽略它。

【讨论】：

您如何得出Reply-To: <> 有效的结论？获取尖括号的唯一方法是使用angle-addr = [CFWS] "<" addr-spec ">" [CFWS]。如果您查看addr-spec = local-part "@" domain，您可以立即知道至少需要一个@ - 而无需检查local-part 或domain 是否可以为空（它们不能）。

【参考方案3】：

RFC 6854 更新RFC 5322 以允许在From 字段中使用组构造（除其他外）。组可以为空，这可能是您见过使用组语法的唯一方式：undisclosed-recipients:;。

RFC 的Section 1 在From 字段中允许组构造的动机中明确列出了“无回复”：

“发件人：”字段的用例已经发展。有许多自动化系统实例希望发送电子邮件但无法处理回复，而没有可用地址的“发件人：”字段对于此目的非常有用。

它提供了以下示例：From: Automated System:;

但是，在同一部分的末尾，RFC 还说：

本文档目前建议不要在这些字段中普遍使用组语法

在section 3 中，RFC 阐明From 字段中的组语法仅适用于Limited Use。

我个人认为不应该使用这种方法——除非我们确定所有相关客户端都以其他方式显示原始域（从Return-Path 或新标头重构）。否则，这会破坏域身份验证（SPF、DKIM 和 DMARC）的所有努力。引入一个额外的标题字段，让客户简单地隐藏回复按钮，这对我来说似乎是更好的方法。

section 5 中关于这方面的 RFC cmets：

某些协议尝试通过将“发件人：”地址与特定的已验证域匹配来验证始发者地址（有关此类协议的一种，请参阅作者域签名实践 (ADSP) 文档 [RFC5617]）。此类协议不适用于在“发件人：”字段中缺少实际电子邮件地址（无论是真实的还是虚假的）的邮件。本地政策将决定此类邮件的处理方式，因此发件人需要注意，在“发件人：”中使用组可能会对邮件的可传递性产生不利影响。

多么失败的机会……