איך עובד אימייל?

ראשית, אתה משתמש בסוכן משתמש בדואר, או ב- MUA כדי לקרוא ולשלוח דוא"ל מהמכשיר שלך (כגון gmail, או מאפליקציית הדואר במכשירי Apple). תוכניות אלה פעילות רק כאשר אתה משתמש בהן.

באופן כללי, הם מתקשרים עם סוכן העברת דואר, או MTA (הידוע גם כשרת דואר, מארח MX ומחליף דואר), המשמש לקבלת ואחסון הדוא"ל שלך.

דואר אלקטרוני נשמר מרחוק עד שתפתח את ה- MUA שלך על מנת לבדוק את הדוא"ל שלך. המיילים נשלחים על ידי סוכני משלוח דואר (MDA), אשר בדרך כלל ארוזים ב- MTA.

בעבר נשלח דואר לשרת דואר באמצעות SMTP, או פרוטוקול העברת דואר פשוט. SMTP הוא פרוטוקול תקשורת לדוא"ל.

גם עכשיו, בעוד שמערכות קנייניות רבות כמו Microsoft Exchange ותוכנות דואר אינטרנט כמו Gmail משתמשות בפרוטוקולים משלהן באופן פנימי, הן משתמשות ב- SMTP כדי להעביר הודעות מחוץ למערכות שלהם (למשל, אם משתמש Gmail רוצה לשלוח דוא"ל ללקוח Outlook).

לאחר מכן הורד דואר מהשרת באמצעות פרוטוקול Post Office (POP3) POP3 הוא פרוטוקול שכבת יישום המספק גישה דרך פרוטוקול אינטרנט (IP) ליישום משתמש ליצור קשר עם תיבת דואר בשרת דואר. הוא יכול להתחבר, לאחזר הודעות, לאחסן אותן במחשב הלקוח ולמחוק או לשמור אותן בשרת.

הוא תוכנן כך שיוכל לנהל חיבורי אינטרנט זמניים, כגון חיוג (כך שהוא פשוט יתחבר ויאחזר דוא"ל כשהוא מחובר, ויאפשר לך להציג את ההודעות כשהיית במצב לא מקוון). זה היה פופולרי יותר כאשר הגישה לחיוג הייתה נפוצה יותר.

כעת, IMAP, פרוטוקול גישה להודעות אינטרנט, החליף בעיקר את POP3. IMAP יכול לאפשר למספר לקוחות לנהל את אותה תיבת דואר (כך שתוכל לקרוא את הדוא"ל שלך משולחן העבודה, המחשב הנייד והטלפון שלך וכו 'וכל ההודעות שלך יהיו שם, מסודרות באותו אופן).

בסופו של דבר, דואר אינטרנט החליף את שניהם. דואר אינטרנט מאפשר לך להתחבר לאתר ולקבל הודעות מכל מקום או מכל מכשיר (כן!), אולם אתה צריך להיות מחובר לאינטרנט בזמן השימוש בו. אם האתר (כמו gmail) הוא ה- MUA שלך, אינך צריך לדעת את הגדרות שרת SMTP או IMAP.

כיצד מאובטח דוא"ל?

לרוע המזל, אבטחה לא הייתה ממש מובנית בפרוטוקולי דואר מההתחלה (כמו רוב פרוטוקולי האינטרנט המתחילים). השרתים פשוט ציפו לקחת כל הודעה ממישהו ולהעביר אותה לכל שרת אחר שיעזור לנתב את ההודעה ליעדה הסופי (הנמען בשדה to:).

באופן לא מפתיע, זה הפך להיות נושא כאשר האינטרנט התרחב מכמה קבוצות ממשלתיות ומחקרות למשהו שרוב העולם משתמש בו לעשות בעצם הכל. די מהר הודעות דואר זבל ודיוג הפכו (ונשארו) לבעיה ענקית עבור כולם.

בתגובה, ניסינו ביחד ליישם כמה אמצעים שמונעים מאנשים לקרוא הודעות של אחרים (הצפנה) ולאמת שההודעות אכן הגיעו מהשולח כביכול (אימות).  

ברוב המקומות משתמשים ב- TLS (אבטחת שכבת תחבורה, החלפה ל- SSL, שכבת שקעים מאובטחת), פרוטוקול הצפנה המספק הצפנה במעבר. הוא מספק הגנה למועד העברת ההודעה, אך לא כאשר הנתונים במנוחה, (למשל, שמירתם במחשבך).

זה מבטיח שההודעה לא תשתנה או תחטוף בזמן שהיא נוסעת מ- MTA ל- MTA. עם זאת, הדבר אינו מאמת שההודעה לא שונתה במהלך הנסיעה.

לדוגמא, אם הדוא"ל עובר דרך שרתי דואר מרובים לפני שהוא מגיע ליעדו הסופי, שימוש ב- TLS יבטיח שהוא מוצפן בין השרתים, אך כל שרת יכול לשנות את תוכן ההודעה. כדי לטפל בכך, יצרנו SPF, DKIM ו- DMARC.

SPF (מסגרת מדיניות שולחים)

SPF מאפשר לבעלים של דומיין (כמו google.com) לקבוע רשומת TXT ב- DNS שלו המציינת אילו שרתים רשאים לשלוח דואר מאותו דומיין (לקבלת הוראות כיצד לעשות זאת עבור מגוון ספקי אירוח בדוק זאת אֲתַר).

איך זה עובד?

רשומה זו מפרטת את המכשירים (בדרך כלל לפי IP) המותרים ויכולים להסתיים באחת מהאפשרויות הבאות:

-all = אם הבדיקה נכשלת (מקור הדוא"ל אינו אחד המכשירים המפורטים) התוצאה היא HardFail. מרבית מערכות הדואר יסמנו הודעות אלה כספאם.

? all = = אם הסימון נכשל (מקור הדואר האלקטרוני אינו אחד המכשירים המפורטים) התוצאה היא ניטרלית. זה משמש בדרך כלל לבדיקה, ולא לתחומי ייצור.

~ הכל = אם הסימון נכשל (מקור הדוא"ל אינו אחד המכשירים המפורטים) התוצאה היא SoftFail. פירוש הדבר שהודעה זו חשודה, אך אינה בהכרח רע ידוע. מערכות דואר מסוימות יסמנו הודעות אלה כספאם, אך רובן לא.

כותרות SPF יכולות להיות מועילות לשרתים עצמם, מכיוון שהם מעבדים הודעות. לדוגמה, אם שרת נמצא בקצה הרשת, הוא יודע שההודעות שהוא מקבל צריכות להגיע משרתים ברשומת ה- SPF של השולח. זה עוזר לשרתים להיפטר מדואר זבל מהר יותר. למרות שזה נשמע נהדר, למרבה הצער, יש כמה בעיות עיקריות עם SPF.

1. SPF לא אומר לשרת דואר מה לעשות עם ההודעה - כלומר הודעה יכולה להיכשל בבדיקת SPF ועדיין להימסר.
2. רשומת SPF אינה מסתכלת על הכתובת 'מ-' שהמשתמש רואה, אלא מסתכלת על 'נתיב החזרה'. זה בעצם המקבילה לכתובת ההחזרה שאתה כותב על מכתב. הוא אומר לשרתי הדואר המטפלים באות היכן להחזיר את ההודעה (והיא נשמרת בכותרות הדוא"ל - למעשה שרתי המידע הטכניים משתמשים בה לעיבוד הדוא"ל).

   זה אומר שאני יכול להכניס את מה שאני רוצה לכתובת from: וזה לא ישפיע על בדיקת ה- SPF. למעשה, שתי כתובות הדוא"ל יכולות להיות מזויפות יחסית על ידי האקר. מכיוון שלא מדובר בהצפנה, לא ניתן לסמוך לחלוטין על כותרות SPF.

3. רשומות ה- SPF צריכות להתעדכן כל הזמן, דבר שעלול להיות קשה בארגונים גדולים ומשתנים.
4. העברה שובר SPF. הסיבה לכך היא שאם דוא"ל מ- google.com למשל, מועבר על ידי [email protected], שולח המעטפה נשאר ללא שינוי (הכתובת מאת עדיין אומרת google.com). שרת הדואר המקבל חושב שהוא טוען שהוא מ- google.com, אך הוא מגיע מ- bobsburgers.com, ולכן הוא נכשל בבדיקת ה- SPF (למרות שהדואר אכן מגיע מ- google.com).

לקריאה נוספת על SPF עיין במאמרים אלה. אתה יכול לבדוק אם לתחום ספציפי מוגדרים רשומות SPF ו- DMARC כאן.

DKIM (DomainKeys Identified Mail)

DKIM דומה ל- SPF. הוא משתמש גם ברשומות TXT ב- DNS של הדומיין השולח, והוא מספק אימות מסוים של ההודעה עצמה. היא מנסה לספק אימות שההודעות לא שונו במעבר.

איך זה עובד?

הדומיין השולח מייצר צמד מפתחות ציבורי / פרטי ומכניס את המפתח הציבורי לרשומת ה- DNS TXT של הדומיין (אם אינך יודע מהו צמד מפתחות ציבורי / פרטי, עיין במאמר זה בנושא הצפנה).

לאחר מכן, שרתי הדואר של התחום (בגבול החיצוני - השרתים השולחים דואר מחוץ לתחום (למשל מ- gmail.com ל- outlook.com)) משתמשים במפתח הפרטי כדי ליצור חתימה של כל גוף ההודעות, כולל כותרות.

יצירת חתימה מחייבת בדרך כלל חשיפה והצפנה של הטקסט (לפרטים נוספים על תהליך זה, עיין במאמר זה).

קבלת שרתי דואר משתמשים במפתח הציבורי ברשומת ה- DNS TXT כדי לפענח את החתימה ואז לחשוף את ההודעה ואת הכותרות הרלוונטיות (כל הכותרות שנוצרו בזמן שהדואר היה בתוך תשתית השולח - למשל אם שרתי Gmail מרובים עיבדו את הדוא"ל לפניו נשלח חיצונית ל- outlook.com).

לאחר מכן השרת יוודא ששני החשיפות תואמים. אם כן, ייתכן שההודעה לא השתנתה (אלא אם כן מישהו התפשר על המפתח הפרטי של השולח) ולגיטימיות מהשולח כביכול. אם החשיפות אינן תואמות, ההודעה לא הייתה מהשולח כביכול, או שהיא שונתה על ידי שרת אחר במעבר, או שניהם.

DKIM עושה עבודה טובה מאוד במשימה ספציפית אחת - לענות על השאלה 'האם הודעת דוא"ל זו שונתה במעבר או לא מהשולח כביכול?'. עם זאת, זה כל מה שהוא עושה. זה לא אומר לך כיצד להתמודד עם הודעות דוא"ל שנכשלות בבדיקה זו, איזה שרת אולי שינה את ההודעה או אילו שינויים בוצעו.  

DKIM משמש גם ספקי אינטרנט מסוימים, או ספקי שירותי אינטרנט, כדי לקבוע את המוניטין של הדומיין שלך (האם אתה שולח הרבה דואר זבל? האם יש לך מעורבות נמוכה? באיזו תדירות הדוא"ל שלך מקפיץ?).

לקריאה נוספת ב- DKIM עיין במאמר זה. תוכל לאמת רשומת DKIM כאן.

DMARC (אימות הודעות מבוסס-תחום, דיווח והתאמה)

DMARC הוא למעשה הוראות לשרתי דואר כיצד לטפל ברשומות SPF ו- DKIM. היא לא מבצעת בדיקות משלה, אך היא מורה לשרתי הדואר כיצד לטפל בבדיקות שמבצעים SPF ו- DKIM.

ספקי האינטרנט המשתתפים יסתכלו על רשומות DMARC שפורסמו וישתמשו בהם כדי לקבוע כיצד להתמודד עם כישלונות DKIM או SPF. כך למשל, מותג מזויף נפוץ עשוי לפרסם רשומת DMARC שאומרת שאם DKIM או SPF נכשלים, שחרר את ההודעה.

לעיתים קרובות ספקי האינטרנט ישלחו אליך גם דוחות על פעילות הדומיין שלך עם מקור הדוא"ל והאם הוא עבר / נכשל ב- DKIM / SPF. פירוש הדבר שתוכל לראות מתי אנשים מזייפים (מתיימרים לשלוח) מהדומיין שלך או משנים את ההודעות שלך.

על מנת ליישם את DMARC, עליך ליצור רשומת DMARC, בהתבסס על צרכיך (ממעקב אחר תעבורת הדוא"ל שלך כדי להבין מה כל מקורות הדוא"ל שלך ועד לבקשת פעולות, כמו דחיית כל הודעות דוא"ל שנכשלות ב- DKIM או SPF). תוכלו ללמוד עוד על עשייה כאן וכאן.

לקריאה נוספת על DMARC עיין במאמר זה. אתה יכול לבדוק אם לתחום ספציפי מוגדרים רשומות SPF ו- DMARC כאן.

לעטוף

אף אחד מאמצעי האבטחה הללו אינו מושלם, אך יחד הם עושים עבודה ראויה בכדי לעזור לנו לשפר את האבטחה של מערכות דוא"ל ברחבי העולם.

ככל שיהיו יותר ארגונים שיאמצו אמצעים אלה (באמצעות יישומי קוד פתוח או תשלום עבור מוצר) כך יהיה טוב יותר לכולם. אבטחה שנוספה לאחר פיתוח פרוטוקול או מוצר היא בדרך כלל יקרה יותר, פחות יעילה וקשה יותר ליישום, מאשר האבטחה המובנית במוצר.

עם זאת, רוב הפרוטוקולים עליהם מסתמך האינטרנט הנוכחי תוכננו לאינטרנט המוקדם - עבור קבוצה קטנה של חובבים, מדענים ואנשי ממשל - לא רשת עולמית בה אנו מפעילים בניינים, מכשירים חכמים, תחבורה ציבורית, תחנות גרעין. (!), וכן הלאה.

לפיכך, ככל שהאינטרנט המשיך להתרחב, עלינו להמשיך להסתגל ולפתח דרכים חדשות לאבטחת המערכות עליהן אנו מסתמכים.