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 envelope، ولا تُستخدم رؤوس الرسائل لذلك.
لقد قمت ببعض البحث الإضافي، وهناك بالفعل رأس 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)، لكن يبدو أنه تم إعادة هيكلة في إصدارات أحدث من receiver.rb.
هل هناك أي احتمال أن تعود التغييرات التي أبرزها @k4rtik؟ لقد صادفت هذه المشكلة مؤخرًا. يرغب مستخدمونا في إرسال التحديثات عبر bcc.