* Όπως λέει και ο τίτλος, το κείμενο γράφτηκε τον Ιανουάριο του 1998 και περιγράφει ένα BoF στο οποίο συζητήθηκε για πρώτη φορά σε joint TERENA – RIPE meeting η ανάγκη οργάνωσης των μελών τους για την αντιμετώπιση του spam.
TERENA Anti Spam BoF 1998/01/28 minutes.
Το antispam meeting έγινε στο Park Plazza Hotel στις 28/1. Το παρακολούθησαν περίπου 200 άτομα. Από πλευράς GRNET ήταν παρόντες ο Γιώργος Αδαμόπουλος και ο Παναγιώτης Χριστιάς. Η συνάντηση διήρκησε περίπου 2:30 ώρες.
Τη συζήτηση ξεκίνησε ο John Martin (JM) από το _TERENA_ staff. o JM πρότεινε να επικεντρωθεί η συζήτηση στο email spam (Unsolicited Commercial Email, Bulk Email), καθώς το _USENET_ spam είναι ένα ξεχωριστό κεφάλαιο από μόνο του. Σκοπός του για την οργάνωση αυτού του meeting ήταν η κατανόηση του φαινομένου από όλους και η διερεύνηση του τι μπορεί να γίνει στα πλαίσια του RIPE.
[ Το φαινόμενο ήταν πλήρως κατανοητό στο ακροατήριο γιατί περίπου το 70%των παρευρισκομένων ήταν Postmasters και άρα καλοί γνώστες του προβλήματος. ]
Οι τρεις στόχοι που καθορίστηκαν, ήταν:
- maximum effect / least pain
- measures
- deployment
Το πρώτο πράγμα που προτάθηκε ήταν η δυνατότητα authentication στο SMTP επίπεδο. Ειπώθηκε από παρευρισκόμενο ότι ήδη στα πλαίσια του IETF υπάρχει προσπάθεια για την επίλυση αυτού του ζητούμενου στα πλαίσια κάποιου RFC. [ Ήδη έχει εκδοθεί και κάποιο σχετικό IETF draft ].
Mία πρόταση που έγινε ήταν να επεκταθεί το RIPE-DB ώστε να περιλαμβάνει τα modem-pools των διαφόρων providers και να αποφεύγονται οι απ’ευθείας συνδέσεις από και προς τις διευθύνσεις τους. Αυτή η πρόταση απορρίφθηκε ως σχεδόν αδύνατη να εφαρμοστεί στην πράξη.
Το επόμενο που συζητήθηκε ήταν η χρήση του MAPS/RBL project. Τα σχετκά links είναι στο . [ Σημ.: Το sendmail.8.9.0.Beta3 ήδη προβλέπει το FEATURE(`rbl’) για αυτό το σκοπό ]. Παρ’όλο που οι περισσότεροι συμφώνησαν πως η πληροφορία του RBL είναι χρήσιμη, οι περισσότεροι δήλωσαν πως δεν το χρησιμοποιούν για να αρνούται SMTP connections.
Παρ’όλο που ειπώθηκε πως οι Ευρωπαίοι γενικά δεν είναι spammers, υπήρξαν διάφοροι που σημείωσαν πως στις Ευρωπαϊκές χώρες το spamming περιορίζεται εντός των συνόρων. [ Σε αυτό το σημείο ο συγγραφέας του draft για το SMTP authentication είπε: “If the US spammers are the problem, I say cut the wire!” ;-) ].
Από παρευρισκόμενο προτάθηκε να ακολουθολυνται οι εξής απλές διαδικασίες για να αποφεύγεται το φαινόμενο:
- Stop unauthorised relaying
- IP SMTP filtering
- DNS lookups
Το πρόβλημα που σημειώθηκε σε σχέση με τα παραπάνω είναι ο κίνδυνος το DNS lookup cache να μεγαλώσει τόσο πολύ ώστε να είναι επικίνδυνο για τη σταθερότητα του συστήματος. Ο ομηλιτής είπε: “Sure, you all say do *always* DNS lookups. But no one speaks of the cost when the DNS cache reaches up to more than 20Mbytes”.
Μια πρόταση για να δημιουργηθεί ένα προτόκολο για SPAM-MTAs απορρίφθηκε μετά βαϊων και κλάδων, κυρίως γιατί κανείς spammer δεν θα χρησιμοποιεί ένα τέτοιο MTA.
Ο JM στη συνέχεια θέλησε να κάνει ένα profile “του καλού spammer”: Υπέθεσε με ασφάλεια ότι οι spammers είναι μάλλον αρκετά έξυπνα άτομα με τεχνική κατάρτιση και γνώση του αντικειμένου. Πολλοί όμως από το ακροατήριο παρατήρησαν πως σε αρκετές από τις περιπτώσεις spamming που κυνήγησαν, διαπίστωσαν πως είχαν να κάνουν με ανθρώπους που έστελναν τα μηνύματά τους μέσω point-and-click GUIs και που δεν είχαν καμία γνώση για το πιθανό προβλημα που μπορεί να προκαλούσαν.
Από το παραπάνω κατέληξαν όλοι πως τελικά οι ISPs οφείλουν να έχουν ένα τέτοιο AUP (Acceptable Usage Policy) ώστε να προβλέπουν κυρώσεις για τέτοια συμβάντα. Σε αυτό το σημείο έγινε και η παρατήρηση πως το cost-model στο Internet είναι τέτοιο ώστε ο spammer να μπορεί να κάνει πολύ εύκολα τη δουλεία του. Το κόστος να στείλει κανείς 10000 spam mails από το Internet είναι το ίδιο με το να στείλει ένα. Σε αυτό το σημείο υπάρχει μια σημαντική διαφορά κόστους ανάμεσα στο snailmail (Ταχυδρομείο) και το Email.
Σε αυτό το σημείο σχολιάστηκαν οι διάφορες τεχνικές για την αντιμετώπιση των spams. Οι περισσότεροι Postmasters αρνούνται emails με βάση anti-relaying rulesets και κάποια γνωστά originating sites. Όλοι συμφώνησαν πως το content-based filtering είναι πολύ επικύνδινο και πρέπει να αποφεύγεται, εκτός εάν γίνεται από τον τελικό χρήστη. Εδώ ένας ομιλητής είπε οτι κρατάνε ένα MD5-hash για κάθε mail που γίνεται relay από τα μηχανήματά τους, ώστε αν ξανασταλεί ενώ έχει διαπιστωθεί πως είναι spam, να κόβεται από το server. Κι εδώ όμως αρκετοί θεώρησαν πως η προτεινόμενη λύση διεισδύει στα δικαιώματα του χρήστη, καθώς πάλι το φιλτράρισμα γίνεται με βάση το περιεχόμενο.
Εδώ πολλοί μίλησαν για την αδυναμία των άλλων MTAs (90% των παρευρισκομένων χρησιμοποιούσε sendmail) να αμυνθούν επαρκώς στο spam. Επίσης πολλοί μίλησαν για την ανικανότητα και την αδιαφορία πολλών ISPs να αντιδράσουν στο φαινόμενο, όπως και την αδιαφορία τους αν περιληφθούν σε λίστες όπως αυτές του RBL και του MAPS project. Οι ΜΤΑ της Μ$ και της Ν$ ήταν αυτοί που δέχτηκαν τη μεγαλύτερη κριτική.
Προτάθηκε να δημιουργηθεί στα πλαίσια του RIPE (ή ακόμα και ως ξεχωριστό EC project) ένα spam report abuse center. Πολλοί συμφώνησαν με την ιδέα, αλλά ο εκπρόσωπος της AOL στη συνάντηση παρατήρησε ότι μια τέτοια λύση δεν θα μπορούσε να δουλέψει και έδωσε ένα παράδειγμα: “I would forward at least 60Mbytes of spam to this center every day- it simply does not scale..”
Τελικά αυτό που αποφασίστηκε ήταν να δημιουργηθεί ένα Working Group που θα γράψει ένα Best Current Practice για τους ISPs για τη διαχείριση και αντιμετώπιση toy email spam. Αν αυτό το WG προχωρήσει σωστά, τότε το επόμενο βήμα θα είναι η δημιουργία ενός Abuse NCC (όχι ενός spam-handling center) που θα δουλεύει όπως τα διάφορα CERT/CCs, αλλά για Abuse (κυρίως spamming γεγονότα). Όλοι τέλος συμφώνησαν ότι πρέπει το RIPE να ηγηθεί της προσπάθειας να υπάρχουν contact-addresses για αυτό το φαινόμενο σε όλα τουλαχιστον τα Ευρωπαϊκά δίκτυα.
[ Για το ISP BCP, δημιουργήθηκε μια ομάδα εθελοντών- κι εγώ μέσα σε αυτή- η οποία θα ενεργοποιηθεί μετά τη δημοσιευση των “επισήμων” πρακτικών του meeting- τα οποία δεν είναι έτοιμα ακόμα ].
—
Yiorgos Adamopoulos, NTUA-NOC
Y.Adamopoulos@noc.ntua.gr
Managing organized complexity 