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 ;)