[email protected] (Wietse Venema) writes: > Dave Taht: >> 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 > ... >> 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. > > SMTP is defined in RFCs and the ones concerning SMTP are RFC 821, > RFC 2821, and RFC 5321. By now, most mail systems in existence will > be build after RFC 2821, which says "the SMTP client SHOULD try at > least two addresses". With three MX hosts you're operating outside > the recommendation.
Many hosts seem to have more than 2 MX records. Gmail, for example, has 5. Is anyone aware of any mail servers in the field that only implement the bare minimum of trying 2 MX records? The workaround that I was thinking of doing was implementing bind9 "views" so I have a separate public and private address space (I already do this to handle DNS for the private ipv4 ips). The public view would have two MX records, my laptop and my smarthost, to comply with RFC2821. The private would have three, with the arm box having second priority. I would just as soon not implement a view if I didn't have to. (I am looking into your transport map suggestion as I write) The two holes in this method are 1) the extremely unlikely possibility that my local bind9 fails, and the machine gets DNS from somewhere else, via ipv4. In that case I would end up with a mail loop. Bind9 is setup as a slave server for my domains, so far as I know this can't happen so long as it's the only thing in resolv.conf I'm going to rip the extra nameserver lines out of the machine's /etc/resolv.conf config right now. 2) I'm kind of resistant to running bind9 on the arm box. I'm doing it currently. After two days of use, it eats 23MB of the 64MB of ram available, even with several cache limiting options set. I would really like to find a name server that has a smaller footprint and the features of bind9 that I use (like views, and nsupdate), but so far only maradns comes close. What I figure I will do is implement views, stop postfix/bind nightly, do stuff that is memory intensive (backups, indexing), then restart bind/postfix. >> Problem 2) My smarthost is only smart enough to try sending to one other >> relay (I think). > > 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. OK, so it sounds like the default does the right thing. But, see above. Bind can get killed by the oom-killer at present. Not your problem, I realize. It does kind of bother me that my present hack means that postfix iterates over all the possible and usually ipv4 mx records before falling back to shipping mail off to the dual homed smarthost, and I can't get mail from my non-ipv6 enabled internal, dumber hosts. (The latter I can solve with a port blocking rule in iptables) Would you take a patch that would let a crazed administrator disable *sending* mail on different protocols? The simplest version would implement something like: smtp_try_sendprotocol: all, ipv4, ipv6 A more complex version would let you specify the protocols your configuration would try. smtp_try_sendprotocol_my_networks: all, ipv4, ipv6 smtp_try_sendprotocol_my_relays: all, ipv4, ipv6 Maybe there's a way to do that already.... (Still reading up on transport maps) > Wietse > -- Dave Taht http://the-edge.blogspot.com "Most people know my father as the despotic warlord that rules europa but he does have his amusing sparky qualities. Do you know he really loves waffles?" - Gil Wulfenbach
