Discourse إرسال إيميل مزدوج

مرحباً، أنا أستخدم Discourse المستضاف ذاتيًا على خادمي. أنا على أحدث إصدار تطوير حاليًا: Commits · discourse/discourse · GitHub

ألاحظ أن Discourse يرسل البريد الإلكتروني مرتين عندما يقوم مستخدم بالتسجيل أو يتلقى رسالة خاصة وما إلى ذلك.

يمكنني إعادة إنشاء هذا عند تسجيل مستخدم جديد. لا أعرف كيف يمكنني استكشاف هذه المشكلة أو ما هي المشكلة بالضبط أو ما إذا كانت هذه مشكلة في خادم البريد الإلكتروني الخاص بي… لقد وجدت بعض المواضيع المماثلة ولكنها قديمة ببضع سنوات لذلك أردت فتح موضوع جديد.

شكراً للمساعدة!

هل ترى أي معلومات في سجلات البريد الإلكتروني المرسلة لموقعك تتعلق بهذه رسائل البريد الإلكتروني؟ لاحظ أنه يمكنك استخدام المدخلات في أعلى تلك الصفحة لتصفية رسائل البريد الإلكتروني حسب المستخدم أو عنوان المستلم أو نوع البريد الإلكتروني:

إذا كان هذا خطأً، فسيكون من الجيد معرفة بالضبط ما هي رسائل البريد الإلكتروني المكررة التي يتم إرسالها.

ما نوع البريد الإلكتروني الذي تتلقاه عند تسجيل مستخدم؟ هل يخبرك أن هناك مستخدمين يتطلبون الموافقة؟

بالنسبة لرسائل البريد الإلكتروني المتعلقة بالرسائل الخاصة، هل هذه للرسائل التي أرسلها المستخدمون إليك؟

إعجابَين (2)

مرحباً،

في تلك الصفحة، حتى عندما يتم إرسالها مرتين، تظهر مرة واحدة فقط.

على الرغم من حدوث شيء غريب. مع نطاق protonmail.com لم يتم إرسال بريد مزدوج، ولكن مع anonaddy.com هناك بريد إلكتروني مزدوج. هذا يجعلني أعتقد أن هذه المشكلة قد تكون مرتبطة بخادم البريد وليس بـ Discourse.

على الرغم من أنني أتلقى رسائل بريد إلكتروني مزدوجة من نطاقي/خادم البريد الخاص بي أيضاً. هل يمكننا الوثوق بأنه إذا لم يتم عرض البريد الإلكتروني في صفحة الإرسال، فهذا يعني بنسبة 100% أن Discourse لا يرسل بريداً إلكترونياً مزدوجاً؟

شكراً لك.

إذا نظرت إلى رؤوس رسائل البريد الإلكتروني المزدوجة، فيجب أن تكون قادرًا على معرفة أين حدثت المشكلة.

تحقق من رؤوس “received-by” على وجه التحديد.

إعجابَين (2)

حسنًا، يبدو أن كلاهما قادم من Discourse إذا فهمت بشكل صحيح:

البريد الأول:

Return-Path: <SRS0=ll8P=FH=anonaddy.com=b_na4w2nlvmv3gizdenmya_gq4wmodfhfrwm@Mail Server>
Delivered-To: Email Address
Received: from mail2.anonaddy.me (mail2.anonaddy.me [***.***.***.***])
	by Mail Server (Postfix) with ESMTPS id A9132370DA
	for Email Address; Sat, 23 Sep 2023 11:06:42 +0300 (+03)
Received: from mail2.anonaddy.me (mail2.anonaddy.me [127.0.0.1])
	by mail2.anonaddy.me (Postfix) with ESMTPS id 64958FA584
	for Email Address; Sat, 23 Sep 2023 09:06:41 +0100 (BST)
DKIM-Signature: [Truncated]
From: [Sender]
To: Email Address
Subject: =?utf-8?Q?=5BBilin=C3=A7li?= Teknoloji
 =?utf-8?Q?T=C3=BCketicileri=5D_Hesab=C4=B1n=C4=B1z=C4=B1_ona?=
 =?utf-8?Q?ylaman=C4=B1z_i=C3=A7in_an=C4=B1msat=C4=B1c=C4=B1?=
Feedback-ID: F:28f5e9fd-7ba5-4466-8b17-b52f087bd332:anonaddy
Message-ID: [Message ID]
Received: from Mail Server ([***.***.***.***]) by
 mail2.anonaddy.me (Postfix) with ESMTPS id 70F86100233 for
 Email Address; Sat, 23 Sep 2023 09:06:37 +0100 (BST)

البريد الثاني (نفس الشيء، مكرر، يمكنك رؤية أنهما منفصلان بثوانٍ):

Return-Path: <SRS0=mdkr=FH=anonaddy.com=b_payts6dtgn5dkodznftq_my3tgntdgvqwk@Mail Server>
Delivered-To: Email Address
Received: from mail2.anonaddy.me (mail2.anonaddy.me [***.***.***.***])
	by Mail Server (Postfix) with ESMTPS id D2066370DA
	for Email Address; Sat, 23 Sep 2023 11:06:54 +0300 (+03)
Received: from mail2.anonaddy.me (mail2.anonaddy.me [127.0.0.1])
	by mail2.anonaddy.me (Postfix) with ESMTPS id 68CBC107D41
	for Email Address; Sat, 23 Sep 2023 09:06:54 +0100 (BST)
DKIM-Signature: [Truncated]
From: [Sender]
To: Email Address
Subject: =?utf-8?Q?=5BBilin=C3=A7li?= Teknoloji
 =?utf-8?Q?T=C3=BCketicileri=5D_Hesab=C4=B1n=C4=B1z=C4=B1_ona?=
 =?utf-8?Q?ylaman=C4=B1z_i=C3=A7in_an=C4=B1msat=C4=B1c=C4=B1?=
Feedback-ID: F:28f5e9fd-7ba5-4466-8b17-b52f087bd332:anonaddy
Message-ID: [Message ID]
Received: from Mail Server ([***.***.***.***]) by
 mail2.anonaddy.me (Postfix) with ESMTPS id E34B6100233 for
 Email Address; Sat, 23 Sep 2023 09:06:51 +0100 (BST)
إعجاب واحد (1)

هذه هي الأجزاء المثيرة للاهتمام.

هل معرف الرسالة هو نفسه؟

تحقق بعد ذلك من سجلات خادم البريد لمعرفة ما إذا كان Discourse قد أرسل رسالة واحدة مقابل رسالتين وما هو تاريخ البريد الإلكتروني الذي وصل إلى خوادم بريد anonaddy بالمعرفين 70F86100233 و E34B6100233.

4 إعجابات

معرفات الرسائل مختلفة.

الأول هو: Message-ID: <6172c966-5777-44c2-988f-6acdd7ff33ff@btt.community>
الثاني هو: Message-ID: <70297dae-5cb7-467b-980d-ef6dcfeea220@btt.community>

لقد تحققت من سجلات خادم البريد الخاص بي على النحو التالي: cat mail.log | grep 70297dae

الإخراج:

Sep 30 13:20:18 yuno postfix/cleanup[1559656]: 7C0F03D047: message-id=<70297dae-5cb7-467b-980d-ef6dcfeea220@btt.community>
Sep 30 13:20:38 yuno postfix/cleanup[1559656]: 88FE33D027: message-id=<70297dae-5cb7-467b-980d-ef6dcfeea220@btt.community>
Sep 30 13:20:44 yuno dovecot: lda(nonrelated@x.x.me)<1559829><m0KuF3z2F2UVzRcAMzq6nQ>: sieve: msgid=<70297dae-5cb7-467b-980d-ef6dcfeea220@btt.community>: stored mail into mailbox 'INBOX'

نفس الشيء مع معرف الرسالة الآخر: cat mail.log | grep 6172c966

الإخراج:

Sep 30 13:20:43 yuno postfix/cleanup[1559799]: D3D4A3D059: message-id=<6172c966-5777-44c2-988f-6acdd7ff33ff@btt.community>
Sep 30 13:20:49 yuno postfix/cleanup[1559656]: EFEBC3D027: message-id=<6172c966-5777-44c2-988f-6acdd7ff33ff@btt.community>
Sep 30 13:20:49 yuno dovecot: lda(nonrelated@x.x.me)<1559834><Z0kBEIH2F2UazRcAMzq6nQ>: sieve: msgid=<6172c966-5777-44c2-988f-6acdd7ff33ff@btt.community>: stored mail into mailbox 'INBOX'

ولكن في لوحة التحكم الخاصة بي، لا يزال يبدو وكأنه أرسل واحدة فقط: image

لقد رأيت مشكلة مشابهة لهذا من قبل مع خادم يعمل بـ dovecot. كانت هناك مشكلة في جانب dovecot تسببت في إعادة التسليم.

دعني أرى ما إذا كان بإمكاني العثور على المعلومات.

تعديل: ما زلت أحاول العثور على المعلومات. لقد نسيت كمية البيانات التي سأبحث فيها. :slight_smile:

4 إعجابات

أعتقد أن كلوديا لا يمكنها العثور على تلك المعلومات. أي اقتراحات أخرى حول كيفية تحديد المشكلة وإصلاحها ستكون موضع تقدير لأنني لا أعرف شيئًا. شكرا لك. :slight_smile:

هل وجدت حلاً؟

لقد واجهت سلوكًا مشابهًا في الماضي. كان المستخدمون يتلقون وابلًا من رسائل البريد الإلكتروني، والتي أرسلها خادم البريد ولكن في عرض ديسكورس لم يتم إرسالها.

كانت فرضيّتي هي أنه من الممكن أن يقوم ديسكورس بإعطاء مهمة لخادم البريد وهناك مهلة أثناء العملية، مما يتسبب في ظهور ذلك كفشل لديسكورس على الرغم من إرسال البريد. ثم يتم تكرار المهمة الفاشلة وينتج عن ذلك بريد جديد.

لقد أسعدني حل هذه المشكلة عن طريق قتل المهام في sidekiq، وإعادة تشغيل خادم البريد، والتلاعب بقواعد fail2ban.