ipv6 and smart(er) mail relaying in postfix

A couple weeks back I started running most of the mail servers I am responsible for over ipv6. I posted a few notes to the postfix mailing list on that.

(My apologies for the excessively geeky contents of this blog recently, I have a few more "normal", real world. blog entries in the queue...)

I posted this question to the postfix mailing list today. (I got some good responses, more info the Updates sections)

I'm trying to wrap my head around a new problem - trying to have two postfix relays and a smart host co-exist where one of the relays is a tiny power sipping ARM based board... (Read on for details)

To recap, what I did was configure my in-house (and other servers I run) server to only listen and send on ipv6 via:

smtp_bind_address6 = my:ip:v6:ad:re::ss
smtp_bind_address = 127.0.0.1

And forward mail to my ipv6/ipv4 smarthost located in the co-lo facility via:

smtp_fallback_relay = [mysmarthost_onivp6.example.org]

For when that doesn't work. Postfix tries connecting directly to the given email addresses, which are usually ipv4, fails rapidly due to being bound to localhost only, then forwards to the smart host, for ipv4 hosts.

This handles the common case where people refuse mail delivered directly to them via ipv4 from invalid reverse dns, and hopefully works generically for those few sites (including my own) that exchange mail over ipv6.

That's been working pretty good. I'm not aware of having missed any mail at all since switching to this method. All the servers I control are exchanging email directly over ipv6 without the smarthost in the loop. I like it. Email is direct, secuire, and as fast as instant messaging once again.

Now I'm trying to wrap my head around a new problem.

Recently I built a 300mw (that's milliwatt!) postfix mail router out of an old 64MB ram TS7250 ARM board I had lying around and a 4GB usb stick, running debian lenny.

It works pretty good in my testing so far. STARTTLS Crypto works, it runs at the speed of my internet link (24KB/sec) without any problem, and transfers on the internal net at ~500KB/sec (it's bound by the usb stick, actually). I have not abused it heavily yet - I need to see what happens when I send very large emails, for example. I will have to limit the number of inbound and outbound connections, to be sure.

(I live way out in the country, and have a (slow) wireless connection to the net. Power and/or internet frequently go out. Remember the bad old days, when email got transfered via dial up connection or via carrier pigeon? Technologically, I'm living there, admittedly with a splendid view of the ocean.

Running a 300mw mail server makes a lot of sense - I have enough battery power to run for days instead of hours sipping power like that (the wireless router uses about 5w) It beats running mail on my laptop, at 65w, by a country kilometer.)

So what I think I want to do is setup fallback relaying as follows:

MX 5 mylaptop.example.org # if my laptop's up send mail there
MX 10 mytinyarmbox.example.org # if not, try my arm box
MX 20 mysmarthost.example.org # otherwise, default to my well connected host

Now, 99.9999% of the internet is NOT relaying mail over ipv6, so what happens in that case is my or your mail ends up at my smarthost, which then relays it for me.

Problem 1) I am under the impression from a foggy memory of reading some RFC or other, that at minimum, 2 MX records will be tried. So adding a third might introduce problems with some MTAs that ONLY do 2 MX records, in that far off day when more stuff speaks ipv6 directly, or when it
fails to fallback to my third, primary smarthost.

Update: Wietse Venema quoted me chapter and verse of the related RFC2821, which states:

"the SMTP client SHOULD try at least two addresses". With three MX hosts you're operating outside the recommendation.

More on how I currently solve this are going to be subject of another blog entry. Briefly, I implemented Bind9 "views" to present two MX records to the outside world, and 3 to my own. Postfix exceeds the RFC in every respect, and does the right thing. Solved. I'm routing my own damn mail.

Problem 2) My smarthost is only smart enough to try sending to one other relay (I think).

Problem 3) Similarly mytinyarmbox is only smart enough to try sending to one smarthost. I'm afraid if I set it up to relay it will fail to reach my laptop, then relay mail back to the main smarthost which will relay it back to the arm box which will relay it back to the smarthost until the loop count is exceeded. I guess I'm looking for some "never use the smarthost relay for these domains" option in postfix... Obviously, after googling, I'm not phrasing the question right....

Update: It turned out that the smarthost lines in postfix "do the right thing". It will not try to send email to a server that I control that has a lower MX record priority than itself. I couldn't find an answer on google, because smarthost does it right to begin with! Wietse, again:

If the machine sends mail to a less preferred MX host than itself,
then it is badly borked. To pull that off with Postfix you would
have to turn off DNS or override the routing with a transport map.

All I did was add another smarthost to my laptop, so when it can't get to my main server, it forwards the mail to myarmbox. In /etc/postfix/main.cf:

smtp_fallback_relay = [myreallysmarthost.example.org] [mytinyarmbox.example.org]

Bing! I can turn my laptop off 10 seconds after sending the last mail, and know that my mail will eventually get to the Net without my further intervention.

Now, it turns out I badly borked DNS the next day, and I'm still sorting through that, but that's not a postfix issue.

Problem 4) My laptop/primary mail server is actually on a dynamic ipv6 address (I control what ipv6 tunnel it is running on and update its dns record with nsupdate when it changes), so that no matter where I am, I have an ipv6 connection, when I have a connection. It seems inefficient
to route mail to my house and then back if I'm not there, especially when my house is off the net and I'm not there to fix it...

Update: The above problem is basically fixed by the dual smarthost line.

I am patently aware that there are other, less crazy ways to do all this (like fetchmail or offlineimap), but 1) I get a lot of mail (think: lkml) so getting email whenever possible, in the background, rather than via a cron job that eats my connection for minutes or hours at a time, is a good idea, and 2) I have to run my own mail servers anyway, so why not skip that step? And 3) It's kind of fun.)

If anyone would like to dink with this little arm box, email me privately, I'll set you up an account.

Labels: arm debian, embedded, ipv6, postfix

  ¶ 10:01 AM 0 comments