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

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

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

לפי הטוקבקים, יש הרבה מטומטמים שלא מבינים ממש בניהול מערכות דואר או שלא מבינים כלום במערכות UNIX/LINUX (כמעט אצל כל הספקים מערכות הדואר רצות על מערכות Linux/Unix למעט נענע שמריצים את זה עם Exchange על Windows).

אז בוא נראה: האם הצעת חוק כזו אמורה להיות קשה לביצוע עבור הספקים? האם היא תעלה להם במשהו?

התשובה ל-2 השאלות האלו, מנסיוני, היא לא. אסביר.

אם ניקח מערכת מייל כמו sendmail לדוגמא (אני מודע שאף אחד מהספקים לא משתמש במערכת כזו לדואר אלא במפלצות הרבה יותר גדולות כמו של Mira או של Sun או אחרים), כל מה שצריך בסופו של דבר לעשות הוא שילוב בממשק WEB שמה שיגרום לאחר שהפקידה תבחר העברת מנוי למישהו אחר, שתיווצר שורה כמו השורה הבאה שתיכנס ל-home directory (רק לדוגמא) של אותו משתמש:

echo "my new email" > .forwardrc

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

זו כמובן סתם דוגמא פשוטה ואני בטוח שבמערכות מייל אחרות הדבר הרבה יותר פשוט ואינו מחייב כל כתיבת סקריפט (זה חלק מובנה במערכת), אבל אני מניח שספקי האינטרנט לא ממש יצאו מעורם כדי לתת שרות זה. צפו לכל מיני סיבות מגוחכות לחלוטין שאותם ספקים יעלו. החל בעלות של האחסון (סיבה מטומטמת שלא רלוונטית, תיבה ריקה תמיד תשאל מס' קטן של K ב-File-system או ב-LDAP וכו' אבל היא לא תגדל כתוצאה ממעבר או כתוצאה מ-Forward!), בקושי "לתחזק" את זה (מה יש לתחזק בזה?) ועוד סיבות כאלו ואחרות. אחרי הכל, הספקיות לא רוצות תחרות נמרצת בין הספקיות עצמן, אז הם יעברו לגישה של לעכב הכל (ומי שלא מכיר מה זה עיכוב, שינסה להתנתק מספק האינטרנט שלו, ואחרי חודש ימצא שהם עדיין גובים ממנו כסף "לשימור" שם המשתמש שלו למרות שהלקוח לא רוצה זאת! לצערי אני אומר את זה מנסיון אישי עם אינטרנט זהב).

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

תודה,
חץ

Comments

comments

5 תגובות בנושא “הצעת הרחבת החוק ניוד מספרים של ח"כ גלעד ארדן

  1. אני לא חושב שזו צריכה להיות בעיה לעשות שירות בתשלום כזה (אפילו די נמוך). אבל הטענה שהעניין הזה לא עולה לספקים כלום, אינה מדוייקת. היא קשורה בכל אותם היבטים שלך, כpower user הם חסרי משמעות, אבל לספק אינטרנט הם בעיתיים במיוחד.
    ראשית: זה עולה להם בnamespace. הם לא יכלו להעניק את כתובת הדואר הזו למישהו אחר. נכון, אנחנו היינו מעדיפים למנוע את זה בלי קשר לחוק (כדי למנוע התחזות, באמצעות מנגנון "שחכתי את סיסמתי"). אבל בכל זאת מדובר בעלות מסויימת לספק.
    דבר שני: עולה להם בפיתוח. בsendmail מדובר בשורה בbash, וככה גם בqmail ובpostfix. אבל לבנות מנגנון אוטומטי, שמיד לאחר סגירת חשבון במערכת ניהול החשבונות, פותח alias לאותו משתמש, ומוחק את תיבת המייל שלו, ומצד שני, אם אותו משתמש חזר לספק, מוחק את הalias, ופותח תיבה חדשה, ובאותה הזדמנות מטפל גם במקרה שמישהו רוצה להחליף את הalias שלו (היה בנטוויז'ן, עבר לבזק בין לאומי, ואז עבר ל012). זה לא בשמיים, אבל זה זמן פיתוח. אתה רואה את זה מנקודת המבט של power user, שמסוגל לסבול תקלות פה ושם. לא כספק אינטרנט, שמבחינתו הסיפור זה אופרציה לא קטנה.
    ומה לגבי תמיכה? אתה צריך להעסיק אנשים שיכניסו את הalias המתאים. אני בכלל לא דן בפיצוי למי שנרשם לו alias לא נכון, שגם זה משהו שצריך לקחת בחשבון, ורחוק מלהיות שולי.
    ואחרון, ואני לא בטוח בכלל שזניח, זה רוחב פס. נניח ושלחתי מייל מהוטמייל, ללקוח בנטוויז'ן, עם alias ל012. נטוויז'ן שילמו על רוחב הפס לחו"ל (כדי לקבל מייל מהוטמייל), ושילמו על רוחב הפס לארץ (ל012). 012 שילמו רק על רוחב הפס לארץ (מנטוויז'ן).
    אז מה נחסך לספק האינטרנט בפועל? מקום איחסון בלבד. מקום אחסון כיום הוא עלות זניחה.

  2. כמה דברים:
    1. ממתי עלות namespace משנה משהו? אם יש לי תיבה של hello ומישהו רוצה גם לפתוח תיבה של hello, איפה העלות לספק לפתוח לאותו מישהו hello1?
    2. מתוך נסיון של הקמה ותחזוקה של שרתי Mirapoint ו-Sun JSMS אני יכול לאמר לך שהפונקציות האלו הן כבר Built in. כן, צריך לבנות תוספת לממשק WEB לתומכים/משווקים שמשתמשים במערכת וובית פנימית, אבל זו תוספת חד פעמית למערכת שכבר קיימת לתמיכה/שיווק. מדובר אולי בעבודה של חצי יום של תכנת פנימי בחברה או בחברה שכבר מתחזקת את המערכת, כלומר העלות החד פעמית היא גם – שולית מאוד.
    3. גם לגבי ה-Alias, בזמן ההתנתקות הפקידה יכולה לשאול את הלקוח לאן הוא רוצה שיגיע לו המייל ולהזין זאת באותו ממשק שציינתי בנקודה 2.
    4. לגבי העלות של רוחב פס, רוחב הפס שנצרך ע"י שרתי ה-MAIL הן בקבלה והן בשליחה זניח בהשוואה למה שתוכנות כמו ביטורנט צורכות, במיוחד שבין כה התיבות כיום אצל הספקים לא מוכנים לקבל מייל שעולה על גודל של 10 או 20 מגה.

    תודה,
    חץ

  3. 1. namespace אינו עולה כסף, הוא עולה ערך. אם אני חשבתי שמגניב שהכתובת של תהיה [email protected], פירושו של דבר שמישהו אחר, שרוצה כתובת בנטוויז'ן, יאלץ להסתפק [email protected] כמה אנשים יוותרו על ספק בשביל זה?  כנראה אותה כמות אנשים שעדיין משתמשים באופן סדיר בשירותי הספק לקבלת דואר אלקטרוני בעידן הג'ימייל, כלומר מועטה, אבל מספיקה. וזה כבר עולה כסף.
    2. הפונקציות שאני מדבר עליהן, הן אכן built in, כאשר אתה מדבר על מערכת המנותקת מהיבטים אחרים של תפעול ספק אינטרנט. אבל אצל ספק אינטרנט, המייל קשור בגבייה, בניהול שירות הלקוחות, וכו'. זה אומר שנדרשת בניה של פונקציה שתופעל יחד עם מערכת הניתוק. לא טריוויאלי בכלל.
    הטענה שמדובר בתוספת חד פעמית, מפתיעה אותי ממישהו שעוסק בתחום התוכנה. מחר אני משנה את מבנה מערכת שירות הלקוחות שלי, זו לא עבודה חדשה להתאים את הפיצ'ר של יצירת aliases? מחר מתגלה באג במערכת, זה לא מייצר עבודה חדשה? מחרתיים אני מחליף שרת דואר, זה לא מייצר אקסטרה עבודה? אני לא חושב שמדובר בתוכנה מסובכת מדי, אבל לכל תוכנה, פשוטה ככל שתהיה, יש אבולוציה. בסופו של דבר, ספק אינטרנט בנוי על דברים שרצים אוטומטית, והמחלקה הטכנית שלהם בנויה על דברים אוטומטיים שמשתבשים.
    3. אפשרי לפתור את הבעיה כמו שאתה מתאר, חוץ מאותם מקרים בהם יש בעיות. הלקוח שמספר כתובת לא מדוייקת, ומתעקש שהפקידה רשמה אותה לא נכון. הלקוח שלא מתחבר כרגע לספק האינטרנט החדש, אבל ייתקשר בעוד חודשיים כדי לרשום כתובת חדשה. הלקוח שמסר כתובת, ואז שמע על קיומו של ג'ימייל, ורוצה להחליף. נניח ומדובר ב10% מהאנשים שיחליפו ספק, ורק 10% מתוכם, גם יהפכו את הסיפור למסורבל הרבה יותר ממה שצריך. זה עדיין משהו שצריך לקחת בחשבון.
    4. נכון, מדובר ברוחב פס זניח יחסית. אבל אני עדיין משלם עליו.
    אגב, אני הייתי נחמד יחסית, וסיפרתי לך על בחור שעשה alias מנטוויז'ן ל012. מה עם הבחור שיבקש alias לgmail, ומעכשיו כתובת הnetvision תשמש אותו להעברת מצגות מטופשות במשקל כבד מארה"ב, לארץ וחזרה, כל זה ללא תמורה למי שסיפק לו את השירות. נכון, בהשוואה לשאר זללני רוחב הפס מדובר באחוז קטן. אבל לא הכל יחסי. גם זה עולה כסף ממשי, בסופו של דבר.

  4. יאיא, בוא בוא נעשה סיבוב שני.. הולך? (הוספתי גם bullets ו-numlist, ככה בשביל הכיף לעורך).

    1. הערך הזה הוא בהתחלה. כשאתה נרשם לספק אינטרנט. אם לקוח חדש ירצה את המייל [email protected] (חשבון שהוא לא שלי, אני מצאתי שהוא תפוס) אז הלקוח יצטרך לבחור שם חדש בעת הרישום. במעבר המייל שלו נשאר אותו דבר. אז בגלל שתפוס ה-user במייל בנאדם לא ירשם לאותו ספק? אז הוא יבחר כינוי אחר, כמו שבדיוק כיום אם תבחר hetz הנציג יאמר לך "זה תפוס, תבחר אחר".
    2. כן, אני יודע מה זה אבולוציה, אבל התהליך הזה הוא בדיוק כמו שמחר תעבור לי מ-SUN JSMS למערכות של Baracuda. תצטרך לשנות מערכות שמתממשקות אליו? בהחלט, אבל ככה זה סיסטם, כל הזמן דברים משתנים, מתווספים, עפים, ככה זה החיים עם המערכות האלו.
    3. אוקיי, אז אפשר לפתור את זה ברמה שהספק החדש מעביר לספק הישן אימייל אוטומטי עם כתובת המייל הישנה של הלקוח שעל זה יעשו forward, ועל האימייל האוטומטי הזה אפשר לעשות parsing. אפשר כמובן לחייב לקוח בתשלום אם ירצה לשנות את ה-forward שלו למשהו אחר, לאחר הפעם הראשונה ואני בטוח שהראש היהודי יכול להמציא פטנטים על כך.
    4. מי זה "אני משלם עליו"? אתה בתור ספק אינטרנט? אז פתח בבקשה מסמכים לשכירת קווים ותראה בבקשה על מה הכמויות מידע שמדברים בעניין התשלום ועל כמות נתונים מועברת פר תשלום. סתם בשביל השוואה: היום ב-Bluehost.com אני יכול להעביר 15 טרה-בייט בחודש תמורת פחות  מ-7 דולר לחודש, ופה מדובר עליי, משתמש פשוט, לא ספק אינטרנט שחותם על הסכמי תעבורה של פטה-בייטים.
      גם אם ניקח את הטענה שלך כנכונה, אני בטוח שאפשר יהיה לקבוע איזה "דמי פרישה" של כמה דולרים חד פעמית שאותם הספק שמקבל את הלקוח יספוג או שהלקוח ישלם.
  5. גם אם נתעלם מכל מה שכתבתי וניקח מראש את זה שאתה צודק בנקודות שהעלית, יש נקודה אחרת שלא התייחסתי אליה: Economics of scale. הרי אם ספקי האינטרנט יסכימו לדברים, אז החישוב יהיה אחר ויותר כדאי.
    לדוגמא (אני סתם זורק מספרים): 012 תקבל 1000 לקוחות שיעברו מנטויז'ן ומבזק בינלאומי, ונטויז'ן תקבל 2000 לקוחות שיעברו אליה מבזק בינלאומי ומ-012, ובזק בינלאומי תקבל 3000 לקוחות שיעברו משאר הספקים אליהם.
    במספרים כאלו, כל החישובים משתנים והעדיפויות משתנים בהתאם. לקוח משלם בממוצע בסביבות 60 ש"ח לחודש לספק האינטרנט שלו (אני לא נכנס לתשלום התשתיות), כפול 12 חודשים יוצא 720 ש"ח לשנה מלקוח אחד. נכפיל ב-1000 לקוחות ויש לנו 720,000 ש"ח לשנה אחת, ועוד לא כללתי שרותים נוספים שספקיות האינטרנט דוחפות (אנטי וירוס, אנטי-ספאם וכו') כלומר אפשר לאמר שמ"מבצע" כזה של כמות לקוחות גדולה שעוברת מספק לספק, הספק שיקבל יעשה הכל כדי לקבל את אותם לקוחות, כולל סבסוד "דמי פרישה" למיניהם אם ספק אחר יעלה.
    לדעתי, ספקים לא יעשו דרישה כזו הואיל ואז יש מעין "סבסוד צולב", כלומר נטויז'ן תצטרך לשלם לבזק  בינ"ל על התעבורת מייל של הלקוח שעבר שהיה בעבר בבזק בינ"ל עם לקוח אחד, ועם לקוח שני בזק בינ"ל תצטרך לשלם לנטיוז'ן ללקוח שעבר לבזק בינ"ל. הרבה יותר יהיה קל לחברות פשוט לרדת מעניין הגביה הזו ולהתחשבן בצורות אחרות (סיבים בין החברות).

סגור לתגובות.