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 헤더를 메시지에서 생략하는 경향이 있습니다.
저도 같은 경험입니다. Bcc로 받은 이메일에서 제 이메일 주소를 본 적이 있는지 기억나지 않습니다.
@zogstrip 혹시 어떤 문제가 일어나고 있는지 아시나요?
해당 커밋에서 add support for incoming emails in CC/BCC fields · discourse/discourse@93d1cc6 · GitHub (구체적으로는 discourse/lib/email/receiver.rb at 93d1cc6294085008e025bb3032b231a6a81c6480 · discourse/discourse · GitHub) envelope에 체크 로직이 있었던 것 같지만, 최근 버전의 receiver.rb에서 리팩토링된 것으로 보입니다.
@k4rtik 님이 강조한 변경 사항이 다시 원상복구될 가능성이 있을까요? 최근 이 문제를 겪고 있습니다. 우리 사용자는 BCC를 통해 업데이트를 보내기를 원합니다.