curl کے ساتھ HTTP پراکسی کے ذریعے میل بھیجنا

بھیجنے کی کوشش سے پہلے CONNECT اجازتیں، SMTP TLS اور پراکسی اور میل سروس کی الگ الگ اسناد جانچیں۔

HTTP پراکسی SMTP کنکشن لے جا سکتی ہے اگر وہ میل سرور کے پورٹ تک CONNECT ٹنل کی اجازت دیتی ہے۔ یہ اجازت اس بات سے زیادہ اہم ہے کہ اسی پراکسی سے کوئی ویب صفحہ لوڈ ہوتا ہے یا نہیں۔

STARTTLS کے ساتھ SMTP استعمال کرنے والی جمع کرانے کی یہ عمومی صورت ہے:

curl --proxy http://203.0.113.10:8080 --proxytunnel \
  --url smtp://mail.example.com:587 --ssl-reqd \
  --user mail-user \
  --mail-from [email protected] \
  --mail-rcpt [email protected] \
  --upload-file message.eml

پتے پلیس ہولڈر ہیں۔ وہ میل سروس اور بھیجنے والا استعمال کریں جس کے لیے آپ مجاز ہیں۔ curl پاس ورڈ پوچھتا ہے جب صارف کے اختیار میں صرف صارف نام ہو۔ پیغام کی فائل کے لیے مناسب میل ہیڈر، ایک خالی سطر اور باڈی درکار ہے؛ یہ صرف وصول کنندہ کا پتہ نہیں ہے۔

الگ کنکشن اور لاگ اِن کی توقع رکھیں

HTTP ٹنل کا اختیار curl کو پراکسی سے SMTP منزل تک کنکشن مانگنے پر مجبور کرتا ہے۔ پراکسی کو curl کے پراکسی توثیق کے اختیارات کے ذریعے اپنی اسناد درکار ہو سکتی ہیں۔ پھر SMTP سروس اسی کنکشن کے اندر میل صارف کی توثیق کرتی ہے۔

--ssl-reqd اس SMTP URL کے لیے TLS اپ گریڈ درکار ہے۔ مطلوبہ میل ہوسٹ نام کے لیے سرٹیفکیٹ کی تصدیق فعال رکھیں۔ کامیاب پراکسی توثیق یہ ثابت نہیں کرتی کہ TLS یا میل لاگ اِن کامیاب ہوگا۔

بہت سی عمومی HTTP پراکسیاں CONNECT پورٹس محدود کرتی ہیں۔ پورٹ 587 کا انکار جان بوجھ کر پالیسی ہو سکتا ہے۔ غیر متعلقہ پورٹس بار بار آزمانے یا پابندی کو خرابی سمجھنے کے بجائے منظور شدہ راستہ طلب کریں۔

میل سروسز راستہ کام کرنے کے بعد بھیجنے والے کی اجازتیں اور جمع کرانے کی پالیسیاں بھی نافذ کر سکتی ہیں۔ SMTP جواب پڑھیں۔ توثیق کے بعد مسترد شدہ پیغام کے لیے SMTP سلام پہنچنے سے پہلے مسترد شدہ ٹنل سے مختلف حل درکار ہے۔

متعلقہ مضامین