Tag: email

blank Subject:

Subject: line occurrences

The graph above (click it to see the full image) displays the occurrences of Subject: lines within a week, for emails that went through an auxiliary outgoing / filtering mail server, set up specifically to deal with a spam outbreak that affected our customers. They were all about pain-killers and other “enhancements”, making it easy to write quick filters on the spot, with the exception of #66, the blank Subject: line.

[ Update: The above means that for that week the most common non-spam outgoing email subject was the blank subject. Some more numbers: 196493 messages passed through that system. The most common spam subject appeared 3588 times. 679 messages had blank subjects. 5 had “(no subject)” as subject. 6707 messages had subjects that appeared less than 100 times each. 5628 of them I would not classify as spam based on the subject line. So 10.7% of the messages that could not be considered as spam based on their subject’s content had empty subject lines. ]

It seems that people are still sending emails without a Subject: line. Although this seems weird to me, to a lot of others it is perfectly natural. Am I alone in believing that one should not send subject-less emails?

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.

sendmail: Should I use $*, $+ or $- ?

When writing a sendmail.mc rule, you can use some operators on the left hand side, like $- (match exactly one token), $+ (match one or more tokens) and $* (match zero or more tokens). You may find yourself in a situation where for example you want to use a certain delivery agent for some of your users. Normally you would write something like the following:

LOCAL_CONFIG
Kmitsos btree -m -a.mitsos /etc/mail/mitsosusers

LOCAL_RULE_0
:
R$-  < @ $=w . > $*              $: $(mitsos $1 $)  $3
R$- . mitsos  $*     $#mitsos $: $1

The above example seems to be correct, right? But what if you have a user in mitsosusers that contains a dot (.) in the user name (for example yiorgos.adamopoulos)? Because the . is a token separator (see the OperatorChars definition in your sendmail.cf), $- will not match the name. So the correct ruleset in this case is:

R$+  < @ $=w . > $*              $: $(mitsos $1 $)  $3
R$+ . mitsos  $*     $#mitsos $: $1

I got bitten by this sometime ago, and that is why I am sharing it.

Poor man’s milter-ahead

I have blogged before that the reason that I like MIMEDefang is that it gives the Postmaster a Perl interpreter (a programming language that is) and a library of functions that can be used to filter and manipulate incoming and outgoing email.

Of the functions available I believe that md_check_against_smtp_server() deserves special mention since it can be used to quickly implement a poor man’s milter-ahead or milter-sender. Of course milter-ahead implements many features (caching among others), but with some effort most (if not all) of the functionality can be implemented withing mimedefang-filter.

Then again, milter-ahead does not cost much (€90) even for small organizations, so the not invented here syndrome can be supressed.

Μήνυμα του Στέφανου Μάνου

Από το υστερόγραφο του τελευταίου πολιτικού spam:

“Υ.Γ. Ζητώ την κατανόηση σας για τον ανορθόδοξο τρόπο επικοινωνίας. Η κυβέρνηση “φρόντισε” να φιμώσει τη Δράση, απαγορεύει στα νέα κόμματα τη χρήση των ραδιοτηλεοπτικών μέσων. Αν πάντως δεν επιθυμείτε να λαμβάνετε μηνύματα από τη “Δράση”, απαντείστε γράφοντας “διαγράψτε με”.”

Καμία κατανόηση. Δύο λάθη δεν κάνουν ένα σωστό. Αναζητήστε λοιπόν ένα σύμβουλο επικοινωνίας που να ξέρει το αντικείμενο. Η όποια στοιχειώδης συμπάθεια που είχα στον κομματικό σχηματισμό σας εξαφανίστηκε.

Aaaargh!!! no-reply addresses in From: headers

I was asked to create a no-reply@ address for a certain internal application.

Aaaargh! Aaaargh! Aaaargh!!!

Fortunately Word to the wise points to this excellent article which I suggested that the people “upstairs” should read:

“Do Not Reply” Address? Don’t Bother.

As always, if you are lucky enough a consultant is an expert from out of town. Most of the times they are from out of this planet though.