HSubject: and rulesets

This is a variation of the bat book‘s subject header checking trick. Assuming that you want to block messages based on the content of the Subject: header of an incoming message, you can place the following rules into your .mc file:

LOCAL_CONFIG
HSubject: $>BlockSubject

The above basically instructs sendmail to call ruleset BlockSubject with the value of the subject. On with the ruleset now:

LOCAL_RULESETS
SBlockSubject
# The next rule is broken in two for readability!
R$* test - block this message $*
        $#error $: "553 message blocked due to Subject: " $&{currHeader}
R$* Your new password $*        $#discard $: discard
R$* Casinoo $*        $#discard $: discard
R$*        $#OK

(You may want to change the $> operator with $>+. Read paragraph 25.5.1 of the fourth edition of the bat book for a discussion on the matter.)

The bat book prefers to put all the unacceptable subjects in an external database file (which is maintained much like aliases and virtusertable). I prefer keeping the list of the unacceptable subjects inside the .mc file for two reasons:

First, keeping them in a file outside the .mc makes the list grow faster. Editing the .mc to add yet another unacceptable subject makes one think whether to do so or not.

Second, although a subject that contains a certain phrase may be considered unacceptable, you might want to make an exception. For example one may decide to block all the Your new password messages except ISP name – Your new password message that your MIS sends to your users when they reset their password. This can easily be maintained in one place in the .mc file and is also self documented modem noise code:

R$* ISP - Your new password $*        $#OK
R$* Your new password $*        $#discard $: discard

Remember, do not copy-paste sendmail.mc code. The LHS and the RHS are tab separated. Copy-pasting converts tabs to spaces and your ruleset will not work.

inbox bankruptcy

My good friend Panagiotis Astithas wrote to me recently:

“Nowadays my INBOX is not what it used to be. I have incoming messages / news from GMail, EBS mail, NETMODE mail, NOC mail, Twitter, Friendfeed, Facebook, Google Reader (and I am surely forgetting some) and I have made sure to minimize both duplication and polling effort (using .forward, gmail notifier and firestatus :-) ).”

With so many sources comprising our INBOX (and not just email) we should replace the term email bankruptcy with inbox bankruptcy.

Vista: Windows Mail and error 0x800CCC0B

I resolved this the other day together with a user: In Vista when Windows Mail fails to connect to the remote SMTP (outgoing) email server returning error code 0x800CCC0B, the reason is that the remote server requires you to have both SSL and SPA enabled:

  • Account Properties → Servers → Log on using Secure Password Authentication
  • Account Properties → Advanced → Incoming Mail / This server requires a secure connection (SSL)

TipJoy as email postage?

I have been thinking about this ever since TipJoy was announced. However, daily life stuff got on the way and the idea did not develop for quite sometime.

Although not the first to do so, reader of this blog Stazybo Horn suggested charging per email as a possible solution to spam some time ago. Systems that do this have appeared, like for example Goodmail Systems. The general idea and I copy-paste from Wikipedia is:

Certified e-mail is an e-mail whitelisting technique by which an internet service provider allows someone to bypass spam filters when sending e-mail messages to its subscribers, in return for paying a fee to the certifying service.

Today Stazybo Horn blogs about a securityfocus.com interview of Wietse Venema, where he says: “The best theoretic solution is to change the email distribution model”. Venema (author of Postfix by the way) then goes on and proposes a “pull” model where a MUA downloads email sent to the user given that certain circumstances apply.

In the same spirit, and because I believe that legitimate email marketeers are willing to pay a minimum fee per message (there are people who use Goodmail’s solution, right?) I also thought of changing the distribution model:

  • Pay the end user to read your spam message!

Even better than pay, TipJoy them so they can buy books.

Spammers thrive because it costs them next to nothing to send their messages and have some of them accepted. This has resulted in implementing a series of filters that do have false positives, where legitimate senders take the hit along with the black sheep. So why not pay a minimum fee to the end user? That would help develop whitelists that would deliver the message to the end user’s INBOX.

Unfortunately the current TipJoy API is not ready to support such an idea, but I am told that a next version might be more suitable for such things.

Update: It seems that TipJoy is shutting down :(

Toward an Ethics and Etiquette for Electronic Mail

Στα όρια της ιντερνετικής Αρχαιολογίας: Στα 1985 η RAND δημοσίευσε το report με τίτλο “Toward an Ethics and Etiquette for Electronic Mail“. Είναι εντυπωσιακά φρέσκο κείμενο 28 σελίδων, δεδομένου του πότε γράφτηκε, καθώς οι συγγραφείς αν και ήταν ήδη 15 χρόνια χρήστες του ηλεκτρονικού ταχυδρομείου, το θεωρούσαν ως νέο μέσο επικοινωνίας. Και ακόμα περισσότερο, βλέπει κανείς πως μερικά προβλήματα μπορεί να έχουν πολύ παλιότερες ρίζες από όσο μπορεί να σκεφτεί, π.χ.

“Until you’ve received too much electronic junk mail, or been offended by a message, or have inadvertently offended someone else (and wondered why), you will miss part of our message.”

Πόσες φορές δεν έχω ακούσει κόσμο να απορεί γιατί “γκρινιάζω” που μου στέλνουν το αστειάκι της ημέρας (για 10η φορά) και “γιατί δεν πατάς ένα delete μωρέ;” ή που δίνουν το email μου σε οποιοδήποτε send-a-friend link. Φτάστε και εσείς στα 500+ (χρήσιμα) emails την ημέρα και τα ξαναλέμε. Είναι κατανοητό πως είναι ίσως και χαριτωμένο να δέχεστε και 2-3 junk mails την ημέρα όταν το mail σας είναι άδειο (και να απορείτε “μα που με βρήκαν;” – hint: δεν σας βρήκαν) αλλά δεν είναι όλοι έτσι.

Και για όποιον αναρωτιέται, το πρώτο internet spam mail εμφανίστηκε το 1978.

Και μια και η κουβέντα το έφερε στις χαριτωμενιές, όταν οι χρήστες γράφουν ένα email δεν σκέφτονται που μπορεί να καταλλήξει, πόσα forward θα γίνει παραπέρα, σε πόσους άλλους θα πάει χωρίς τη γνώση του αρχικού αποστολέα και πως ίσως θα αλλάξει από κάποιον από τους ενδιάμεσους παραλήπτες ή εάν ακόμα θα τυπωθεί. Έτσι οι συγγραφείς δίνουν ήδη από το 1985 τη χρυσή συμβουλή:

“Never say anything in an electronic message that you wouldn’t want appearing, and attributed to you, in tomorrow morning’s front-page headline in the New York Times.”

Άπειρες παρεξηγήσεις και flame-wars έχουν ξεκινήσει από emails που διαβάστηκαν στραβά, στα πεταχτά. Το email είναι γραπτή μεν επικοινωνία, αλλά κουβαλάει χαρακτηριστικά του προφορικού λόγου χωρίς ταυτόχρονα να συνοδεύεται από τον ήχο, το χρώμα της φωνής ή ακόμα και χειρονομίες και κινήσεις του σώματος σε περίπτωση face-to-face επικοινωνίας. Πολύ νόημα δεν μεταφέρεται είτε επειδή ο αποστολέας το θεωρεί αυτονόητο, είτε επειδή ο παραλήπτης δεν έχει καν την ίδια κουλτούρα για να το συλλάβει, ή απλά έχει ξυπνήσει στραβά. Και ταυτόχρονα είναι κατά κανόνα ανεπίσημη επικοινωνία, οπότε:

“It might help to consider the message as a written verbal communication, rather than real writing.”

Ωραίο κείμενο. Με λίγο τρίψιμο στις γωνίες, γίνεται επίκαιρο.

Why no HTML email?

Perry E. Metzger explains why he does not allow HTML email to be sent in the cryptography mailing list. I copy-and-paste:

  1. Many people still read their email in systems that handle only plain text effectively. They’re a large enough group that I don’t like disenfranchising them.
  2. HTML email, like most machine parsable data, often has “gotchas”, and as this is a security oriented list, I really don’t want to have to vet email for hacking attempts. Vetting real code is unpleasant enough — I don’t want to have to look for attempted buffer overflows and web bugs in email I’m forwarding.
  3. HTML email is harder to search, to edit down, to cut and paste cleanly, etc.
  4. HTML email is often just plain ugly to look at.

To those who often without previously thinking thoroughly their suggestion and only judging by their own limited experience, propose that he should simply switch his email reader to a GUI one, he responds:

I’m one of the group that reads email in a non-GUI. Please don’t tell me to switch mail readers, because I’ve yet to find a GUI based one that will let me process hundreds to thousands of incoming emails a day efficiently, and without efficiency I’d stop getting any work done. Pretty toys are great if you’re reading 20 messages a day and can’t remember commands — I need stuff that’s fully programmable.)

Haven’t I been told to switch my MUA on numerous occasions! For many many years I even silently refused to accept .doc attachments or worse winmail.dat ones. Why on earth would one fire up Word to write three lines of plaintext?

Oh well, now with alpine’s prospects uncertain, it may be time to check whether sup is a suitable MUA (mail user agent) for me.

[via cryptography]

UW-IMAP utilities and restrictBox mode

Note to self:

When using the UW-IMAP toolkit in restrictBox or closedBox modes, or even with local patches, it is helpful to have a “vanilla” version of the utilities around, for they may not work as expected. It took me a while to figure out why

mailutil prune `pwd`/Trash “before 18-may-2008”

was not working as expected. Our local version was linked with a c-client.a with restrictBox = -1 and a local version of getpwnam(3).

Firefox 3 default mail clients

Από το Gmail Blog:

Εάν θέλετε να έχετε το Gmail σαν default mail client στον Firefox 3, ενώ έχετε ανοίξει στο tab του Firefox το Gmail, κάντε copy-paste στο address bar τον παρακάτω κώδικα:

  • javascript:window.navigator.registerProtocolHandler(“mailto”,”https://
    mail.google.com/mail/?extsrc=mailto&url=%s”,”Gmail”)

Αντίστοιχα από το Yahoo! Mail Blog:

  • Tools -> Options -> Applications -> mailto: -> Use Yahoo! Mail

advise me no more

Τον τελευταίο καιρό λαμβάνω ένα επίμονο ελληνικό image spam το οποίο συνοδευτικά με την εικόνα στέλνει και αυτή την παράγραφο:

ΣΗΜΑΝΤΙΚΗ ΠΛΗΡΟΦΟΡΙΑ
Σύμφωνα με το άρθρο 14 του Νόμου 2672/1998 (ΦΕΚ 290 τ.Α) , τα μηνύματα e-mail, για να είναι έγκυρα θα πρέπει να περιέχουν απαραίτητα : Ονοματεπώνυμο ή επωνυμία (για Νομικό πρόσωπο), ταχυδρομική διεύθυνση κατοικίας, αριθμό τηλεφώνου ή fax, ιδιότητα του χειριστή. Αν τα μηνύματα προέρχονται απο υπηρεσία ή Δημόσιο φορέα να περιέχουν επιπλέον θέμα, ημερομηνία, αριθμό πρωτοκόλλου. Το μήνυμα ηλεκτρονικού ταχυδρομείου τεκμαίρεται οτι έχει περιέλθει κανονικά στον λήπτη αν υπάρξει ηλεκτρονική επιβεβαίωση.

Η εικόνα περιέχει όλα τα προβλεπόμενα κατά τη σημείωση, εκτός από την ιδιότητα του χειριστή. Το ερώτημα είναι: Εάν ο παραλήπτης είναι τυφλός, διαβάζει το email του με text mail reader ή δεν διαβάζει images από τον mail client έτσι κι αλλιώς, πως μπορεί να θεωρεί “νομότυπο” (έστω και εν μέρει) ένα τέτοιο μήνυμα;