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 కోసం వేచి ఉండే విధానం, శుక్రవారం నుండి క్యూ పెరుగుతున్నట్లు ఎవరూ గమనించకపోతే మెయిల్ అంతరాయంగా మారుతుంది.

రిలే, రవాణా, ఫైర్వాల్ నియమం మరియు ఆయుష్షును కలిసి నమోదు చేయండి. ఆ నాలుగు ఏర్పాటును వివరిస్తాయి; వాటిలో ఏదైనా ఒంటరిగా ఊహను మాత్రమే వివరిస్తుంది.