مقالات شبکه – برگه 4 – پشتیبانی VoIP|پشتیبانی شبکه|ویپ |تجهیزات شبکه

آشنایی با پروتکل احراز هویت DKIM ایمیل

Posted on نوامبر 22, 2021 by tilatel

(DomainKeys Identified Mail (DKIM پیچیده ترین پروتکل تصدیق ایمیل می باشد، این مقاله به صورت اختصاصی به معرفی پروتکل DKIM خواهیم پرداخت. با ما همراه باشید:

(DomainKeys Identified Mail (DKIM یک پروتکل است که به سازمان ها اجازه می دهد تا انتقال پیام را به گونه ای که توسط ارائه دهندگان ایمیل قابل تایید باشد، انجام دهند. این تاییدیه توسط احراز هویت رمزنگاری شده (Cryptographic authentication) و از طریق کلید های Public و Private انجام می پذیرد.

DKIM کمی پیچیده می باشد، در ادامه سعی می کنیم، به زبانی ساده آن را برای شما شرح دهیم.

گام اول: شناسایی عناصر یک پیغام برای Sign در DKIM

یک فرستنده ایمیل ابتدا باید تصمیم بگیرد که کدام Elements های یک ایمیل را می خواهد در فرایند Sign قرار دهد، آن ها باید تصمیم بگیرند که کل پیام (Header,Body) یا فقط یک یا چند فیلد خاص در هدر ایمیل در جریان این فرایند رمزنگاری قرار بگیرد.، Element هایی که قرار است در Sign DKIM قرار بگیرند نباید در حین انتقال پیام تغییر کنند، در غیر اینصورت احراز هویت DKIM رد یا Fail می شود.

برای مثال، اگر یک ایمیل از Yahoo به Gmail forward شود، یاهو یک متن در بالای ایمیل مانند (forward By yahoo mail) اضافه می کند و Body ایمیل دچار تغییر می شود، اگر Body جز Element های امضا شده در فرایند DKIM باشد، احراز هویت در ایمیل Forward شده Fail خواهد شد.

با این حال، اگر تنها یک Element از Header مانند فیلد From در فرایند امضای DKIM قرار گرفته باشد، و ایمیل از Yahoo به Gmail forward شود، احراز هویت DKIM تایید می شود، زیرا آن بخشی از ایمیل که تغییر کرده است در فرایند امضای DKIM قرار نگرفته بوده است.

گام دوم: فرایند رمزنگاری

فرستنده باید یک سری تنظمیات بر روی Platform ایمیل خود انجام دهد، که به صورت خودکار یک Hash از Element هایی که قرار است در فرایند Sign قرار بگیرند ساخته شود. فرایند Hash، متن را تبدیل به یک رشته متنی منحصر بفرد می کند.

<From: Ehsan Ataei <IT@PardisMail.com

Subject: Testing

:Maps to the following unique hash string

3303baf8986f910720abcfa607d81f53

قبل از ارسال ایمیل، رشته متنی Hash شده با استفاده از Private Key رمزنگاری می شود، کلید خصوصی از ترکیب نام دامنه و Selector (هر اسمی امکان پذیر می باشد، بیشتر بر اساس نوع کاربری ایمیل انتخاب می شود) ساخته می شود، که به شما این قابلیت را می دهد که چندین کلید خصوصی قانونی برای یک دامنه داشته باشید( که برای مدیریت ایمیل و اهداف امنیتی مهم می باشد)، و فقط فرستنده به کلید خصوصی دسترسی دارد. بعد از کامل شدن فرایند رمزنگاری ایمیل ارسال می شود.

گام سوم: تایید DKIM Signature با کلید عمومی:

Mail سرور گیرنده بعد از دریافت ایمیل، متوجه می شود که ایمیل دارای امضای DKIM می باشد، که نشان دهنده نام دامین و Selector است که فرایند رمزنگاری را امضا کرده اند، دریافت کننده ایمیل یک پرس و جو Query DNS برای پیدا کردن کلید عمومی براسا Domain\Selector برای تایید امضا انجام می دهد.

کلید عمومی دارای خصوصیات منحصربفردی است که تنها با کلید خصوصی که ایمیل را امضا کرده است، مطابقت دارد،که به عنوان keypair match هم شناخته می شود، که ارائه دهندگان ایمیل را قادر به رمزگشایی امضای DKIM و بدست آوردن رشته اصلی Hash میسازد.

ارائه دهندگان ایمیل سپس با استفاده از Element های شرکت کننده در امضای DKIM دوباره یک Hash از این عناصر میسازد، سپس هش را با هش بدست امده از DKIM Hash مقایسه می کند، اگر دو Hash با هم مطابقت داشته باشند، ما می دانیم که:

دامنه با امضای DKIM مالک ایمیل می باشد، در غیر اینصورت فرایند رمزگشایی در وهله اول کار نخواهد کرد.
عناصر ایمیل که توسط DKIM امضا شده بودند در هنگام ارسال تغییری نکرده اند (زیرا اگر تغییر کرده بودند، Hash ها با یکدیگر مطابقت نداشتند).

ارائه دهندگان ایمیل که امضای DKIM را تایید می کنند، می توانند از اطلاعات مربوط به امضاکننده به عنوان بخشی از یک برنامه برای کاهش حملات Spam,Spoofing و Phishing استفاده کنند، هر چند که DKIM به دریافت کنندگان ایمیل برای انجام، اقدامی خاص کمک نمی کند، بستگی به پیاده سازی DKIM می توان اطمینان حاصل کرد که پیام در نقل و انتقالات دستخوش تغییرات بوده است یا خیر

مشکل DKIM این است که به دلیل اجرای سخت پیاده سازی، فرستنده های کمتری آن را قبول کرده اند، این نقطه ضعف بدان معنی است که عدم وجود امضای DKIM لزوما نشان دهنده جعلی بودن ایمیل نیست، بنابراین DKIM یک راه قابل اعتماد برای تایید هویت فرستنده نیست، علاوه بر این DKIM برای کاربر نهایی غیر فنی قابل مشاهده نیست، و هیچ کاری برای جلوگیری از جعل هویت Header From دامین نمی کند.

DMARC، آخرین و پیشرفته ترین پروتکل در احراز هویت ایمیل می باشد و این مشکل را با تضمین اینکه دامنه قابل مشاهده برای کاربر نهایی همان دامنه ای است که توسط SPF و DKIM بررسی و تایید شده است حل می کند. علاوه بر این، ارائه دهندگان صندوق پستی را با دستورالعمل مشخصی در مورد اینکه کدام ایمیل ها باید توسط DKIM احراز هویت شوند و کدامیک نه کمک رسانی می کند.

آشنایی با پروتکل احراز هویت SPF ایمیل

Posted on نوامبر 22, 2021نوامبر 22, 2021 by tilatel

احراز هویت ایمیل، می تواند کاری بسیار فنی و گیچ کننده باشد.

حتی متخصصان امنیت با تجربه هم نیاز به کمک و هدایت در این حوزه دارند، و توضیح آن برای افراد غیرفنی براحتی قابل هضم نیست.

در این مقاله قصد داریم تا شما را با مهمترین پروتکل های احراز هویت ایمیلآشناکنیم، پروتکل هایی مانند :

SPF(Sender Policy Framework)

،DKIM(Domain Keys Identified Mail)

DMARC(Domain-Based Message Authentication,Reporting & Conformance)

Two “From” Addresses:

پیغام های ایمیل شامل دو آدرس “from” هستند(Envelope from(return path or mfrom و (Header from(Friendly From.

Envelope from آدرس برگشتی است، و به میل سرورها مسیر بازگشت را می گوید، Enveloper from در هدر پیام های ایمیل مخفی می باشد که شامل جزئیات فنی سرورها است، که برای فهمیدن اینکه چه کسی ایمیل را ارسال کرده و یا از چه نرم افزاری برای ساخت آن استفاده شده است.

آدرس Header from آدرس قرار گرفته در فیلد From می باشد که برای همه کاربران قابل مشاهده می باشد.

هر دوی این ها آدرس ها توسط مجرمان سایبری به براحتی قابل جعل و کلاهبرداری می باشد، این مرحله ای است که تایید و احراز هویت ایمیل وارد می شود.

(SPF (Sender Policy Framework:

SPF یک پروتکل احراز هویت ایمیل می باشد، که به مالک یک دامین اجازه می دهد که مشخص کند،که کدام میل سرورها برای ارسال ایمیل از این دامنه استفاده می شود.

کمپانی های ارسال ایمیل رکوردهای SPF را در DNS منتشر می کنند، این رکوردها، لیست آدرس های IP مجاز برای ارسال ایمیل برروی دامنه ها را مشخص می کنند.

در طی بررسی SPF، ارائه دهندگان ایمیل،تایید رکورد SPF را با جستجو کردن نام دامنه ذکر شده درآدرس Envelope from را در DNS بررسی می کند، اگر آدرس IP ارسال ایمیل روی دامین در رکورد SPF نباشد، ایمیل دراحراز هویت SPF رد می شود.

یک دامین محافظت شده با SPF کمتر برای phishers جذاب می باشد، بنابراین کمتر به لیست های Spam اضافه می شود.

اما SPF دارای چند مشکل عمده می باشد.

فقط به این دلیل که یک پیام فاقد SPF است، به این معنا نیست که همیشه مسدود می شود، این یکی از چندین فاکتوری است که ارائه دهندگان ایمیل برای Spam در نظر می گیرند.
SPF هنگامی که یک پیام forward می شود، از بین می رود.
به روز نگه داشن رکوردSPF کمی زمانبر می باشد.
SPF نمی تواند هیچ کاری برای محافظت در برابر مجرمان اینترنتی که نام یا آدرس”Header from” را در پیغام خود جعل می کنند، انجام بدهد.

نحوه ی تغییر رمز عبور کاربران در کنسول EAC در Exchange Server

Posted on نوامبر 21, 2021 by tilatel

پیکربندی و تغییر رمز عبور یکی از وظایف مهم در ایمن سازی محیط IT می باشد، در بعضی مواقع کاربران رمز عبور خود را فراموش کرده یا شاید رمز عبور به اندازه کافی قوی یا Complex نباشد یا رمز های عبور هر ماه عوض می شود، بنابراین کاربران باید بتوانند رمز عبور خود را عوض نمایند، کاربران به راحتی می توانند رمز عبور خود را از طریق صفحه تنظیمات OWA تغییر دهند و همچنین یک Admin قادر به تغییر رمز عبور کاربران از طریق کنسول EAC می باشد.

در این مقاله قصد داریم تا نحوه راه اندازی Reset Password درکنسول EAC را بررسی کنیم با ما همراه باشید:

در ایمیل سرور اکسچنج تغییر رمز عبور توسط خود کاربر از طریق Outlook Web Access یا توسط ادمین در EAC امکان پذیر است، تغییر رمز در OWA خیلی آسان است، ولی اگر بخواهید در کنسول EAC رمز عبور یک کاربر خاص را عوض کنید ممکن است گزینه Reset Password را در کنسول مدیریتی مشاهده نکنید.

به صورت پیش فرض موقع نصب اکسچنج کاربر Administrator دسترسی تغییر رمز عبور کاربران را دارا نمی باشد، بنابراین باید به صورت دستی این سطح دسترسی به کاربر Administrator داده شود، کنسول EAC را باز کرده و با اکانت Administrator لاگین کنید سپس به پنل Permission ها و سپس به ثب Admin roles بروید، شما اکنون قادر به دیدن Role های پیش فرض هستید.

گروه Organization Management تقریبا شامل همه رول ها می باشد به جز ویژگی Reset Password، به صورت پیش فرض تنها کاربر Administrator عوض این گروه می باشد بنابراین شما باید رول Reset Password به گروه Organization Management اضافه نمایید، اگر بر روی گروه Organization Management کلیک کنید، صفحه زیر را مشاهده خواهید کرد:

در صفحه بالا بر روی گزینه Add در بخش Roles کلیک کنید، یک صفحه جدید که شامل تمامی Role ها می باشد به شما نمایش داده خواهد شد.

Reset Password Role را انتخاب، در پنل سمت راست شما می توانید توضیحات مربوط به این رول را بببینید، بر روی دکمه Add کلیک کنید تا Role اضافه شود و سپس روی Ok کلیک کنید، اگر عملیات با موفقیت انجام شد پاراگراف بعدی را دنبال کنید، اما اگر خطای

You don’t have access to create, change, or remove the “Reset Password-Organization Management” management role assignment. You must be assigned a delegating role assignment to the management role or its parent in the hierarchy without a scope restriction

را دریافت کردید باید از طریق Exchange Management Shell رول RBAC را مجددا نصب کنید، بعد از اجرا کردن Command یک بار دیگر از کنسول EMS خارج و دوباره لاگین کنید و رول Reset Password را اضافه نمایید.

PS] C:\Windows\system32> Add-pssnapin microsoft]

PS] C:\Windows\system32> Install-CannedRbacRoles]

PS] C:\Windows\system32> Install-CannedRbacRoleAssignments]

پنجره تنظیمات میل باکس را با دوبار کلیک بر روی میل باکس باز کنید، اکنون در تب General گزینه Reset Password را مشاهده خواهید کرد، اکنون قادر به تغییر رمز عبور هر کاربری از طریق کنسول EAC می باشید.

معرفی Protocol Logging در Exchange Server 2013

Posted on نوامبر 20, 2021نوامبر 20, 2021 by tilatel

در این مقاله به معرفی Protocol Logging در Exchange Server 2013 می پردازیم.با ما همراه باشید

پروتکل لاگینگ (Protocol Logging) کلیه رخدادهای SMTP بین ایمیل سرورها را ثبت می کند. این گفتگوهای SMTP بین Send Connector سرور ارسال کننده ایمیل و Receive Connector سرور دریافت کننده ایمیل در Front End Transport Services سرور Client Access، Transport Service روی Mailbox Server و Mailbox Transport Service روی سرورهای Mailbox رخ می دهد. از طریق پروتکل لاگینگ (Protocol Logging) می توانیم مشکلات مربوط به ارسال و دریافت ایمیل را مشخص کنیم.

به صورت پیش فرض پروتکل لاگینگ روی کلیه کانکتورهای مربوط به ارسال و دریافت غیرفعال می باشد. پروتکل لاگینگ به ازای هر کانکتورها قابل فعال یا غیرفعال شدن می باشد. سایر آپشن های مربوط به پروتکل لاگینگ روی کلیه کانکتورهای ارسال و کلیه کانکتورهای دریافت در Transport Service سرور تنظیم می شوند. فایلهای مربوط به پروتکل لاگها و پروتکل آپشن های همه Receive Connector ها یا همان کانکتورهای دریافت در یک Transport Service به صورت مشترک در یکجا ذخیره می شوند. این پروتکل لاگ ها و پروتکل آپشن ها با پروتکل لاگ ها و پروتکل آپشن های Send Connector های همان سرور متفاوت می باشد.
آپشن های ذیل برای پروتکل لاگ کلیه Send Connector ها یا Receive Connector های Transport Service روی Exchange Server قابل تنظیم می باشد:
– تعیین مسیر نگهداری فایلهای پروتکل لاگ مربوط به کانکتور ارسال و کانکتور دریافت.
– تعیین حداکثر سایز فایلهای پروتکل لاگ برای کانکتور ارسال و کانکتور دریافت. حجم پیش فرض 10 مگابایت می باشد.
– تعیین حداکثر حجم فولدر مربوط به ذخیره سازی فایلهای پروتکل لاگ برای کانکتور ارسال و کانکتور دریافت. حجم پیش فرض 250 مگابایت می باشد.
– تعیین حداکثر مدت نگهداری فایلهای پروتکل لاگ برای کانکتور ارسال و کانکتور دریافت. مدت زمان پیش فرض 30 روز می باشد.
به صورت پیش فرض Exchange Server فایلهای لاگ را پس از حجم و زمان مجاز پاک می کند تا امکان مدیریت فضای هارددیسک فراهم شود.
یک Send Connector خاص به نام Intra-organization در هر سرور با رول Transport Service ایمیل سرورها و Client Access سرورها وجود دارد. این کانکتور به صورت پیش فرض ساخته می شود و نیازی به کانفیگ ندارد. کانکتور ارسال کننده intra-organization برای Transport Services های ذیل استفاده می شود:
– Transport Services روی Mailbox سرورها
o رله کردن ایمیل های ارسالی به Transport Service و Mailbox Transport Service روی سایر Exchange Server های 2013 در همان Organization
o رله کردن ایمیلهای ارسالی به سایر Exchange Server های 2007 یا 2010 در همان Organization
o رله کردن ایمیلهای ارسالی به Edge Transport سرور
– Front End Transport Services روی Client Access سرورها
o رله کردن ایمیل های ارسالی به Transport Service روی Mailbox Server Exchange 2013
Send Connector دیگری معادل همان Send Connector intra-organization به نام mailbox delivery send connector در Mailbox Transport Service سرورهای Mailbox وجود دارد. این کانکتور هم به صورت پیش فرض ساخته و کانفیگ می شود و به صورت مخفی می باشد. Mailbox delivery send connector برای رله کردن ایمیلهای ارسالی به Transport Service و Mailbox Transport Service در Organization استفاده می شود.
به صورت پیش فرض پروتکل لاگینگ برای این کانکتور نیز غیرفعال می باشد. شما می توانید از طریق کامند نسبت به فعال یا غیرفعال سازی پروتکل لاگینک اقدام نمایید.
ساختار فایلهای پروتکل لاگ
به صورت پیش فرض فایلهای پروتکل لاگ در مسیرهای زیر قرار دارد:
– فایلهای پروتکل لاگ کانکتور دریافت کننده برای Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive

– فایلهای پروتکل لاگ کانکتور دریافت کننده برای Mailbox Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpReceive

– فایلهای پروتکل لاگ کانکتور دریافت کننده برای Front End Transport Service روی Client Access

o servers %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive

– فایلهای پروتکل لاگ ارسال کننده برای Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend

– فایلهای پروتکل لاگ ارسال کننده برای Mailbox Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpSend

– فایلهای پروتکل لاگ ارسال کننده برای Front End Transport Service روی Client Access

o servers %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend

فرمت نامگذاری برای لاگ فایلها در هر کدام از فولدرهای پروتکل لاگ به صورت prefixyyyymmdd-nnnn.log می باشد. متغیرها به صورت ذیل می باشند:
– متغیر Prefix برای کانکتور ارسال کننده SEND و برای کانکتور د ریافت کننده RECV می باشد.
– متغیر yyyymmdd نمایانگر زمان ایجاد فایل با فرمت UTC می باشد. متغیر yyyy برای سال، mm برای ماه و dd برای روز می باشد.
– متغیر nnnn برای ارزش تعداد فایلها در روز می باشد که از 1 شروع می شود.
اطلاعات در لاگ فایلها ذخیره می شوند تا جایی که حجم فایل به سقف مجاز خود برسد و سپس فایل جدیدی با شماره جدید ایجاد می شود. این پروسه در طول روز تکرار می شود. سیستم Circular Logging فایلهای تاریخ گذشته را حذف می کند وقتی که حجم فولدر از حد مجاز گذشته باشد.
پروتکل لاگ ها فایلهای TXT ای هستند که دیتاها را به صورت تقسیم بندی شده توسط Comma ایجاد نموده اند. هر پروتکل لاگ شامل Header ی می باشد که اطلاعات ذیل را در بر دارد:
– #Software نام نرم افزاری که فایل پروتکل لاگ را ایجاد نموده است. معمولا این اسم Microsoft Exchange Server می باشد.
– #Version ورژن نرم افزاری که فایل پروتکل لاگ را ایجاد نموده است. برای Exchange Server 2013 این مقدار 15.0.0.0 می باشد.
– #Log-Type مشخص می کند که فایل پروتکل لاگ مربوط به SMTP Receive Protocol Log می باشد یا SMTP Send Protocol Log
– #Date زمان ایجاد فایل را مشخص می کند.
– #Fields نام فیلد با کاما جداشده که برای فایل پروتکل لاگ استفاده می شود.
اطلاعاتی که در پروتکل فایل ذخیره می شود
پروتکل لاگ هر رخداد مربوط به SMTP را در یک خط جداگانه ذخیره می کند. اطلاعات ذخیره شده در هر خط توسط نام فیلد سازماندهی می شود. این فیلدها توسط کاما از هم جدا می شوند. در ذیل به بررسی فیلدهای مختلف می پردازیم.
– date-time زمان هر رخداد.
– connector-id نام Distinguished name (DN) کانکتور مربوط به آن رخداد
– session-id GUID که برای هر STMP Session یکتا می باشد اما برای کلیه رخدادهای مربوط به همان Session مشترک می باشد
– sequence-number شماره اندازی که از 0 شروع می شود و به ازای هر رخداد به مقدار آن افزوده می شود
– local-endpoint آیپی و پورت مربوط به مقصد لوکال که به صورت <ip address>:<port> می باشد
– remote-endpoint آیپی و پورت مربوط به مقصد اینترنتی
– event تک کاراکتری که رخداد پروتکل را معرفی می کند.

o + Connect

o – Disconnect

o > Send

o < Receive

o * Information

– Data توضیحات مربوط به رخداد SMTP
– Context اطلاعاتی متنی که احتمالا مرتبط به رخداد پیش آمده می باشد
یک گفتگوی ساده SMTP که برای ارسال یا دریافت می باشد، رخدادهای زیادی را در بر دارد در محل های مرتبط ذخیره می کند. این رخدادها در خطوط مختلف در لاگ فایلهای نوشته و ذخیره می شوند. مفدار زیادی گفتگوی SMTP برای ارسال یا دریافت ایمیل ممکن است به صورت همزمان انجام شود. که این باعث در هم آمیختگی متنهای داخل پروتکل لاگ می شود. شما از طریق session-id و sequence-number می توانید این دیتاها را مرتب کنید تا سریعتر به دیتا مورد نظر برسید.

بررسی و درک Receive Connector های پیش فرض در Exchange Server 2016

Posted on نوامبر 20, 2021مارس 27, 2022 by tilatel

وقتی که Exchange Server 2016 را نصب می کنید، پنج Receive Connector را مشاهده می کنید که به صورت پیش فرض ایجاد شده است. در این مرحله ممکن است برای شما سوال پیش بیاید که این کانکتورها چه هستند و کاربرد آنها چیست. دانستن این کانکتورهای پیش فرض برای درک کردن اینکه چگونه ایمیل به دست شما می‌رسد مفید است.

درک کانکتورهای دریافت پیش فرض در Exchange Server 2016
Exchange Server 2016 شامل دو Server Role به نامهای Mailbox Server Role و Edge Transport Server Role می باشد. Mailbox Server Role داری سه Transport Service (یا Sub Role) می باشد. این Transport Service ها Transport Pipeline نیز خوانده می شوند. ایمیل ها در بین این سه Pipeline حرکت می کند. سه Transport Service که به آن اشاره کردیم موارد زیر می باشند:
1- Front End Transport Service: این سرویس برای کلیه ایمیلهای ارسالی و دریافتی خارج از میل باکس های موجود در ایمیل سرور می باشد. این سرویس نقش صف دهی و بازرسی روی ایمیلها را ایفا نمی کند. وقتی ایمیلی از خارج سازمان می آید، اولین سرویسی که آن را دریافت می کند این سرویس می باشد. این سرویس ایمیل را به Transport Service منتقل می کند و به هیچ عنوان با Mailbox Transport به صورت مستقیم ارتباط برقرار نخواهد کرد.
2- (Transport Service (Hub Transport Service: این سرویس نقش گروه بندی و مدیریت صف ارسال و دریافت ایمیل را ایفا می کند. همچنین این سرویس بازرسی ایمیلها و بررسی آنها از لحاظ آنتی اسپم و anti-malware را انجام می دهد. این سرویس ایمیلها را از Front End Transport Service دریافت می کند و به Mailbox Transport Service منتقل می کند.
3- Mailbox Transport Service: این سرویس می باشد که در نهایت ایمیلها را دریافت و در میل باکس مرتبط قرار می دهد. این سرویس شامل دو زیر سرویس می باشد:
– Mailbox Transport Submission Service: این سرویس پیامها را از Mailbox Database دریافت می کند و آنها را به Transport Service منتقل می کند تا به مخاطب مورد نظر ارسال شود.
– Mailbox Transport Delivery Service: این سرویس ایمیل را از Transport Service دریافت می کند و از طریق (RPC (Remote Procedure Call به میل باکس مورد نظر منتقل و در آن ذخیره می کند.
برای دیدن لیست Receive Connector به کنسول (Exchange Admin Center (EAC لاگین کنید و از منوی mail flow وارد receive connector شوید:

همانطوری که در تصویر فوق مشاهده می کنید پنج Receive Connector در این لیست وجود دارد. تعداد سه کانکتور Frontend Transport Service و دو کانکتور Hub Transport Service وجود دارد. خب حال ببینیم که هر کدام از این کانکتورها چه کاری انجام می دهند.
1- Client Frontend HQ-MS1: این کانکتورها ایمیلهایی که به صورت امن شده از طریق TLS را دریافت می کند. پذیرش از طریق پورت 587 انجام می شود. این کانکتور توسط POP و IMAP استفاده می شود. این کانکتور کانکشنهای نرم افزاری IMAP و POP را به کانکتور Hub Transport Receive Connector بنام Client Proxy HQ-MS1 پروکسی می کند.
2- Default Frontend HQ-MS1: ایمیلهای ارسالی از طریق اینترنت توسط این کانکتور در پورت 25 پذیرفته می شوند. سپس این کانکتور ایمیلها را به Transport Service روی Hub Transport Service Receive Connector بنام Default HQ-MS1 روی پورت 2525 منتقل می کند.
3- Outbound Proxy Frontend HQ-MS1: اگر شما در Send Connector تیک مربوط به proxy through client access server option را زده باشید، سپس کلیه ایمیلهای خروجی توسط این کانکتور دریافت می شود. به زبان دیگر این کانکتور کلیه ایمیلهایی که توسط Transport Service ای که تیک proxy through client access server خورده باشد را دریافت می کند. اکنون ایمیلها توسط این کانکتور به اینترنت ارسال می شود. این کانکتور از طریق پورت 717 ایمیلها را دریافت می کند.

4- Client Proxy HQ-MS1: این یک سرویس Hub Transport می باشد. ایمیلها را از Frontend Service دریافت می کند وبه Mailbox Transport Service منتقل می کند. این کانکتور از پورت 465 دریافت می کند. این Receive Connector کانکشن های POP و IMAP پراکسی شده را که از Frontend Transport Service بنام Client Frontend HQ-MS1 ارسال شده دریافت می کند.
5- Default HQ-MS1: این یک Hub Transport Service می باشد. این کانکتورهای ایمیلهای دریافتی را از Frontend Transport Service دریافت می کند و به Mailbox Transport Service منتقل می کند. مشابه همین، ایمیلهای ارسالی را از Mailbox Service دریافت می کند و به Send Connector جهت ارسال ایمیل به اینترنت یا دریافت از طریق کانکتور Outbound Proxy Frontend HQ-MS1 (در صورتی که تیک proxy through client access server در Send Connector خورده باشد) منتقل می کند. این کانکتور ایمیلها را از طریق پورت 2525 دریافت می کند.

نحوه ی کانفیگ کردن دیتابیس در Exchange Server 2016

Posted on نوامبر 17, 2021نوامبر 17, 2021 by tilatel

در این مقاله قصد داریم تا شما را با نحوه ی ساخت و کانفیگ دیتابیس در Exchange Server 2016 آشنا کنیم با ما همراه باشید:

تصور اشتباهی که خیلی از افراد در مورد دیتابیس Exchange Server دارند، برابری این دیتابیس با دیتابیس های SQL Server می باشد. توجه داشته باشید که دیتابیس Exchange Server به هیچ عنوان همانند دیتابیس های SQL Server نمی باشد. در نتیجه قابلیت اتصال یک دیتابیس از یک Exchange Server به یک Exchange Server دیگر وجود ندارد. زمانی که Exchange Server را نصب می کنید، یک دیتابیس به صورت پیش فرض ایجاد می شود. هر چند که می توانید از همان دیتابیس برای ایجاد میل باکس ها استفاده کنید اما ما پیشنهاد می کنیم که از یک دیتابیس جدید برای این موضوع استفاده کنید.
برای ایجاد دیتابیس به صورت ذیل عمل می کنیم:

مطابق تصویر فوق وارد منوی Server و از آنجا وارد Databases می شویم و اقدام به ایجاد دیتابیس جدید می کنیم. مواردی که باید در حین ساخت دیتابیس جدید در Exchange Server 2016 انجام دهیم شامل:
– نام دیتابیس
– سروری که قصد ساختن دیتابیس برای آن دارید
– مسیر لاگهای مربوط به دیتابیس
– تعیین عملیات مانت شدن یا نشدن
نکته ای که در این قسمت وجود دارد این است که پیشنهاد می کنیم تیک مربوط به Mount this database را بردارید و پس از ذخیره کردن دیتابیس و ایجاد شدن آن، اقدام به مانت کردن کنید. علت این است که تاخیری که در ساخت دیتابیس و ارتباط با اکتیودایرکتوری وجود دارد باعث بروز خطائی می شود که این موضوع با به تاخیر انداختن عملیات مانت دیتابیس مرتفع می شود.
اگر از دیتابیسها Properties بگیرید مواردی به شما نمایش داده خواهد شد.

در منوی General اطلاعات عمومی از دیتابیس نمایش داده می شود. نظیر نام دیتابیس، مسیر دیتابیس، نام سرور میزبان، آخرین وضعیت بکاپ گیری و … .

در منوی Maintenance گزینه ای با نام Enable circular logging وجود دارد که به صورت پیش فرض به صورت غیر فعال می باشد. هر گونه عملیاتی که در دیتابیس ها انجام می شود منجر به تهیه لاگ می شود، نتیجه اینکه پس از مدت کوتاهی شاهد حجم زیادی لاگ هستید حتی پس از مدتی دیگر حجم لاگ ها از حجم خود دیتابیس نیز بیشتر می شود. برای مدیریت این لاگها می بایست از طریق بکاپ سرور نسبت تهیه بکاپ به صورت مستمر اقدام کنیم. پس از تهیه بکاپ لاگ ها به صورت اتومات حذف می شوند. اما اگر در سازمانی بکاپ سرور نداشته باشید ناگزیر به استفاده از این گزینه می باشید. پس از فعالسازی این گزینه سیستم پاکسازی لاگها به صورت اتومات انجام می شود. انجام این کار به هیچ وجه پیشنهاد نمی شود.
در تب Limit می توانید محدودیت فضا به ازای هر میل باکس را مشخص کنید. به صورت پیش فرض این مقدار حدود 2 گیگابایت می باشد. همچنین می توانید محدودیت را بردارید در این صورت محدودیت متناسب با فضای هارد دیسک شما می باشد.

آشنایی با Mail Flow و نحوه ی کانفیگ آن در Exchange Server 2016

Posted on نوامبر 17, 2021 by tilatel

در این مقاله قصد داریم تا شما را با Mail Flow آشنا کنیم با ما همراه باشید:

در این مقاله قصد آموزش نکات مهم در کانفیگ Mail Flow را داریم. همانطور که می دانید پس از نصب Exchange Server و بدون انجام هیچگونه تغییری در تنظیمات Mail Flow شما قادر به دریافت ایمیل از محیط اینترنت هستید. البته با فرض انجام صحیح تنظیمات مربوط به DNS External. اما امکان ارسال ایمیل به بیرون از سازمان خود را خود را ندارید که نیاز به ساخت یک Send Connector می باشد که در مقاله قبلی آموزش ساخت آن داده شد.
در این مقاله می خواهیم تنظیمات مهمی که می بایست در کانکتورها ارسال و دریافت انجام شود تا ارسال و دریافت ایمیل با موفقیت و دقت بیشتری صورت پذیرد را آموزش خواهیم داد.
در مورد Receive Connector های پیش فرض، در یک مقاله جداگانه به نام آشنایی با Receive Connector های پیش فرض در Exchange Server 2016 نوشته ایم که از طریق لینک مربوطه می توانید آن را مطالعه کنید. پس در این مقاله در مورد آن صحبت نمی کنیم.
هماهنطور که در مقاله قبلی ذکر شد پس از نصب Exchange Server 2016 در صورتی که تنظیمات مربوط به Port Forwarding و DNS External به درستی انجام شده باشد، دریافت ایمیل خواهید داشت. این اتفاق از طریق کانکتوری با نام Default Frontend SRV-EX2016 انجام می شود. بهتر است که امکان دریافت ایمیل از طریق این کانکتور غیرفعال شود و برای دریافت ایمیل از بیرون یک کانکتور جداگانه ایجاد شود.

همانطور که در تصویر فوق مشاهده می کنید ابتدا وارد منوی Mail Flow می شویم سپس از ساب منوی Receive Connector یک کانکتور جدید ایجاد می کنیم. یک نام برای Receive Connector انتخاب می کنیم. نقش آن را Frontend Transport انتخاب می کنیم و نوع آن را Internet انتخاب می کنیم.

در ادامه یک ایپی که در واقع آیپی سرور Exchange می باشد را مشخص می کنیم و ساخت Receive Connector را به اتمام می رسانیم.
پس از اتمام ساخت مجدد وارد Properties این کانکتور می شویم.

نکته مهمی که در تنظیمات Receive Connector باید رعایت کنید وارد کردن نام MX Record در قسمت FQDN می باشد. MX Record همان رکوردی ست که در DNS Server اکسترنال ساخته می شود و و مسئول مسیردهی ایمیل های ورودی به سرور ما می باشد.
همچنین در مقاله قبلی گفتیم که به صورت پیش فرض Send Connector ی برای ارسال ایمیل به اینترنت وجود ندارد. پس لازم است که Send Connector مربوطه ساخته شود که این مورد در مقاله قبلی با نام کانفیگ اولیه Exchange Server آموزش داده شد. در مورد Send Connector نیز مراحل بالا می بایست انجام شود. وارد کردن نام MX Record در Internet Send Connector نقش مهمی در اسپم نشدن ایمیل ها دارد.

Edge Transport چیست و چه مزایایی دارد

Posted on نوامبر 16, 2021 by tilatel

آیا در محیط خود به Exchange Edge Transport نیاز دارید؟

مایکروسافت نقش Edge Transport را ابتدا به عنوان یکی از پنج نقش اصلی در Exchange 2007 معرفی کرد و دوباره آن را در Exchange 2010 ارائه کرد. هدف از نقش Edge Server این است که ترافیک SMTP ورودی محدود به محیط DMZ شود، از آنجایی که بسیاری از اتصالات SMTP ورودی غیر قابل شناسایی هستند، برخی واحد های امنیتی اجازه ارتباط مستقیم این ترافیک ها را، به منابع شبکه داخلی شما نمی دهند(Exchange Server)، Edge Transport Server، به مشتریان این قابلیت را می دهد که بدون نیاز به خرید SMTP Gateway Appliance یک ایمیل سرور راه اندازی کنند.

برای امنیت بیشتر، سرورهایی که نقش Edge Servers را اجرا می کنند Join به دامین داخلی مربوط به Exchange Organization شما نمی شوند و همینطور قادر به نصب آن در کنار دیگر Role های Exchange نیستیم، این امکان وجود داردکه Edge Server را Join یک دامین در شبکه DMZ کنید که بتوانید از Group Policy و تنظیمات امنیتی مشترک استفاده کنید، اما اکثر مشتریان Active Dirctory را در محیط DMZ خود قرار نمی دهند.

سرورهای Edge می توانند به عنوان اولین خط دفاعی شما در برابر نرم افزارهای مخرب SMTP و انکار سرویس ها (DOS,DDOS) به عنوان نقطه ورود SMTP عمل نماید. Edge Transport Role با ایمیل سرور داخلی از طریق Edge Subscription کار می کند، Edge Subscription یک اتصال متقابل معتبر و رمزگذاری شده بین سرورهای Edge و سرورهای داخلی Exchange فراهم می کند، برخی از مزایای امنیتی دیگر Edge عبارتند از:

بیشتر تنظیمات Edge Transport بر روی سرورهای داخلی Exchange انجام می شود و این پیکربندی با استفاده از فرایندی به نام EdgeSync انجام می شود، اگر یک Edge Server به هر نحوی در معرض خطر و نفود قرار بگیرد، پیکربندی Edge Transport قابل تغییر نمی باشد.
قابلیت پیشرفته Anti-Malware با استفاده از Recipient Filtering، کمی جلوتر توضیح خواهم داد.
کاهش حملات Harvest با استفاده از Tarpit، Tarpitروشی است که Edge Transport برای پاسخ دادن به دستورات نامعتبر و Recipient ها به یک مدت مشخص(پیش فرض 5 ثانیه) پاسخ های خود را به تاخیر می اندازد، این رفتار به شدت اثرات انکار سرویس و حملات Harvest را کاهش می دهد.
تمام ارتباطات Edge Sync با استفاده از گواهینامه Self-Sign Exchange، احرازهویت و رمزنگاری می شود.
تمام ارتباطات بین Edge و سرورهای Exchange داخلی از TLS Encryption استفاده می کند.

مایکروسافت موقع ارائه Exchange 2013 RTM در تاریخ 11 اکتبر 2012، آن را بدون نقش Edge Transport منتشر کرد، مشتریانی که تمایل به کنترل SMTP ورودی داشتن می توانستن از Edge Transport 2007 یا 2010 به عنوان SMTP Front-end در Exchange استفاده کنند

در Exchange 2013 SP1 دوباره نقش Edge 2013 معرفی شد و مشتریان می توانستند تمامی سرویس های ایمیل خود را به 2013 ارتقا دهند،Edge Transport ساختار اصلیش مشابه ورژن های قدیمی است اما رابط کاربری ندارد، Edge 2013 با استفاده از Exchange Management Shell مدیریت می شود و دیگر نیازی به راه اندازی IIS نیست، در حقیقت، تنها نرم افزار پیش نیاز برای نصب .Net Framework 4.5 و نقش AD LDS است.

Exchange 2013/2016 Mailbox Servers دارای Anti-Malware Protection است اما سرورهای Edge Transport به شما Recipient Filtering را ارائه می دهند، Recipient Filter Agent تمامی پیام هایNon-Authentication از طریق اینترنت را پردازش می کند و با آنها مثل پیام های خارجی رفتار می کند، این کار به Edge سرور اجازه می دهد تا کارهای زیر را انجام بدهد:

Recipient Blocking به مدیران اجازه می دهد تا SMTP Senders یا Sender Domain خاصی را Block کنند.
Mailbox های مهم را می توان فیلتر کرد تا هرگز از اینترنت ایمیلی دریافت نکنند.
Edge Transport می تواند ایمیل های ورودی بهDistribution List ، که فقط برای دریافت ایمیل از کاربران داخلی پیکربندی شده است را مسدود کند.

توجه داشته باشید که Recipient Filtering در سرورهای Exchange Mailbox هم نصب می باشد، ولی نباید آن را پیکر بندی کنید، سرورهای Mailbox قادر به تشخیص پیام های خارجی نیستند واگر یک پیام مشکوک شناسایی شود، کل پیام را مسدود می کنند.

نحوه ی نصب و پیاده سازی Certificate در Exchange Server 2016

Posted on نوامبر 16, 2021 by tilatel

در این مقاله قصد داریم تا ابتدا به بررسی انواع Trust Certificate ها و سپس به کانفیگ و نصب Certificate بر روی ایمیل سرور بپردازیم.با ما همراه باشید:

انواع Trust Certificate:
• Standard
فقط برای یک آدرس مشخص خریداری می شود مانند https://mail.tilatel.com یا https://tilatel.com
• Wildcard
برای یک دامنه به همراه subdomain مانند https://mail.tilatel.com یا https://crm.tilatel.com
• SAN(Subject Alternative Names)
برای استفاده در چندین دامنه کاربرد دارد، فرض کنید شرکت یا سازمان شما دارای دامنه های pardismail.com،pardismail.ir و pardismail.org هست، بهترین راه برای خرید certificate استفاده از SAN Certificate هست که می تواند همه این دامنه ها را پوشش بدهد به جای اینکه اقدام به خرید چند دامنه کنیم.

مراحل نصب و کانفیگ certificate در exchange
• ساخت یک فولدر share در شبکه برای ذخیره اطلاعات
• ایجاد یک CSR در ایمیل سرور
• استخراج Certificate خروجی و خرید Certificate
• Import کردن Certificate و Assign کردن به سرویس های میل سرور
در مرحله اول یک فولدر در شبکه ایجاد نمایید و در تب sharing، قسمت Advanced sharing را انتخاب و به everyone مجوز full control بدهید و سپس در تب Security مجوز NTFS برای گروه Exchange Trusted Subsystem را بر روی Full Control قرار بدهید.
مرحله دوم ایجاد یک Requset Certificate:
مطابق شکل زیر بر روی + کلیک نمایید.

سپس در wizard باز شده گزینه create a request را انتخاب و بر روی Next کلیک نمایید.

در این صفحه در فیلد friendly یک نام برای این certificate انتخاب کنید(این نام فقط برای نمایش در کنسول است و بهتر است در صورتی که دارای چند certificate هستید نامی را انتخاب کنید که بعدا بتوانید certificate خود را به راحتی پیدا کنید) و بر روی next کلیک کنید.

در صفحه زیر در صورتی که قصد تهیه یک wildcard certificate را دارید انتخاب و اسم دامنه خود را وارد کنید، در غیر اینصورت بدون هیچ تغییری بر روی next کلیک کنید.

در صفحه بعد یکی از سرور های میل سرور را برای ذخیره سازی request انتخاب کنید(در صورتی که چندین سرور برای میل سرور خود راه اندازی کرده باشید).

در صورتی که wildcard را انتخاب کرده باشید این صفحه را مشاهده نخواهید کرد، در غیر اینصورت سرویس هایی را که قصد ایمن کردن آنها را دارید انتخاب کنید.

در صفحه بعد شما قادر به مرور مجدد نام های پیشنهادی در certificate request هستید، در صورت نیاز قادر به اضافه کردن و حذف کردن هستید، بر روی Next کلیک نمایید.

در صفحه بعد اطلاعاتی در مورد سازمان یا شرکت، منطقه و .. از شما درخواست می کند که باید تکمیل نمایید.

در صفحه بعد مسیر فولدری که برای ذخیره در مرحله اول ایجاد کردید را وارد نمایید.

در مرحله سوم باید به یکی از سایت های معتبر خرید SSL مراجعه کنید ، پس از خرید، فایل های خروجی را در مسیر share قرار دهید.
مطابق شکل زیر بر روی Certificate Request که در حالت Pending request کلیک و در پنل سمت چپ بر روی Complete کلیک نمایید.

در صفحه باز شده مسیر share فولدری را که فایل cer را قرار داده اید را وارد نمایید و بر روی OK کلیک نمایید، اکنون Certificate بر روی میل سرور نصب شده است.

در مرحله بعد Certificate را انتخاب و گزینه ویرایش را بزنید در صفحه باز شده از سمت چپ بر روی Services کلیک نمایید و سرویس های مورد نظر را انتخاب و بر روی save کلیک نمایید.

کار تمام است و اکنون قادر به استفاده از میل سرور به صورت امن بر روی پروتکل SSL هستید.

نحوه ی نصب و کانفیگ آنتی اسپم در Exchange Server 2016

Posted on نوامبر 14, 2021 by tilatel

در این مقاله قصد داریم تا شما را با نحوه ی نصب و کانفیگ آنتی اسپم در Exchange Server 2016 آشنا کنیم با ما همراه باشید:

در exchange server 2010 موقع فعال سازی Anti Spam به راحتی قادر به مدیریت این ماژول در کنسول EMC بودید، ولی از نسخه 2013 به بعد این امکان حذف گردید و فقط طریق Powershell امکان مدیریت آن مهیا است.

به صورت پیش فرض Anti Spam در سروری که دارای رول Mailbox است، نصب نیست و شما باید در ابتدا از طریق پاورشل آن را نصب نمایید.

& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1

دستور بالا موجب اجرا شدن یک اسکریپت برای نصب Anti Spam می شود، بعد از نصب شدن نیاز هست که یکبار سرویس Microsoft Exchange Transport Service را ریستارت کنید، پس دستور زیر را در پاورشل اجرا کنید.

Restart-Service MSExchangeTransport

حال که Anti Spam نصب شد باید شروع به کانفیگ کنیم پس Exchange Management Powershell را باز کنید.

در این مرحله ابتدا سرورهای Exchange را به Anti Spam Agent معرفی کنید:

Set-TransportConfig -InternalSMTPServers 192.168.1.1

در صورتی که در مجموعه بیش از یک سرور دارید به شکل زیر می‌توانیم همه سرورها را معرفی کنیم:

Set-TransportConfig -InternalSMTPServers 192.168.1.1, 192.168.1.2

مرحله دوم تنظیم IP Blocklist Provider

IP Blocklist Provider نوعی خاص از ارائه دهندگان سرویس DNS هست که مدیران می‌توانند از آن برای کاهش Spam ها استفاده کنند، به زبانی ساده تر یک سری سایت ها هستند که شامل یک دیتابیس بروز از Spammer ها هستند و زمانی که exchange یک درخواست از بیرون دریافت میکند از طریق ارسال DNS Query به این Provider امکان شناسایی Spammer ها رو فراهم می کند.

یکی از معروف ترین سایت ها در این زمینه spamhaus.org هست، برای انجام تنظمیات دستور زیر را اجرا کنید.

“Add-IPBlockListProvider -Name “SpamHaus IP Block List Provider” -LookupDomain “zen.spamhaus.org

برای ارسال یک پیغام به فرستنده در صورتی که ارسال کننده به عنوان یک Spammer شناخته شده باشد از دستور زیر استفاده کنید.

Set-IPBlockListProvider “SpamHaus IP Block List Provider” -RejectionResponse “Your message was rejected because the IP address of the server sending your message is in the block list of pardismail.com IP Block List Provider service. No soup for you.”

برای track کردن کارهایی که Anti Spam Agent انجام می‌دهد دستور زیر را اجرا کنید.

set-TransportService Mailboxserver -AgentLogPath “D:\spamlogs” -AgentLogMaxFileSize 30MB -AgentLogMaxDirectorySize 250MB -AgentLogMaxAge 7.00:00:00

بسته به نیاز و چارچوب های سازمانتان مقادیر رو تغییر بدید.

برای فیلتر کردن ایمیل ها بر اساس محتوا:

Set-ContentFilterConfig -Enabled $true

در صورت بروز مشکل در Anti Spam Agent آن را غیر فعال کنید.

Set-ContentFilterConfig -Enabled $false

Anti Spam Agent ایمیل های دریافتی را بر اساس میزان سطح اعتماد تقسیم بندی و از 0 تا 9 به آنها مقداری می‌دهد که به SCL معروف است، که هرچه این میزان به 9 نزدیک تر باشد احتمال Spam بودن ایمیل بیشتر است.

Set-ContentFilterConfig -SCLDeleteEnabled $true -SCLDeleteThreshold 9 -SCLRejectEnabled $true -SCLRejectThreshold 7 -SCLQuarantineEnabled $true

با دستور بالا می توانید مشخص کنید بر اساس SCL چه رفتاری با ایمیل شود، و با دستور زیر هم می‌توانید یک پیغام سفارشی در صورتی که ایمیل Reject شد به فرستنده ارسال کنید.

Set-ContentFilterConfig -RejectionResponse “hey Mr that email was spammy!”

در صورتی که ایمیل های دریافتیتان از دامین یا آدرس خاصی بلاک و به عنوان اسپم شناخته می‌شود با دستورات زیر می توانید عمل Trust را انجام بدید.

Set-ContentFilterConfig -BypassedSenderDomains <SmtpDomainWithSubdomains>

Set-ContentFilterConfig -BypassedSenderDomains example.com

Set-ContentFilterConfig -BypassedSenderDomains *.example.com

Set-ContentFilterConfig -BypassedRecipients <SmtpAddress>

Set-ContentFilterConfig -BypassedSenders trust@sample.com

Set-ContentFilterConfig -BypassedSenders trust@sample.com, trust1@sample.com

نحوه ی کانفیگ کردن SPF Record در Exchange Server 2016

Posted on نوامبر 14, 2021نوامبر 14, 2021 by tilatel

در این مقاله قصد داریم تا شما را با نحوه ی کانفیگ کردن SPF Record در Exchange Server 2016 آشنا کنیم با ما همراه باشید:

SPF مخفف Sender Policy Framework به معنی چارچوب سیاست فرستنده می باشد. پس از ارسال ایمیل از یک ایمیل سرور و قبل از دریافت ایمیل توسط ایمیل سرور مقصد، سروری در اینترنت با نام Sender ID Framework مسئول بررسی اعتبار سرور ارسال کننده ایمیل می باشد.

یک SPF (Sender Policy Framework) Record لیست Mail Server هایی می باشد که مجاز هستند از طرف و به اسم دامنه سازمان شما به بقیه میل سرورها میل ارسال کنند.
این رکورد باعث کاهش فعالیت Spamming از طرف اسم دامنه سازمان شما می شود. یعنی هر میل سروری مجاز به استفاده از دامنه ما برای ارسال ایمیل نمی باشد.

SPF Record یکی از انواع رکوردهای DNS Server می باشد که معمولاً با پسوند txt در DNS Server ساخته می شود. اما ساخت SPF Record دارای اصولی می باشد که ما برای اطمینان از صحت ساخت آن می توانیم از طریق سایتهای معتبر در اینترنت نسبت یه ایجاد آن اقدام کنیم. یکی از معروف ترین سایتهای SPF Generator سایت www.spfwizard.net می باشد.

– برای ساخت SPF Record نام دامین مورد نظرمان را در قسمت Your Domain وارد می کنیم.
– فیلد بعدی (Allow servers listed as MX to send email for this domain) برای مشخص سازی این مطلب می باشد که آیا MX Record های ثبت شده در DNS Server اجازه ارسال ایمیل دارند یا خیر. در اکثر مواقع MX Record ها مسئول ارسال ایمیل نیز می باشند، اما شاید در شبکه ای IP مربوط به MX Record صرفاً برای دریافت ایمیل باشد و IP دیگری مسئول ارسال ایمیل باشد، پس بر اساس سیاست داخلی شبکه این گزینه را انتخاب می کنیم.
– فیلد بعدی : (Allow current IP address of the domain to send email for this domain) جهت مشخص کردن این مطلب می باشد که آیا A Record های تعریف شده در DNS Server دامین، مجاز به ارسال ایمیل می باشند یا خیر. این مورد نیز کاملاً وابسته به نوع شبکه می باشد، ولی معمولاً A Record ها مربوط به هاستینگ وب سایت ما می باشد و در صورتی که ما ایمیل سرور داخلی داشته باشیم، A Record ها مجاز به ارسال ایمیل نمی باشند.
– فیلد بعد: (Allow any hostname ending in yourdomain.com to send email for this domain) جهت مشخص سازی این مطلب می باشد که آیا هر رکوردی با پسوند yourdomain.com برای مثال ftp.yourdomain.com مجاز به ارسال ایمیل از طریق این دامین می باشد یا خیر، که در اکثر مواقع جواب این فیلد خیر می باشد.
– در فیلد بعدی : (IP addresses in CIDR format that deliver or relay mail for this domain) می توانیم IP آدرس هایی که مجاز به ارسال ایمیل با دامین مورد نظر ما می باشند را تعیین کنیم. این آدرس IP میتواند یک تک IP و یا یک رنج IP باشد.
– در فیلد : (Add any other server hostname that may deliver or relay mail for this domain) می توانیم سایر سرورهایی که مجاز به ارسال ایمیل از طرف دامین اصلی ما می باشند را تعریف کنیم. این قسمت برای زمانی می باشد که شما بخواهید به یک دامین اجازه ارسال از چند سرور مختلف که برای شما می باشد را بدهید. برای مثال شما مالک چهار دامین مختلف می باشید که هر کدام به صورت مستقل امکان ارسال ایمیل را با MX Record های خودشان دارند اما می خواهید اگر با MX Record یکی دیگر از دامین هایتان نیز ارسال شد مشکلی پیش نیاید. این موضوع معمولاً به ندرت پیش می آید. در صورت نیاز می توانید NS های سایر دامین هایتان را در این قسمت وارد نمایید.
– فیلد : (Any domains that may deliver or relay mail for this domain) کاملاً مشابه با فیلد بالا می باشد با این تفاوت که در فیلد بالا NS های مجاز را تعریف می کنیم و در این فیلد Domain Name های مجاز را تعریف می کنیم.
– فیلد : (How strict should be the servers treating the emails?) میزان شدت سخت گیری SIDF را تعیین می کند. به این صورت که می توان میزان سخت گیری را به حداکثر رساند (Fail (Not (compliant will be rejected) که در این صورت اگر شرایط تعیین شده شما در SPF رکود Pass نشود ایمیل به مقصد نخواهد رسید و برگشت می خورد، یا میزان سخت گیری را در حال متوسط (SoftFail (Not compliant will be accpted but marked) قرار می دهیم که در این صورت ایمیل به مقصد می رسد اما به صورت اسپم به آدرس مقصد می رسد و یا سخت گیری را در حالت حداقل (Neutral (Mails will be probably accepted)) قرار می دهیم که در این صورت، در هر حالت ایمیل به مقصد می رسد. این مورد نیز به سیاست ایمیل سرور شما مربوط می شود اما از لحاظ منطقی بهتر است شرایط را در حداکثر سخت گیری قرار می دهیم.
همانطور که در طی ساخت SPF Record مشاهده نمودید، خروجی نهایی یک خط متن می باشد. متن نهایی را به صورت یک TXT Record در DNS Server ایجاد کنید.
نحوه ساخت SPF Record در DNS مایکروسافتی:
در کنسول DNS، Zone مورد نظر خود را انتخاب کنید و در قسمت رکورد ها کلیک راست و بر روی Create another Recordکلیک نمایید و text را انتخاب و Create Record بزنید.

در پنجره جدید در قسمت Text متن رکورد SPF خود را وارد نمایید و بر روی Ok کلیک نمایید.

و در انتها مشاهده خواهید کرد رکورد SPF شما ایجاد شده است.

معرفی انواع روش های کاهش سایز دیتابیس میل باکس Exchange

Posted on نوامبر 13, 2021 by tilatel

این مقاله در مورد انواع روش های کاهش سایز دیتابیس میل باکس Exchange صحبت میکند و از مزایا و معایب آن برای شما خواهد گفت. همچنین یک روش عملیاتی به صورت کامل شرح داده می‌شود.

توضیحات:

در حالت عادی زمانی که Exchange Server را راه اندازی می کنید، حجم دیتابیس بر اساس دیتاهای وارد شده افزایش پیدا می کند اما پس از حذف دیتاها از دیتابیس حذف نمی شوند و نیاز است برای پاکسازی دیتاها پاک شده از روش های دیگری استفاده کنید. در نظر داشته باشید که این مورد حتی در صورت تهیه فول بکاپ نیز از دیتابیس حذف نمی شود.

روش عملیاتی
Reclaim کردن فضای دیسک بر روی میل باکس Exchange سرور دو روش دارد:
1. ساخت و ایجاد دیتابیس جدید در Exchange و Migration تمام میل باکس ها به صورت آنلاین از دیتابیس قدیمی به دیتابیس جدید
اینکار به صورت آنلاین انجام میشود و هیچ گونه اختلالی در خدمات رسانی ایجاد نمیگردد و روشی کاملا امن است. اما دقت کنید که ساخت دیتابیس میل باکس جدید و فرستادن همه میل باکس های قدیمی به آن، خود اضافه کاری زیادی به همراه دارد. به علاوه این روش لاگ های زیادی تولید کرده و نیازمند فضای حجیمی است و ادمین در حین انجام کار باید دائما به سیستم نظارت داشته باشد.
2. دیفرگ آفلاین دیتابیس موجود
در این روش دیتابیس به حالت آفلاین میرود و از دستور eseutil برای دیفرگ کردن دیتابیس استفاده میکنیم. در نتیجه اینکار فایلهای اضافی از دیتابیس شما حذف می شود و در واقع حجمی که به شما نشان می دهد میزان فضای اشغال شده واقعی می باشد. چیزی شبیه به دیفرگ کردن فایل های سیستم می باشد.
این روش دردسرهایی هم به همراه دارد. تا زمانی که دیتابیس Dismount شده هیچ کاربری نمیتواند از میل خود استفاده نماید. البته توجه داشته باشید که این روش سریعتر از فرستادن میل باکس ها به دیتابیس جدید است و بار کاری کمتری به همراه دارد. دیفرگ آفلاین امنیت میل باکس Migration را ندارد اما دیتابیس اصلی را دست نخورده باقی میگذارد.
دیفرگ آفلاین فضایی نیاز دارد تا دیتابیس موقتی ایجاد کرده و دیتابیس کنونی را در حین دیفرگ کردن درون آن قرار دهد. حالا فرض کنید در درایوی که دیتابیس قرار گرفته هیچ فضای خالی در اختیار ندارید در اینجاست که باید یک درایو به همان اندازه دیتابیس اضافه کنید یا فضایی را در شبکه تخصیص دهید.
کدام روش مناسب است ؟!
جواب این سوال وابستگی مستقیمی به شرایط و وضعیت شما دارد. با توجه به مزایا و معایبی که از دو روش برای شما شرح دادم تصمیم بگیرید و کار مناسب را شروع کنید. من روش دوم را انتخاب کردم و به نتیجه رسیدم
دیفرگ کردن دیتابیس آفلاین
دست بکار شوید.
1- وارد محیط Exchange Management Shell شوید و دستور زیر را تایپ کنید:

“C:\ Windows\ system32>cd D:\ Mailbox\ ‘database name’”
“D:\ Mailbox\ ‘database name’> Dismount-Database ‘database name’”

در دستورات بالا ما ابتدا وارد دایرکتوری شدیم که دیتابیس قرار دارد و سپس آن دیتابیس را Dismount کردیم البته از طریق محیط ECP هم امکان Dismount کردن وجود دارد کافی است مسیر زیر را طی کنید :

Servers> databases> select Database> … > Dismount

2- دستور eseutil را مطالبق با سوئیچ های زیر وارد نمایید:

“D:\ Mailbox\’database name’>eseutil /d ‘database name’.edb /t\\ testserver \defrag\temp.edb”

3- بعد از اتمام کار و مشاهده پیغام تکمیل موارد میتوانید از دستور زیر برای Mount کردن مجدد دیتابیس استفاده نمایید.

“D:\ Mailbox\ ‘database name’> mount- database ‘database name’”

حالا دیتابیسی دارید که هم حجم آن کم شده است هم کاملا دیفرگ شده است .

بهین ارتباط هوشمند

دسته: مقالات شبکه