Postfix, VPN અને smarthost: કતાર એ ફાયરવોલ નથી

VPN ઉપર આવે ત્યાં સુધી મેઇલને કતારમાં રાખવી એ સમયપત્રકની સમસ્યા છે, અને સામાન્ય ઉકેલ છે Postfix બંધ કરવું, main.cf બદલવું અને ફરી ચાલુ કરવું. તે કામ કરે છે, અને તે ખોટો આકાર છે, કારણ કે તે બે આવશ્યકતાઓ ભેગી કરે છે: ડિલિવરી ક્યારે અજમાવવી જોઈએ, અને કયો નેટવર્ક માર્ગ તેને વહન કરી શકે. બીજી ફાયરવોલનો નિર્ણય છે, અને કોઈ પણ Postfix નિર્દેશ તે લઈ શકતું નથી. બંને અલગ થયા પછી, દરેક પાસે નાનો અને ચકાસી શકાય તેવો જવાબ છે.

રિલેનું લક્ષ્ય સ્થિર રાખો, નેટવર્ક સીમા પર સીધી ડિલિવરી અવરોધો, અને કતારને રાહ જોવા દો.

લોકો જે બે આવશ્યકતાઓને એકમાં ભેગી કરે છે

રિલે Postfix ને કહે છે કે મેઇલ ક્યાં સોંપવો; relayhost = [smtp.corp.example]:587 યજમાન અને પોર્ટનું નામ આપે છે, અને કૌંસ તે આગલા હોપ માટે MX આધારિત પસંદગી દબાવે છે. માર્ગ કર્નલને કહે છે કે પેકેટ ક્યાં જઈ શકે. માર્ગ પ્રતિબંધ વિનાનું સાચું relayhost હજી પણ Postfix ને સીધું ઇન્ટરનેટ સુધી પહોંચવા દે છે જ્યારે રૂટિંગ કોષ્ટક તેને મંજૂરી આપે, અને ખોટા relayhost સાથેનું સાચું ફાયરવોલ મેઇલને ખોટી જગ્યાએ મોકલે છે. એક પણ બીજાને સૂચિત કરતું નથી.

ટ્રાન્સપોર્ટ નકશા, પ્રતિ-મોકલનાર ઓવરરાઇડ અને ફોલબેક રિલે દરેકને એ જ વાંચન લાયક છે. સ્થિર relayhost એ પુરાવો નથી કે દરેક રૂપરેખાંકિત ડિલિવરી માર્ગ તેનો ઉપયોગ કરે છે, અને રિલેને ટાળતો ફોલબેક માર્ગ એ જ નિષ્ફળતા છે, ફક્ત વધુ સારા વેશમાં.

defer_transports ખરેખર શું કરે છે

defer_transports નામ આપેલા ટ્રાન્સપોર્ટ માટે સંદેશા રોકી રાખે છે, જેથી કતારની એક ફેરી તેમને સ્પર્શે નહીં ત્યાં સુધી કોઈ ડિલિવરી પ્રયાસ થતો નથી. તે સમયપત્રક નિયંત્રણ છે, અને કતાર ફ્લશ તેને ઓળંગે છે; તે રચના છે, ખામી નથી. master.cf માંથી વાસ્તવિક ટ્રાન્સપોર્ટ નામો વાપરો, કારણ કે કસ્ટમ ટ્રાન્સપોર્ટ અથવા અલગ નામનો રિલે ટ્રાન્સપોર્ટ ફક્ત એટલા માટે આવરી લેવાતો નથી કે તેનો પ્રોગ્રામ SMTP પણ બોલે છે. સામાન્ય ફરી પ્રયાસ એ બીજી પદ્ધતિ છે: fail-closed માર્ગ સાથે, ડિલિવરી પ્રયાસો ફક્ત નિષ્ફળ જાય છે અને કતારમાં રહે છે, કોઈ મુલતવી નિર્દેશ સામેલ નથી.

કાયમી નિષ્ફળતાઓ નમ્રતાથી રાહ જોતી નથી. ખરાબ પ્રાપ્તકર્તા અથવા નકારાયેલ ઓળખપત્ર ટનલ આવે ત્યાં સુધી બેસવાને બદલે પાછું ઉછળે છે અથવા કઠોર ભૂલ તરીકે અટકી જાય છે, તેથી મુલતવી મેઇલથી ભરેલી કતાર આપોઆપ સુરક્ષિત કતાર નથી.

નેટવર્ક સ્તરે માર્ગ લાગુ કરો

પ્રતિબંધ સ્થાનિક આઉટપુટ સીમા પર અથવા અલગ નેટવર્ક નામસ્થાનની અંદર આવે છે. તે રિલેના વાસ્તવિક સરનામાં, ટ્રાન્સપોર્ટ અને પોર્ટ આવરી લેવા જોઈએ, જેમાં IPv6 પણ સક્રિય હોય તો સમાવેશ થાય, કારણ કે TCP 25 અવરોધતો નિયમ 587 અથવા 465 પરના રિલે માટે કંઈ કરતો નથી. લૂપબેક અને સ્થાનિક સબમિશન માર્ગ અલગ રાખો જેથી કતાર પોતે કામ કરતી રહે. ટનલ માર્ગ અદૃશ્ય થાય અથવા બીજા ઇન્ટરફેસ નામ હેઠળ ફરી દેખાય ત્યારે નીતિ બંધ રહેવી જોઈએ.

ઇન્ટરફેસ ઉપર આવવાની ઘટના સાબિત કરતી નથી કે રિલે તેના દ્વારા પહોંચી શકાય છે. તેથી લિંક તપાસીને પછી કતાર ખાલી કરતો હૂક સુવિધા છે, બાંયધરી નથી: તપાસ અને ડિલિવરી પ્રયાસ વચ્ચે લિંક બદલાઈ શકે છે.

એક નિર્દોષ સંદેશ સાથે સાબિત કરો

VPN બંધ હોય ત્યારે એક નિર્દોષ સંદેશ મોકલો, પછી મુલતવીનું કારણ અને કતાર ID માટે postqueue -p તપાસો. ઇચ્છિત માર્ગ પુનઃસ્થાપિત કરો અને નિયંત્રિત કતાર ફેરીની વિનંતી કરો, સંદેશ રિલે દ્વારા નીકળે છે કે બીજે ક્યાંક તે જુઓ. પછી ઉડાન વચ્ચે માર્ગ ફરી તોડો અને ખાતરી કરો કે સંદેશ કતારમાં પાછો આવે છે. વિક્ષેપ કેટલો ચાલી શકે તે નક્કી કરતા પહેલા maximal_queue_lifetime સમીક્ષા કરો, કારણ કે શૂન્ય મૂલ્યનો અર્થ એક પ્રયાસ છે, અમર્યાદિત જાળવણી નહીં.

કતારની ઉંમર અને ડિસ્ક વપરાશ પર નજર રાખો. VPN ની રાહ જોતી નીતિ મેઇલ વિક્ષેપમાં ફેરવાય છે જો કોઈ ધ્યાન ન આપે કે શુક્રવારથી કતાર વધી રહી છે.

રિલે, ટ્રાન્સપોર્ટ, ફાયરવોલ નિયમ અને આયુષ્ય એકસાથે નોંધો. તે ચાર ગોઠવણીનું વર્ણન કરે છે; તેમાંથી કોઈ પણ એકલું અનુમાનનું વર્ણન કરે છે.