re: Κάθε βοήθεια δεκτή

Το blog Ανακύκλωση_τώρα_ ζητά τη βοήθειά μας:

Αυτό το post είναι μια παράκληση για όσους ενδιαφέρονται να βοηθήσουν σε αυτό το blog, ας αφήσουν εδώ το σχόλιό τους ώστε να τους προσθέσω και να μπορούν να αναρτούν άρθρα.”

Όποιος νομίζει πως έχει να συνεισφέρει περιεχόμενο για αυτή την προσπάθεια, ας επικοινωνήσει με τον συντονιστή της.

My EUR 0.02.

(In-Reply-To:)

milter-dnsbl

Sendmail administrators using FEATURE(dnsbl) may have noticed that ruleset check_rcpt is executed after all connected milters have executed the corresponding xxfi_*() routines.

Wouldn’t it be better if a milter (in fact the first in order) could block a connection based on a list of DNSBLs?

That is why I wrote my first milter, milter-dnsbl (download). milter-dnsbl has no configuration file; on startup it takes a number of arguments that allow you to specify a number of DNSBLs, plus whitelists published via DNS, or based on the domain name of the connecting host. It requires a running lwresd(8) which it uses as a caching server. Read the manpage that comes with the source code distribution.

milter-dnsbl is distributed with an OpenBSD-style license and has been tested on an Ubuntu 6.06 i386 server.

Πονηριές

Με την υπόθεση πως οι mail servers που εμπλέκονται στην διακίνηση ενός email message είναι συγχρονισμένοι με NTP, το πότε στάλθηκε το μήνυμα φαίνεται καθαρά από τα Received: headers.-

Διευκρίνηση: Έτσι με το να αλλάζουμε την ώρα στον υπολογιστή μας ώστε να φαίνεται πως το μήνυμα εστάλη άλλη ώρα από αυτή που το στείλαμε κανονικά (Date: header), δεν καταφέρνουμε τίποτε.

graymilter with DNS based whitelists support – part 3

In part 2 we saw a simple way of whitelisting domain names in Jef Poskanzer’s graymilter. However, this is a solution that does not scale well enough for busy mail systems. Adding or removing a domain from the whitelist means recompiling graymilter which is not the most convenient thing, especially if one needs to do it (over and over) on multiple mail servers.

Wouldn’t it be easier if you could update only one file and have the information distributed to all mail servers? One way of doing this is by using rbldnsd:

“rbldnsd is a small and fast DNS daemon which is especially made to serve DNSBL zones. This daemon was inspired by Dan J. Bernstein’s rbldns program found in the djbdns package.”

Normally people use rbldnsd for publishing blacklists, but this should not stop you. After all you only need to publish a list. Whether it is a blacklist or a whitelist depends on how the program that consults it decides upon the information it gets. I start rbldnsd as follows:

/usr/sbin/rbldnsd -p /var/run/rbldnsd.pid -r/var/lib/rbldns -b1.2.3.4 \\
whitelist.tee.gr:combined:whitelist.tee.gr.txt

And assuming that I want to enlist the domains example.com, example.net and example.org, whitelist.tee.gr.txt looks like this:

; It is declared as a combined zonefile when rbldnsd statrs
$DATASET dnset: @
.example.com
.example.net
.example.org

The next step is to patch graymilter so that it consults a nameserver. While we are at it why not use lwresd?

“[lwresd] provides resolution services to local clients using a combination of a lightweight resolver library and a resolver daemon process running on the local host. These communicate using a simple UDP-based protocol, the “lightweight resolver protocol” that is distinct from and simpler than the full DNS protocol.

To use the lightweight resolver interface, the system must run the resolver daemon lwresd or a local name server configured with a lwres statement.

The lwresd daemon is essentially a caching-only name server that responds to requests using the lightweight resolver protocol rather than the DNS protocol. Because it needs to run on each host, it is designed to require no or minimal configuration. Unless configured otherwise, it uses the name servers listed on nameserver lines in /etc/resolv.conf as forwarders, but is also capable of doing the resolution autonomously if none are specified.”

Now using the lwres(3) interface we can write a query function that consults the domain name whitelist that we serve via rbldnsd:

#ifndef _TEE_CHECKS_C_
#define _TEE_CHECKS_C_ 1
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <lwres/lwres.h>
#include <lwres/netdb.h>
static int
tee_check_domain(char *host, char *whitelist)
{
        char *name;
        int l, herr;
        struct hostent *he;
        l = strlen(host) + strlen(whitelist) + 1;
        name = (char *)malloc(l);
        if (name == NULL) {
                syslog(LOG_INFO, "tee_check_domain(): malloc() error: aborting");
                return(0);
        }
        memset(name, '\0', l);
        sprintf(name, "%s%s", host, whitelist);
        /* syslog(LOG_INFO, "tee_check_domain(): %s", name); */
        he = lwres_getipnodebyname(name, AF_INET, 0, &herr);
        if (he == NULL) {
                free(name);
                if (herr == HOST_NOT_FOUND) {
                        return(1);
                } else {
                        return(0);
                }
        }
        lwres_freehostent(he);
        free(name);
        return(0);
}
#endif /* _TEE_CHECKS_C_ */

and again after line 680 of graymilter.c (assuming graymilter-1.26):

if (tee_check_domain(connhost, ".whitelist.tee.gr") == 0) {
  syslog(LOG_INFO, "accepting host %s from whitelist", connhost);
  return SMFIS_ACCEPT;
}

After you run ./configure you have to add -llwres to the generated Makefile.

So there, now rbldnsd distributes your domain name whitelist and you have local caching at every mail server with the help of lwresd.

(part 2) (final)

War stories

Κάθε system administrator έχει ιστορίες να λέει για χρήστες, “απέναντι” δίκτυα, προμηθευτές, contractors ή/και consultants που τον έβγαλαν από τα ρούχα του.

Έτσι όταν διάβασα το ξέσπασμα του φίλου μου του DBA, κατάλαβα τον εκνευρισμό του.

Εκείνο όμως που δεν περίμενα, ήταν να διαβάσω τον εκνευρισμό ενός γιατρού και να διαπιστώσω πόσο ίδια είναι η συμπεριφορά των χρηστών, ανεξάρτητα από το είδος των υπηρεσιών που ζητούν. Ειδικά τα 5 πρώτα του γιατρού χτυπήσανε νεύρο!

Αλλά και πάλι, system debuggers δεν είναι και οι γιατροί;

ΕΕΤΤ και DNS

Διάβαζα την Έκθεση Πεπραγμένων της ΕΕΤΤ για το 2006 και το μάτι μου έπιασε μια περίεργη φράση:

“[Η ΕΕΤΤ] ρυθμίζει τα θέματα Ονομάτων Δικτυακών Τόπων με κατάληξη [.gr] καθώς και οποιουδήποτε άλλου χώρου ή υποχώρου χορηγηθεί στην Ελλάδα.”

Διαβάζω καλά; Από ότι φαίνεται ναι:

Ν.3431/2006 “Περί Ηλεκτρονικών Επικοινωνιών και άλλες διατάξεις” Άρθρο 12 (Αρμοδιότητες της Ε.Ε.Τ.Τ.):

“κδ) Ρυθμίζει τα θέματα ονομάτων χώρου στο Διαδίκτυο με κατάληξη “.gr”, καθώς και οποιουδήποτε άλλου χώρου ή υποχώρου χορηγηθεί στην Ελλάδα.

Τι ακριβώς σημαίνει η παραπάνω πρόταση; Πως εάν π.χ. χορηγηθεί στο Κράτος Ελλάδα και η κατάλληξη ονομάτων [.hellas] η ΕΕΤΤ θα είναι η ρυθμιστική αρχή; Ή μήπως πως για ονόματα που έχουν εκχωρηθεί και στεγάζονται σε DNS servers που βρίσκονται γεωγραφικά στον Ελληνικό χώρο (και ανεξάρτητα από την κατάληξη) ρυθμιστική αρχή είναι η ΕΕΤΤ;

Μπορεί να προσφύγει κάποιος στην ΕΕΤΤ επειδή θα έχω σε λειτουργία (ότι κι αν σημαίνει αυτό) το όνομα χώρου mitsos.postmaster.gr επειδή θεωρεί πως είναι ο θιγόμενος mitsos; Ακόμα χειρότερα μπορεί να κάνει το ίδιο γιατί έχω σε λειτουργία το όνομα mitsos.dblabs.com;

Τι σημαίνει η παραπάνω πρόταση στο νόμο για τα [.GR.EU.ORG] και [.CY.EU.ORG];

“Εκδίδει Κανονισμό με τον οποίο ρυθμίζεται κάθε θέμα το οποίο αφορά την εκχώρηση των ονομάτων χώρου στο Διαδικτυο με κατάληξη “.gr”, τους όρους χρήσης τους, τους λόγους διαγραφής, τους όρους μεταβίβασης, την τήρηση του μητρώου εκχωρούμενων ονομάτων χώρου τα τέλη για την παροχή των σχετικών υπηρεσιών, την ασκηση εποπτείας για τη χρήση και κάθε άλλο θέμα το οποίο αφορά στη λειτουργία και χρήση των ονομάτων χώρου στο Διαδίκτυο με κατάληξη “.gr” Τα ανωτέρω ονόματα χώρου αποτελούν πόρους του Ελληνικού Κράτους, οι οποίοι εκχωρούνται αποκλειστικά από την Ε.Ε.Τ.Τ., μόνο κατά χρήση. Το μητρώο δεδομένων, που περιέχει κάθε σχετική πληροφορία τηρείται στην Ε.Ε.Τ.Τ.. Η Ε.Ε.Τ.Τ. έχει τη δυνατότητα, με διαγωνισμό, για περιορισμένο χρόνο, ο οποίος σε κάθε περίπτωση, δεν υπερβαίνει την πενταετία, να αναθέτει την τήρηση του Μητρώου σε άλλο πρόσωπο, το οποίο όμως θα ενεργεί στο όνομα και για λογαριασμό της Ε.Ε.Τ.Τ..”

και συνεχίζει με το:

“κε) Η Ε.Ε.Τ.Τ. είναι ο αρμόδιος φορέας για θέματα ονομάτων χώρου στο Διαδίκτυο, με κατάληξη “.eu”.”

Χωρίς παραπάνω ανάπτυξη. Δηλαδή; Εάν κάποιος έχει πρόβλημα με ένα [.eu] domain θα πρέπει να προσφύγει στην ΕΕΤΤ και όχι στο δικαστήριο διαιτησίας (με έδρα την Πράγα) που όρισε το EURid στις 12 Απριλίου του 2005 και σύμφωνα με την Οδηγία 874/2004;


(Και τώρα που ο Dunga σήκωσε το Copa America μπορώ να κλείσω το ραδιόφωνο και να πάω για ύπνο)

Context switching

Δεν υπάρχει κάτι που να καταπονεί τον system administrator περισσότερο από το συνεχές context switching:

“A context switch is the computing process of storing and restoring the state (context) of a CPU such that multiple processes can share a single CPU resource”.

Όπου “multiple processes” οι χρήστες και “single CPU resource” ο system administrator, ο οποίος εκτός από μαντικές ικανότητες πρέπει να έχει τουλάχιστον μία υποψηφιότητα για το βραβείο Turing.

Φορητότητα email


(ή στο περίπου φορητότητα)

Στο δελτίο τύπου της 2007-06-29 της ΕΕΤΤ διαβάζουμε μερικά ενδιαφέροντα πράγματα:

Α) Αυτόματη προώθηση ηλεκτρονικής αλληλογραφίας όταν αλλάζει ο πάροχος

Οι χρήστες ηλεκτρονικού ταχυδρομείου (e mail) που αλλάζουν Πάροχο Υπηρεσιών Διαδικτύου (Internet Service Provider) αποκτούν πλέον τις εξής δυνατότητες:

1. Η ηλεκτρονική αλληλογραφία τους προωθείται αυτομάτως από το παλαιό πάροχο στην νέα τους διεύθυνση για χρονικό διάστημα δύο (2) μηνών.

2. Για διάστημα έξι (6) μηνών αποστέλλεται από το παλαιό πάροχο στον αποστολέα της αλληλογραφίας τους ένα απαντητικό μήνυμα που τον ενημερώνει για την νέα τους ηλεκτρονική διεύθυνση.

Επίσης, ο παλαιός Πάροχος Υπηρεσιών Διαδικτύου δε μπορεί να εκχωρήσει σε άλλο χρήστη διεύθυνση ηλεκτρονικού ταχυδρομείου που έχει καταργηθεί, πριν την πάροδο έξι (6) μηνών από την κατάργησή της. Κατ’ εξαίρεση, η διεύθυνση μπορεί να εκχωρηθεί, πριν την εκπνοή του συγκεκριμένου διαστήματος, μόνο στον χρήστη ο οποίος ήταν ο προηγούμενος κάτοχός της.

Τα παραπάνω αναφέρονται επίσης στην τροποποίηση του Κανονισμού Γενικών Αδειών με την απόφαση 442/68/28-6-2007 (παρ. 3.8α και 3.8β)* της ΕΕΤΤ.

Η απόφαση αν και με σωστό πνεύμα δεν προσδιορίζει μερικά θέματα:

  • Σε ποια γλώσσα θα είναι το ενημερωτικό μήνυμα που θα πληροφορεί για την νέα διεύθυνση του χρήστη;
  • Είναι αρκετό ένα μήνυμα, όπως αυτό παράγεται π.χ. από το FEATURE(`redirect’) του sendmail ή πρέπει να είναι κάτι πιο επεξηγηματικό+;
  • Πως θα διαχειριστεί ο πάροχος μέσα σε αυτό το διάστημα των 6 μηνών επαναλλαμβανόμενες ενημερώσεις του (πρώην) χρήστη του για την ανακατεύθυνση της αλληλογραφίας του; Π.χ. όταν παύει τη σύμβασή του με τον πάροχο ζητάει να του προωθείται η αλληλογραφία στο Yahoo!Mail και μετά από ένα μήνα αλλάζει γνώμη και θέλει να ανακατευθύνεται στο Gmail.
  • Δεν προβλέπει τον χειρισμό των antispam filters, τόσο στον παλιό, όσο και στο νέο πάροχο. Στην περίπτωση που ο παλιός πάροχος έχει κεντρική πολιτική antispam κοινή για όλους τους χρήστες, θα πρέπει να εξαιρέσει αυτόν τον χρήστη; Εάν ναι, ο νέος πάροχος έχει δικαίωμα να κάνει blacklist τα συστήματα του παλαιού επειδή του προωθούν spam;

    Στην περίπτωση που έχουμε personalised antispam filtering, ο παλαιός πάροχος θα πρέπει να διατηρεί τα φίλτρα του πρώην χρήστη του για το διάστημα των 2 μηνών. Σε αυτό το χρονικό διάστημα θα πρέπει να του δίνει και πρόσβαση να ανανεώνει τα φίλτρα ή όχι;

Αυτό που με παραξενεύει είναι πως στο site της ΕΕΤΤ δεν είδα καμία διαδικασία διαβούλευσης για το θέμα της φορητότητας των διευθύνσεων email. Έστειλα και mail στις 2007-07-02 στην ΕΕΤΤ (στο info παπάκι eett.gr) αναζητώντας κάποιον για να μπορέσω να συζητήσω αυτά τα θέματα, αλλά τίποτα ακόμα.


[*] – PDF document
[+] – Π.χ. “A better E-mail bouncer