لقد لاحظت أن العديد من المواقع تشتكي من عدم تعريف مفتاح واجهة برمجة تطبيقات Mailgun، ولكن (على الأقل معظم) تلك المواقع تتلقى ردودًا عبر حاوية استقبال البريد وهي تتعامل مع هذه الارتدادات، لذا لا يلزم أن يكون مفتاح واجهة برمجة التطبيقات (والخطاف المرتبط به على Mailgun) مطلوبًا. يبدو أن المنطق في المواصفات (وبالتالي، في الكود) معكوس:
context "when using Mailgun without an API key" do
let(:replies_enabled) { true }
let(:mailgun_address) { "smtp.mailgun.org" }
let(:api_key) { nil }
it do
expect(check).to have_a_problem.with_priority("low").with_message(
"The server is configured to send emails via Mailgun but you haven't provided an API key used to verify the webhook messages.",
)
end
يشكو إذا كانت الردود ممكّنة، ولكن في هذه الحالة، نحن لا نحتاج إلى الخطاف، و
context "when replies are disabled" do
let(:replies_enabled) { false }
let(:mailgun_address) { anything }
let(:api_key) { anything }
it { expect(check).to be_chill_about_it }
end
هنا نحن لا نعالج الارتدادات باستخدام مستقبل البريد ونحن مرتاحون حيال ذلك.
هل أنا مرتبك أم أن هذا معكوس؟
حسنًا، ربما أنا مرتبك. يبدو أن مستقبل البريد لا يخبر Discourse عن الارتدادات. موقع مزدحم لا يحتوي على رسائل مرتدة حديثة.
ولكن:
و:
لذلك تشير هذه الوثائق إلى أنه إذا كان لديك مستقبل بريد يعمل، فيجب أن يتعامل مع هذا. والكود الذي كتبته ذات مرة في بعض أدواتي الداخلية التي أعدت هذه الخطافات تقول “لا نحتاج إلى خطافات عندما يكون لدينا مستقبل بريد”.
لقد صادفت هذا للتو أيضًا. إذا كان لديك مستقبل البريد (mail-receiver) ممكّنًا، فهذا التحذير لا معنى له. لقد تجاهلت للتو التحذير بناءً على ما قرأته هنا (شكرًا جاي!)، ولكن لا يسعني إلا التفكير في أنه يمكن التعامل مع هذا بشكل أفضل. على الأقل قم بتوفير رابط إلى الإعداد حتى لا تضطر إلى البحث عنه (تلميح: إنه ليس في إعدادات البريد الإلكتروني)، وعلى الإعداد قم بتوفير وصف أفضل مع مزيد من التفاصيل وربما رابط لموضوع توثيق على ميتا؟
أثناء التحقيق في هذا الأمر، لاحظت أننا لم يكن لدينا سوى فحص مشكلة لـ Mailgun. لذلك قمت ببعض إعادة الهيكلة لإضافة فحص مشكلة عام “لمعالجة ارتداد البريد الإلكتروني” سيعمل مع جميع مزودي البريد الذين قمنا بتكوينهم.
