ارسال ایمیل از طریق پروکسی HTTP با curl

پیش از تلاش برای ارسال، مجوزهای CONNECT، TLS مربوط به SMTP و اعتبارنامه‌های جداگانه پروکسی و سرویس ایمیل را بررسی کنید.

یک پروکسی HTTP می‌تواند اتصال SMTP را حمل کند اگر تونل CONNECT به درگاه سرور ایمیل را مجاز بداند. این مجوز مهم‌تر از آن است که یک صفحه وب از همان پروکسی بارگذاری شود.

ارسال با SMTP همراه با STARTTLS این شکل کلی را دارد:

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 ارتقای TLS را برای این نشانی SMTP الزامی می‌کند. بررسی گواهی را برای نام میزبان ایمیل مورد نظر فعال نگه دارید. احراز هویت موفق پروکسی ثابت نمی‌کند که TLS یا ورود به ایمیل موفق خواهد شد.

بسیاری از پروکسی‌های HTTP عمومی درگاه‌های CONNECT را محدود می‌کنند. رد درگاه 587 می‌تواند سیاستی عمدی باشد. به جای آزمودن مکرر درگاه‌های بی‌ربط یا تلقی این محدودیت به عنوان قطعی، مسیر تأییدشده بخواهید.

سرویس‌های ایمیل می‌توانند پس از کارکرد مسیر، مجوزهای فرستنده و سیاست‌های ارسال را نیز اعمال کنند. پاسخ SMTP را بخوانید. پیامی که پس از احراز هویت رد می‌شود به اصلاح متفاوتی از تونلی که پیش از رسیدن سلام SMTP رد می‌شود نیاز دارد.

مقالات مرتبط