用于传递邮件列表邮件的正确电子邮件标头

发布于 2024-11-16 05:32:04 字数 541 浏览 3 评论 0 原文

我正在编写一个应用程序,允许用户将电子邮件发送到动态创建的邮件列表。例如,用户可以将电子邮件发送到 [email protected](网站是体育联盟的联盟管理网站),电子邮件将发送给该​​网站上的每个人用户团队。我试图弄清楚电子邮件标题应该是什么,以便正确发送电子邮件并使所有“发件人”和“收件人”字段看起来正确。

在 Gmail 中,当您从邮件列表收到一封电子邮件(我正在查看来自 google groups 的电子邮件)时,它会说该电子邮件来自发送者,并且已发送到列表地址,但该电子邮件是交付给我。我的地址不会出现在除“Delivered-To:”标头之外的任何标头中。这是谷歌的魔法吗?或者我也可以做同样的事情吗?

额外问题:我正在使用 Postfix+OpenDKIM 来签署电子邮件。如果发件人域与我指定的域匹配,它将对该邮件进行签名,但如果发件人域匹配,则不会签名。我怎样才能告诉它使用发件人域。

I'm writing an application that allows users to send email to dynamically-created mailing lists. For example, a user can send an email to [email protected] (the site is a league management site for sports leagues) and the email will be sent to everyone on that users's team. I'm trying to figure out what the email headers should be to deliver the email correctly and make all the From and To fields look right.

In Gmail, when you get an email from a mailing list (I'm looking at an email from google groups), it says that it came from the person who sent it and that it was sent to the list address, yet the email was delivered to me. My address doesn't appear in any of headers except in the Delivered-To: header. Is that some Google magic, or can I do the same thing?

Bonus question: I'm using Postfix+OpenDKIM to sign the emails. It will sign the message if the From domain matches the one I specified, but not if the Sender domain matches. How can I tell it to use the Sender domain instead.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

若言繁花未落 2024-11-23 05:32:05

看起来 OpenDKIM 总是使用 From: 标头,因此您必须仅签署所有电子邮件。请参阅了解说明。

Looks like OpenDKIM always uses the From: header so you have to resort to just signing all your emails. See this for instructions.

救星 2024-11-23 05:32:04

From: 和 To: 标头用于“显示目的”(这是在用户电子邮件应用程序中显示为发件人和收件人的内容)。它们不必与电子邮件的真实发件人/收件人相匹配,这些发件人/收件人称为“信封发件人”/“信封收件人”,并在 smtp 协议中指定(“MAIL FROM:....”“RCPT TO. ..”)。

示例:

邮件来自[电子邮件受保护] ,转到 [电子邮件受保护] 并正在传送至 [电子邮件受保护]

从 Alice 到列表服务器:

信封发件人:[电子邮件受保护]
信封收件人:[电子邮件受保护]
来自标头:[电子邮件受保护]
收件人 标头:[电子邮件受保护]

从列表服务器到鲍勃:

信封发件人:[email protected] (因此错误消息将发送到列表服务器,而不是 alice! )
信封收件人:[电子邮件受保护]
From 标头:[email protected] (Bob将 Alice 视为发件人,这不会被列表服务器修改)
收件人 标头:[email protected](再次,不被列表服务器修改)

可选:回复标头:[电子邮件受保护] (因此,如果鲍勃按下回复,回复将进入列表- 由列表服务器添加) - 请注意:有些人不喜欢 回复标头修改

其他标头:

一些电子邮件客户端还可以理解这些附加标头,并向用户提供特殊的邮件列表功能:

  • list-Id
  • list-Post
  • list-help
  • 列表取消订阅
  • 列表所有者

https://www.ietf.org/rfc/rfc2919 .txt
https://www.ietf.org/rfc/rfc2369.txt

另外,您可以添加一个标头

Precedence: bulk

,例如告诉智能外出实施不要向列表发送外出回复。但 RFC 2076 不鼓励这样做。

From: and To: headers are for 'display purposes' (this is what is presented in the users email application as sender and recipient). They don't have to match to the real sender/recipient of a email message which are called "envelope sender"/"envelope recipient" and are specified in the smtp protocol ("MAIL FROM:...." "RCPT TO...").

Example:

Mail comes from [email protected], goes to [email protected] and is being delivered to [email protected]:

From Alice to The list Server:

Envelope Sender: [email protected]
Envelope Recipient: [email protected]
From Header: [email protected]
To Header: [email protected]

From the list Server to bob:

Envelope Sender: [email protected] (so error messages go to the list server, not to alice!)
Envelope Recipient: [email protected]
From Header: [email protected] (Bob sees Alice as the sender, this is not modified by the list server)
To Header: [email protected] (again, not modified by the list server)

Optional: Reply-To header: [email protected] (So, if bob presses reply, the reply goes to the list - added by the list server ) - beware: some people do not like reply-to header munging

Additional headers:

Some email clients also understand these additional headers and present special mailinglist features to the user:

  • list-Id
  • list-Post
  • list-help
  • list-unsubscribe
  • list-owner

https://www.ietf.org/rfc/rfc2919.txt
https://www.ietf.org/rfc/rfc2369.txt

Also, you could add a header

Precedence: bulk

which for example tells intelligent out-of-office implementations not to send out-of-office replies to the list. But this is discouraged by RFC 2076.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文