We have just released a new rails plugin called workling_mailer. This plugin provides a module which - when included into an ActionMailer subclass - pushes all emails that would normally be delivered synchronously into a queue for asynchronous processing. For queuing it relies on the workling plugin which can use for example twitter’s starling as a queue server.

We use this on autoki which sends a lot of email (thanks to our social feed plugin ).

Recently we got errors from the mailserver complaining about too many concurrent connections. This did not only cause emails not being delivered and our users getting an error page, it also caused long running transactions in the database: if you send an email within an after_create hook in a model this happens inside of the database transaction. That means that if you have a 60s timeout on your mail server you end up with database transactions taking 60s to finish (or being rolled back in this case) which essentially locks up your tables after a short period of time.

Now that we are sending our emails from a queue one at a time, the mailserver is happy and our database transactions are again as short as they should be.

You can get the sources at github.

Eigentlich hatte ich mich schon damit abgefunden: zuletzt erreichten mich taeglich ca. 150 Spam-Emails pro Tag, in denen mir die bekannten Aktienpakete, Pillen und anderen Schätze versprochen wurden. Neulich musste ich dann für einen Kunden ein paar Emailaccounts bei webmail.us (Email-Provider) einrichten. Also schnell Adressen eingetragen und noch kurz eine Testmail versandt und … kam nicht an. Also mal kurz ins Logfile des eigenen Mailserver geschaut und siehe da: temporarily rejected RCPT … greylisted (see http://en.wikipedia.org/wiki/Greylisting).

Greylisted? Black lists, white lists, klar. Aber grau? Schnell nachgesehen und herausgefunden: method of defending electronic mail users against e-mail spam. A mail transfer agent which uses greylisting will “temporarily reject” any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again to send it later, at which time the destination will accept it. If the mail is from a spammer, it will probably not be retried - coole sache, nur … Mailserver umkonfigurieren? Au weia. ich bin froh, dass der überhaupt funktioniert. Glücklicherweise gibt’s für Exim auf Debian ein Paket namens greylistd. Einfach apt-get install greylistd und anschließend ein greylistd-setup-exim4 add und voila - greylisting a la Debian. Und das beste, ich habe in den letzten zweit Tagen tatsächlich nur eine einzige (!) Spam-Email erhalten.

Wenn mir jetzt noch jemand erklärt, wie ich diese Zeitverzögerung beim senden von Emails von dynamisch verteilten IP-Adressen aus wegbekomme….