Sendi retpoŝton tra HTTP-prokura servilo per curl

Kontrolu CONNECT-permesojn, SMTP-TLS kaj la apartajn akreditaĵojn de la prokura servilo kaj la retpoŝta servo antaŭ ol provi sendon.

HTTP-prokura servilo povas porti SMTP-konekton se ĝi permesas CONNECT-tunelon al la pordo de la retpoŝta servilo. Tiu permeso pli gravas ol ĉu retejo ŝargiĝas tra la sama prokura servilo.

Sendado per SMTP kun STARTTLS havas ĉi tiun ĝeneralan formon:

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

La adresoj estas lokokupiloj. Uzu retpoŝtan servon kaj sendanton, por kiuj vi rajtas. curl petas la pasvorton kiam la uzula opcio enhavas nur la uzantnomon. La mesaĝa dosiero bezonas taŭgajn retpoŝtajn kapojn, malplenan linion kaj korpon; ĝi ne estas nur la adreso de la ricevanto.

Atendu apartajn konektojn kaj ensalutojn

La opcio de HTTP-tunelo igas curl peti de la prokura servilo konekton al la SMTP-celo. La prokura servilo povas postuli proprajn akreditaĵojn per la prokuraj aŭtentikigaj opcioj de curl. Poste la SMTP-servo aŭtentikigas la retpoŝtan uzanton ene de tiu konekto.

--ssl-reqd postulas la TLS-plibonigon por ĉi tiu SMTP-URL. Lasu atestilan kontroladon ŝaltita por la celita retpoŝta gastignomo. Sukcesa prokura aŭtentikigo ne pruvas, ke TLS aŭ la retpoŝta ensaluto sukcesos.

Multaj ĝeneralaj HTTP-prokuraj serviloj limigas CONNECT-pordojn. Rifuzo de pordo 587 povas esti intenca politiko. Petu aprobitan vojon anstataŭ ripete provi nerilatajn pordojn aŭ trakti la limigon kiel paneon.

Retpoŝtaj servoj ankaŭ povas plenumi sendantajn permesojn kaj sendajn politikojn post kiam la vojo funkcias. Legu la SMTP-respondon. Mesaĝo rifuzita post aŭtentikigo postulas alian riparon ol tunelo rifuzita antaŭ ol alvenas la SMTP-saluto.

Rilataj artikoloj