მიმართეთ Postfix ფოსტის რელეს, და არა ვებპროქსის

relayhost = proxy.example.net:3128 დამაჯერებლად გამოიყურება, სანამ ორი მხარე ლაპარაკს დაიწყებს. Postfix ელოდება SMTP პარტნიორს. ვებპროქსი 3128-ზე ელოდება HTTP პროქსის მოთხოვნას. არცერთი არ იღებს იმ საუბარს, რომელსაც ელოდა.

თუ ქსელი უზრუნველყოფს დამტკიცებულ ფოსტის რელეს, ნაცვლად ამისა დააკონფიგურირეთ ის SMTP სერვისი. ტიპიური ფორმა ასეთია:

relayhost = [smtp-relay.example.net]:587

ჰოსტის სახელი და პორტი მაგალითებია. კვადრატული ფრჩხილები თრგუნავს MX ძიებას ამ რელეს სახელისთვის. ისინი არ ამატებენ HTTP CONNECT-ს, TLS-ს ან აუთენტიფიკაციას. ცალკე დააკონფიგურირეთ რელეს მიერ მოთხოვნილი submission, SASL და TLS პარამეტრები.

ორი ანგარიში ასევე შეიძლება განსხვავებული იყოს. ვებპროქსის მიერ მიღებული პაროლი ავტომატურად არ არის ფოსტის გაგზავნის სერტიფიკატი და რელეს შეუძლია გამომგზავნის უარყოფა კავშირის მიღების შემდეგაც.

რა მოხდება, თუ ერთადერთი დამტკიცებული გზა გვირაბია?

HTTP პროქსის შეუძლია SMTP-ის გადატანა CONNECT-ის მეშვეობით, როცა დანიშნულების ადგილსა და პორტს უშვებს. ეს არ აიძულებს თვითნებურ SMTP კლიენტს CONNECT-ის შექმნას. curl-ის მსგავს ინსტრუმენტს აქვს პროქსი გვირაბის ცალსახა პარამეტრი; Postfix-ის relayhost-ის დაყენება სხვა ინტერფეისია.

ფიქსირებულ SSH გადამისამართებას ან სპეციალურად შექმნილ ლოკალურ ტრანსპორტის ადაპტერს შეუძლია ერთი დამტკიცებული SMTP სერვისი ლოკალურ TCP ბოლო წერტილად წარმოაჩინოს. ამ დიზაინში Postfix SMTP-ით ესაუბრება ბოლო წერტილს, ადაპტერი კი მეორე ტრანსპორტს უზრუნველყოფს. შეინახეთ იგი შეზღუდული და დაიცავით განკუთვნილი ფოსტის სერვერის TLS იდენტობა: კავშირის მისამართის loopback-ზე შეცვლამ შეიძლება გავლენა მოახდინოს სახელზე დაფუძნებულ სერტიფიკატის პოლიტიკაზე.

უპირატესობა მიანიჭეთ ფოსტის რელეს, როცა ეს არის ის სერვისი, რომელსაც ქსელის ოპერატორი გთავაზობთ. ის რიგს, გამომგზავნის პოლიტიკას და მიწოდების შეცდომებს SMTP-ის მცოდნე სახლს აძლევს. მხოლოდ ვებპროქსის პარამეტრი ამ ფოსტის ფუნქციებიდან არცერთს არ უზრუნველყოფს.