Mac Mail, બે ખાતાં અને એક VPN નિયમ જે તેમને અલગ કરી શકતો નથી

Mail ખૂલે છે, કામનું ઇનબોક્સ સિંક થાય છે, અને અંગત ઇનબોક્સ સમય વીતવા લાગે છે. અથવા બંને સિંક થાય છે, પણ કામનું સર્વર ફક્ત ત્યારે જ જવાબ આપે છે જ્યારે ટનલ ચાલુ હોય, અને Mail જાણતું નથી કયું ખાતું કયું છે. લક્ષણનો આકાર હંમેશા એક જ હોય છે: એક એપ, બે ખાતાં અને એક નિયમ જે એપને ઓળખે છે. સુધારો એ સ્વીકારથી શરૂ થાય છે કે એપ એક પાત્ર છે, સીમા નહીં.

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

કેમ એપ ખોટો એકમ છે

Mail એ એક પ્રક્રિયા છે જે દરેક ગોઠવાયેલા ખાતાની સેવા કરે છે. એપ સામે લખાયેલો નિયમ તેના બધા જોડાણો પકડે છે, તેથી અંગત ખાતું કામની ટનલ અને તેનો મૂળભૂત માર્ગ વારસામાં મેળવે છે. તે સ્વીકાર્ય હોઈ શકે, પણ તે નિર્ણય છે, એવી આડઅસર નહીં જેને તપાસ્યા વિના છોડી શકાય.

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

જ્યારે બંને ખાતાં જુદા જુદા સર્વર વાપરે છે

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

સરનામાં વાપરો, @ ચિહ્ન પછીનો ભાગ નહીં. મેલ સરનામામાંનું ડોમેન રાઉટિંગનું નિવેદન નથી, અને તેને એમ ગણવાથી એવો નિયમ બને છે જે ખોટા હોસ્ટ માટે ચાલે અથવા કદી ચાલે જ નહીં. વાસ્તવિક અંતિમ બિંદુઓ ખાતાની સેટિંગ્સમાંથી કે સંચાલક પાસેથી ખાતરી કરો.

જ્યારે બંને ખાતાં એક સર્વર વહેંચે છે

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

તે સમયે પ્રામાણિક વિકલ્પો છે ખાતા-જાગૃત નીતિ જો પ્લેટફોર્મ અને ક્લાયન્ટ તેને સમર્થન આપે, કામના ખાતા માટે અલગ મંજૂર મેલ ક્લાયન્ટ જેથી એપની સીમા વાસ્તવિક બને, અથવા બંને ખાતાં સાથે મુસાફરી કરે તે સ્વીકારવું. જાણી જોઈને એક પસંદ કરો અને કહો કે કયું પસંદ કર્યું.

ટનલ શરૂ કરવી એ તેને આવરવા સમાન નથી

Appleનું App Layer VPN પેલોડ MailDomains સેટિંગનું દસ્તાવેજીકરણ કરે છે: સૂચિબદ્ધ ડોમેન Mailને સમર્થિત સંચાલિત ડિપ્લોયમેન્ટમાં VPN જોડાણ શરૂ કરાવે છે. તે ઉપયોગી ક્ષમતા છે, અને તે સાંભળવામાં આવે તેનાથી સાંકડી છે. Mail તે ડોમેન સાથે વાત કરે ત્યારે તે ટનલ શરૂ કરે છે; તે દરેક માર્ગ, દરેક એપ-સંલગ્નતા કે ટનલ બંધ હોય ત્યારે શું થાય તે વર્ણવતું નથી.

તે સંચાલિત સુવિધા પણ છે, Mail ઇન્ટરફેસમાં દરેક ખાતા માટેનું ચેકબોક્સ નહીં. જો ડિપ્લોયમેન્ટ સંચાલિત ન હોય, તો સેટિંગ તમારા માટે ઉપલબ્ધ નથી, અને કેટલુંય પ્રોફાઇલ સંપાદન કરો તે તેને બનાવશે નહીં.

કેશ કરેલા ઇનબોક્સ સાથે નહીં, નવા સિંક સાથે પરીક્ષણ કરો

સ્વીકૃતિ પરીક્ષણ એ ઇચ્છિત નીતિ હેઠળ દરેક ખાતા માટે નવું સિંક છે, સાથે સુરક્ષિત ખાતા માટે અનુપલબ્ધ સ્થિતિ. કેશ કરેલું ઇનબોક્સ આગલી વિનંતી વિશે કંઈ સાબિત કરતું નથી, અને જોડાયેલું VPN ચિહ્ન ફક્ત એટલું કહે છે કે કોઈ ટનલ અસ્તિત્વમાં છે.

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