Kutuma barua pepe kupitia proksi ya HTTP kwa curl
Kagua ruhusa za CONNECT, SMTP TLS, na vitambulisho tofauti vya proksi na huduma ya barua pepe kabla ya kujaribu kutuma.
Proksi ya HTTP inaweza kubeba muunganisho wa SMTP ikiwa inaruhusu handaki la CONNECT kwenye bandari ya seva ya barua pepe. Ruhusa hiyo ni muhimu zaidi kuliko kama ukurasa wa wavuti unapakiwa kupitia proksi hiyo hiyo.
Uwasilishaji unaotumia SMTP pamoja na STARTTLS una umbo hili la jumla:
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
Anwani ni nafasi za kujazwa. Tumia huduma ya barua pepe na mtumaji uliyeruhusiwa kutumia. curl huuliza nenosiri wakati chaguo la mtumiaji lina jina la mtumiaji pekee. Faili ya ujumbe inahitaji vichwa vya barua pepe vinavyofaa, mstari tupu na mwili; si anwani ya mpokeaji pekee.
Tegemea miunganisho na uingiaji tofauti
Chaguo la handaki la HTTP hufanya curl kuomba proksi muunganisho kwa lengo la SMTP. Proksi inaweza kuhitaji vitambulisho vyake mwenyewe kupitia chaguo za uthibitishaji wa proksi za curl. Kisha huduma ya SMTP huthibitisha mtumiaji wa barua pepe ndani ya muunganisho huo.
--ssl-reqd inahitaji uboreshaji wa TLS kwa URL hii ya SMTP. Acha uthibitishaji wa cheti ukiwa umewashwa kwa jina la mwenyeji wa barua pepe linalokusudiwa. Uthibitishaji wa proksi uliofanikiwa hauthibitishi kwamba TLS au uingiaji wa barua pepe utafanikiwa.
Proksi nyingi za jumla za HTTP huzuia bandari za CONNECT. Kukataliwa kwa bandari 587 kunaweza kuwa sera ya kukusudia. Omba njia iliyoidhinishwa badala ya kujaribu bandari zisizohusiana mara kwa mara au kuchukua kizuizi kama hitilafu.
Huduma za barua pepe zinaweza pia kutekeleza ruhusa za mtumaji na sera za uwasilishaji baada ya njia kufanya kazi. Soma jibu la SMTP. Ujumbe uliokataliwa baada ya uthibitishaji unahitaji suluhisho tofauti na handaki lililokataliwa kabla ya salamu ya SMTP kuwasili.