I keep learning about email architectures, and I'm always astonished of what I find :) Today, I had a tiny server blackout, and while I was restarting my services, I noticed that an email I was highly expecting arrived a 5pm.... and got rejected by postgrey !

Oct 20 17:05:32 smtp2 postfix/smtpd[30121]: NOQUEUE: reject: RCPT from 
<example.net>[11.22.33.44]: 450 4.2.0 <julien@lin.....info>: Recipient address 
rejected: Message rejected by greylisting policy; from=<kevin@example.net> 
to=<julien@lin.....info> proto=ESMTP helo=<example.net>

That's usually fine, the SMTP server on the sender's side will retry after a few minutes, and I will receive my email with a minimum delay. But in that case, it seems that 2 hours after the first attempt, the sender's smtp (a lazy Sendmail) had not retried yet. And I was still waiting for my email !

This is when ETRN comes to help. ETRN stands for Extended Turn and is a extended SMTP implementation of the TURN command. What ETRN does is simple. It ask a mail server to start delivering the messages it is holding for a specific recipient (or recipient's domain).

Lazy sendmail didn't want to retry by itself ? No problem, I when with my buddy netcat knock at its door and issued a ETRN command to ask it to start sending the emails it had for me. It's as simple as this:

# nc 11.22.33.44 25
220 example.net ESMTP Sendmail 8.12.11/8.12.11; Wed, 20 Oct 2010 12:06:30 -0500
ehlo mail
250-example.net Hello reverse dns [55.66.77.88], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH GSSAPI LOGIN PLAIN
250-DELIVERBY
250 HELP
ETRN linuxwall.info
250 2.0.0 Queuing for node linuxwall.info started
quit
221 2.0.0 example.net closing connection

ETRN doesn't return the awaiting messages on the current connection. Instead, the sender's mail server will establish a new connection to the recipient's mail server and attempt to deliver again. Thanksfully, this time, without having postgrey messing with it ;)