“my new favorite ping destination”

Χρόνια πριν, όταν δούλευα στο NTUA-NOC (πριν καν ακόμα υπάρξει ΕΔΕΤ, όταν τα Πανεπιστήμια είχαν το καθένα τον δικό τους upstream ISP), μια συνήθεια (την οποία οφείλω στον Πάνο) που είχα αποκτήσει και που απαντούσε πάνω / κάτω στο ερώτημα “δουλεύει το δίκτυο;” ήταν να κάνω traceroute προς ένα host στο MIT:

$ traceroute 18.0.0.1

Όταν δεν “έφτανε” το traceroute έξω από το MIT, κάποιο πρόβλημα υπήρχε με τον upstream provider (BT τότε). Τα θυμήθηκα αυτά επειδή χτες άκουγα το επεισόδιο #12 του Ask Mr. DNS podcast και το θυμήθηκα όταν ο Matt Larson είπε στον Cricket Liu, αναφερόμενος στις διευθύνσεις του Google Public DNS:

This is going to be my new favorite ping destination

Αναφερόταν στις διευθύνσεις 8.8.8.8 και 8.8.4.4. Άλλες ευκολομνημόνευτες διευθύνσεις που ανέφεραν ήταν οι 4.2.2.1 και 4.2.2.2.

Να δω όταν αρχίσει και αναπτύσσεται το IPv6 ποιος θα σκαρφιστεί την αντίστοιχη πιο εύκολη διεύθυνση.

on security policies

While reading “Rule Based Analysis of Computer Security” I stumbled upon the following phrase:

All the desired operations should be allowed, and all the undesired operations should be disallowed

Many times we focus so much on the latter part (disallowed) that we force users to circumvent obstacles in order to share or access information and work in ways that they end up granting more access than what is actually required. Then trouble, friction among admins and users and exceptions emerge.

The purpose of SMTP-HELO

Years ago D. J. Bernstein wrote “I recommend that server implementors let clients skip HELO, to support a future transition to a world without HELO”. I suppose that anyone who has spend enough time “speaking” SMTP as part of debugging mail systems must have wondered about the need for HELO to even exist in SMTP.

Well it was not always there. RFCs 722 (Sep 1980) and 780 (May 1981) do not include it. It first appears in RFC 788 (Nov 1981). But why?

Back in 2005 in comp.mail.imap Mark Crispin explained why:

The purpose of HELO (and the Received: header line) was to fix a problem that went away with the NCP->TCP transition.

He goes on to explain that in the NCP days the IMPs that relayed messages knew only of the destinations of them and how that could lead to loops delivering the messages to the sender’s machine instead of the recipient’s. HELO solved the loop probelm. The transition from NCP to TCP/IP took place in 1/1/1983 in what is known as the Internet Flag Day. That should have effectively ended the life of HELO. But no, “people felt strongly about making this never happen again” and with the introduction of SMTP:

the SMTP client identified itself (HELO), and you were allowed to barf if the HELO claimed to be yourself since that meant that the network was in loopback.

HELO not only survived, but also a trend emerged as it started to be used as a weak authentication mechanism. People started checking whether the IP addrees of the connecting machine and the argument supplied with HELO had matching A and PTR RRs. This lead to the RFC 1123 prohibition:

However, the receiver MUST NOT refuse to accept a message, even if the sender’s HELO command fails verification.

This prohibition stands even with the current SMTP specification (RFC 5321):

Information captured in the verification attempt is for logging and tracing purposes. Note that this prohibition applies to the matching of the parameter to its IP address only

This is not to be interpreted as that no connection can be rejected based on the argument supplied with HELO. This thread over at RFC Ignorant discusses such valid cases where rejection is possible.

So there, now you not only know the history of HELO and why it was invented, you also know that it is not needed since 1983.

→ SMTP servers should not require, or ascribe meaning to, HELO or EHLO.

PTR και multiple A RRs

Ο Βαγγέλης έκανε στο twitter δύο ενδιαφέρουσες ερωτήσεις:

@hakmem ερώτηση: δεν είναι καφρίλα να ζήτας από SMTP να έχει και Valid RDNS;

και αφού του απάντησα πως δεν είναι:

@hakmem έστω ένα VPS με 1 IP που τρέχει SMTP για 5-6 virtual domains, αν βάλεις reverse dns based block το χάσαμε το κορμί πατριώτη

Για να γίνει κατανοητό το γιατί, θα χρησιμοποιήσω το test case που δίνει ο Βαγγέλης. Έστω VPS με IP address 10.2.3.4 και όνομα server-vps.example.com. Έστω επίσης και 5 virtual domains που τρέχουν πάνω σε αυτόν, τα example-1.com έως και example-5.com. Κατά πως συνηθίζεται ο mail server για κάθε ένα από αυτά ονομάζεται mail.example-1.com, mail.example-2.com κ.ο.κ. Και οι πέντε mail server έχουν την ίδια ακριβώς IP address, την 10.2.3.4.

Όταν κάποιος θέλει να στείλει ένα email στον user@example2.com συμβουλεύεται το DNS για τα MX RR. Τα MX RR είναι η απάντηση στην ερώτηση “ποιος ξέρει να παραδώσει την αλληλογραφία προς χρήστες στο example2.com;”. Στο παράδειγμα η απάντηση είναι ο mail.example2.com. Στη συνέχεια συμβουλεύεται το DNS για τα A RR. Τα A RR είναι η απάντηση στην ερώτηση “ποια είναι η διεύθυνση του mail.example2.com;”. Θα λάβει την απάντηση 10.2.3.4 και στη συνέχεια θα κάνει τα προβλεπόμενα από το πρωτόκολλο SMTP ώστε να συνδεθεί και να παραδώσει την αλληλογραφία. Σημειώστε πως και τα δύο ερωτήματα που έγιναν στο DNS είναι παραδείγματα forward lookup.

Όταν σε κάποιον server συνδέεται κάποιος ώστε να χρησιμοποιήσει μια υπηρεσία που προσφέρει, το μόνο που ξέρει ο server είναι η διεύθυνση που χρησιμοποιεί ο αιτών. Τον “παλιό καλό καιρό” που το spam δεν ήταν πρόβλημα, ένας mail server θα δεχόταν οποιδήποτε μήνυμα από οποιονδήποτε και θα έκανε ότι μπορούσε για να παραδοθεί στον προορισμό του. Επειδή οι καιροί έχουν αλλάξει κανείς δεν είναι τόσο ανεκτικός και αρκετοί mail servers στα πλαίσια πολιτικών που εφαρμόζουν θέλουν να γνωρίζουν το όνομα αυτού που συνδέεται πάνω τους. Για να το κάνουν αυτό ρωτούν για το PTR RR που σχετίζεται με την συνδεόμενη IP address. Εάν το reverse delegation δεν είναι ορισμένο σωστά ή εάν δεν συμφωνούν το A RR για το όνομα με το PTR RR που δίνει το DNS για τη διεύθυνση, τότε είναι πιθανό η επικοινωνία να μη γίνει αποδεκτή και το email να μην παραδοθεί.

Παρόλο που κανείς μπορεί να οδηγηθεί στο συμπέρασμα πως πρέπει να υπάρχει ένα PTR για κάθε όνομα που κάνει χρήση της 10.2.3.4, αυτό που είναι απαραίτητο είναι ένα από όλα (οποιοδήποτε) να συμφωνεί με το PTR RR. Το ενδεικνυόμενο στη συγκεκριμένη περίπτωση, για διαχειριστικούς λόγους επειδή έχουμε να κάνουμε με virtual domains, είναι το PTR να δείχνει στο “πραγματικό” όνομα του server, δηλαδή στο vps.example.com. Ή όπως πιο απλά το έθεσε ο Γιώργος Κεραμιδάς:

@vtripolitakis Το σημαντικό σε αυτό που είπε ο @hakmem είναι ότι η αντιστοιχία name ↔ address είναι M ↔ 1. Απλά τυχαίνει συχνά M=1

Γυρνώντας πίσω στην απάντηση που έδωσα στην πρώτη ερώτηση του Βαγγέλη:

@vtripolitakis Όχι. Καφρίλα είναι να κόβεις με βάση το HELO/EHLO

Δεν είναι πρόβλημα να μην αποδέχεται κανείς τη σύνδεση επειδή δεν υπάρχει PTR record. Πρόβλημα είναι η μη αποδοχή σύνδεσης για προβληματικό HELO. Και αυτό γιατί τα RFC 1123, 2821 και 5321 το απαγορεύουν. Το RFC5321 γράφει:

However, if the verification fails, the server MUST NOT refuse to accept a message on that basis. Information captured in the verification attempt is for logging and tracing purposes.

Αλλά για την ιστορία του SMTP-HELO θα ακολουθήσει επόμενο post.