Continuing the discussion from Replacing Mailing lists: Email-In:
Sorry if this is already discussed. It’s rather hard to search for the 2-character “CC” on Discourse. 
Is there (ever or still) a valid reason to reject emails where the Discourse email address is on the CC or BCC line? If so, what’s the rationale? We have had this happen a few times recently with confused users.
I was asked about this on Monday. A user wanted to send an email to a consultant with a cc to our staff mailing list on discourse. The idea she had (I think) was to enable staff to reply to both consultant and staff for follow up.
This doesn’t have predictable results and so I encouraged her to write two separate emails. One to staff and another to the consultant. Otherwise if the consultant replies all it will generate an error from discourse, and the replies from the staff won’t get to the consultant.
Discourse and email are like oil and water, sadly. But folks are getting used to it and we’re getting good results.
Our scenario is quite similar. The questions come from addresses (aliases) associated with specific categories that are handled like team distribution lists, like yours.
Seems to really confuse users. How best to improve the experience? At a minimum, I think the error message here could be improved.
OK, what does it currently say and what do you think it should say?
Discourse fires off the “I didn’t recognize that To: address” error reply if it’s in the CC:.
Here’s an important question: What part of the email should be posted?
It will be difficult to strip out the email addresses from the “Forwarded Message” block, as (of course!) every email client will do it differently.
If it is not wanted to let in emails send to a category through Cc: or Bcc: I at least want to suppress the reject email. What do you think?
Reason is I currently try to move people away from using email and get them used to Discourse. So I let Discourse harvest emails send to some mailinglists. As soon as there is such an mailinglist address added to the Cc: field instead of To: the sender gets confronted with the reject email send by Discourse. This is confusing people.
Has there been any change in this behavior with 1.5, @zogstrip?
When an email is received, we look for email addresses in all the destinations fields (To, Cc and Bcc). If at least one matches a reply address, a group or a category incoming email address, then the mail will be processed.
也许我漏掉了什么，但好像根本没有 Bcc: 这个邮件头？
我确实看到 Discourse 的源代码中检查了它，但 Bcc 的初衷不就是这些邮箱地址永远不会出现在邮件头中吗？
BCC 是一个有效的邮件头选项，如果收件人地址未包含在邮件头中，邮件将无法送达该收件人。
一旦包含多个收件人的邮件到达邮件传输代理（MTA），系统会按每位收件人单独发送。位于“to”或“cc”字段的用户将看到一个不包含 BCC 的邮件头，而被密送（BCC）的用户则会看到自己的地址被明确标注为 BCC：
路由是根据 RFC821 信封执行的，邮件头并不用于此目的。
我做了进一步研究，发现规范中确实存在 Bcc 头，但我从未见过它被使用。
在实际操作中，MTA 和/或电子邮件客户端似乎会在消息中省略 Bcc 头，即使消息是发送给 Bcc 中的收件人的。
[quote=“RGJ, 第 11 楼，主题 25985”]
MTA 和/或电子邮件客户端似乎会在消息中省略 Bcc 头，即使消息已发送给 Bcc 中的收件人之一。[/quote]
这也是我的经历。我不记得曾在发给我（通过 Bcc）的邮件中看到过我的电子邮件地址。
@zogstrip 您是否知道可能出了什么问题？
似乎在这个提交中曾经有过一个检查：https://github.com/discourse/discourse/commit/93d1cc6294085008e025bb3032b231a6a81c6480（具体见 discourse/lib/email/receiver.rb at 93d1cc6294085008e025bb3032b231a6a81c6480 · discourse/discourse · GitHub receiver.rb 中似乎已被重构。
@k4rtik 提到的更改有重新实施的可能吗？我最近遇到了这个问题。我们的用户希望通过密送（BCC）发送更新。