תבנית כתובת דואר אלקטרוני: כללי תחביר ומגבלות אמת

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

שני החצאים משני עברי סימן הכרוך

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

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

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

כמה ארוכה יכולה כתובת להיות?

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

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

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

מה התקן מתיר ורוב השירותים דוחים

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

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

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

מדוע כתובת תקפה עדיין נדחית?

שלוש סיבות, ואף אחת מהן אינה קשורה לתחביר.

הראשונה היא שהדומיין עשוי שלא לקבל דואר כלל. כתובת מושלמת מבחינת תחביר בדומיין שאין לו שרת מקבל, או כזה שדוחה כל דואר, אינה ניתנת למסירה. זה בדיוק המקרה שתיבת דואר זמנית נבנתה כדי לעקוף: כלי הדואר הזמני מוסר כתובת בדומיין שמקבל דואר ברגע זה, כך שמסלול המסירה הוא החלק שאין צורך לסדר לבד.

השנייה היא כלל של שירות מסוים. מוצר עשוי להגביל אילו דומיינים הוא מקבל, או אילו תווים הוא מתיר בשם משתמש, מסיבות שאין להן קשר לתקן. ההגבלות האלה הן מדיניות, וכדאי לתאר אותן כמדיניות ולא לעטוף אותן כאימות.

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

הפקת כתובות ששירותים מקבלים

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

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

כל מה שנדון כאן מתאר את הצורה של כתובת ולא אדם. אין להתייחס לשום כתובת כאל זהות אמיתית, וכתובת נכונה מבחינת תחביר אינה אומרת דבר על מי, אם בכלל, עומד מאחוריה.

למפתחים: אימות, רוחב שדות ורישיות

שלושה הרגלים מונעים את רוב הפגמים בטיפול בכתובות.

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

יש להתאים את האחסון לתקן. יש לתת לחלק המקומי מספיק מקום ל-64 בתים, לדומיין מספיק ל-255, ולשדה השלם מספיק ל-256 כולל פיסוק. כדאי לבדוק את הגבול במכוון עם חלק מקומי ארוך, כי קלט ארוך מדי הוא המקרה שמקוצץ בשקט.

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

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

צעדים הבאים

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