IPv6 and smarter relaying
I have setup my laptop (as a test) to send out and respond to ipv6 mail, and not listen on the ipv4 ports at all. I tunnel my laptop out to have a static ipv6 address, and have mx records (for the teklibre.org domain) that have a priority 10 for the ipv6 "direct" connection, and a priority 20 mx record for a dual ipv4, ipv6 machine acting as a smart relay. This seems to be working with all the mail exchangers I've tried thus far. I'd like to (assuming I get reverse dns straightened out) convince postfix to: If possible, send out the email from my static ipv6 address to any ipv6 capable mail exchanger (for example, I correspond with someone at isc.org, and their mail exchanger, mx.isc.org sits on both ipv4 and ipv6), and if that is not possible, fall back to my better connected relay host. Right now, everything not in mynetworks gets forwarded to my ipv6 relay host which has both ipv4 and ipv6 addresses because I have relayhost set ? -- Dave Taht http://the-edge.blogspot.com
Re: IPv6 and smarter relaying
d...@teklibre.org (Dave Täht) writes: Half solved! > I have setup my laptop (as a test) to send out and respond to ipv6 mail, > and not listen on the ipv4 ports at all. I tunnel my laptop out to > have a static ipv6 address, and have mx records (for the teklibre.org > domain) that have a priority 10 for the ipv6 "direct" connection, and a > priority > 20 mx record for a dual ipv4, ipv6 machine acting as a smart relay. This > seems to be working with all the mail exchangers I've tried thus far. > > I'd like to (assuming I get reverse dns straightened out) convince postfix to: > > If possible, send out the email from my static ipv6 address to any ipv6 > capable mail exchanger (for example, I correspond with someone at > isc.org, and their mail exchanger, mx.isc.org sits on both ipv4 and > ipv6), and if that is not possible, fall back to my better connected > relay host. > > Right now, everything not in mynetworks gets forwarded to my ipv6 > relay host which has both ipv4 and ipv6 addresses because I have > relayhost set With postfix bound to localhost for IPv4, and bound to a real ipv6 address (via the smtp_bind_address, and smtp_bind_address6 options set) with relayhost disabled and smtp_fallback_relay set to my more smartly connected dual ipv6, ipv4 box, laptop attempts an ipv6 connection against mx records that have ipv6 (isc.org), which worked (very rapidly!) For an ipv4 only mx exchanger (gmail.com), postfix tried, very rapidly, to connect to multiple ipv4 addresses, failed, and ended up forwarding to my smarter host, which did the rest of the work. Half the problem solved. On to getting mail via ipv6 on the laptop... -- Dave Taht http://the-edge.blogspot.com
Re: rbl checks, best place + ipv6?
mouss writes: > Dave a écrit : >> Hello, >> I'm running postfix, amavisd-new and spamassassin. Currently in my >> postfix smtpd_recipient_restrictions right at the end last thing i have some >> rbl checks. I'm wondering if that's the best place for them or should i >> disable that and activate them in spamassassin? Suggestions welcome. >> Thanks. >> Dave. >> > > think defense in depth. at each oignon layer, get rid of part of the > unwanted traffic. > > - at the firewall level, get rid of those "hopeless networks". > > - at postfix level, reject transactions that should not "occur" > (independently of content) > > - at SA, tag mail based on its content. > > > at postfix level, use zen.spamhaus.org. it is safe and effective. you > can also use spamcop and korea.services.net but these won't catch a lot > of junk. other lists are better used in SA. Thank you, I just added that to my rbl list and watched my spam drop dramatically. (I was using an old rbl list, I'm surprised it was working at all) I have been doing weird stuff with ipv6, as well as certs. I am curious if there is a list of mail servers out there running various common smtp servers (postfix, sendmail, exim, exchange, etc) that I could ping via email and have them, according to their rules, filters, etc, send a reply (either back or to an address I'd define) I am painfully aware I don't have reverse DNS working on my ipv6 clients (yet), for example, and also am concerned that TLS negotiation may not work correctly for some ipv4 hosts, and have an on-going concern that any future changes I make to my mail configuration be easily testable. What I found after fighting with an exchange server that what seems to work best is assigning my first mx host to be ipv6 only, and my fallback to be a mx ipv6 and ipv4 host. > -- Dave Taht http://the-edge.blogspot.com
Re: rbl checks, best place + ipv6?
Mark Martinec writes: > On Sunday August 23 2009 04:10:06 Dave Täht wrote: >> What I found after fighting with an exchange server that what seems to >> work best is assigning my first mx host to be ipv6 only, and my fallback >> to be a mx ipv6 and ipv4 host. > > My choice is to have the first MX have both the IPv6 and IPv4 addresses, > but have a lower priority MX be IPv4-only. This way it should provide a > fallback connectivity even if some mailer which thinks it has an IPv6 > connectivity but doesn't, then fails to walk through multiple records > of a multihomed host name. (even though RFC 5321 requires to try > at least two records). In my case, my first mx record is my laptop which has postfix configured to listen and send on IPv6 only. For sending mail, if it can't get through, it falls back to forwarding via IPv6 to the secondary, smarter host, which is listening on both IPv4 and IPv6. Replies to teklibre.org try that IPv6 mx record first (I hope), then fall back to the smarter host. This brings back an age of direct email connectivity for all the IPv6 hosts on my fairly widely geographically spaced network. Mail gets through as fast as IM (or faster), with a minimum of men in the middle, over IPv6 whenever possible. I still have to get reverse DNS to resolve, working on it... (the 8 hosts I have exchanging mail this way use certs to identify and authenticate themselves currently) This leaves the problem of dealing with non RFC 5321 compliant hosts, but to heck with them, and so far, I haven't had anyone complain that they can't get mail to me (I am continuing to experiment, however). > > Mark > -- Dave Taht http://the-edge.blogspot.com
ipv6 and smart(er) relaying
A couple weeks back I started running most of the mail servers I am responsible for over ipv6. (I posted a few notes to this list on that) 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] 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 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 mail got transfered via dial up connection or via carrier pigeon? Technologically, I 'm living there, admittedly with a splendid view of the ocean. Running my mail server on 300mw makes a lot of sense - I have enough battery power to run for days instead of hours sipping it 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.% 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. Problem 2) My smarthost is only smart enough to try sending to one other relay (I think). Problem 3) Similarly myarmbox 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. 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 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 down... 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, 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. -- 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
Re: ipv6 and smart(er) relaying
wie...@porcupine.org (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
Re: ipv6 and smart(er) relaying
wie...@porcupine.org (Wietse Venema) writes: > Dave T?ht: >> wie...@porcupine.org (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, > > Unlike your unsupported configuration, gmail etc. do NOT require > that a client tries MORE THAN TWO addresses. Gotcha. This morning I implemented a bind9 view that should be showing two MX records only, publicly, for teklibre.org, and shows three, internally. Mail is successfully getting routed through the arm box both incoming and outgoing, and queues up there when the main internal server is down. (I might have bounced a mail or two along the way, and if any further mail bounces, please tell me via a less-strangely routed email address: d...@teklibre.com) So... Postfix... Running out of flash... On an Arm... ***Running at 300 milliwatts*** Nice way to spend a weekend's hacking. Thanks for the help! -- 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
Re: ipv6 and smart(er) relaying
wie...@porcupine.org (Wietse Venema) writes: > Dave T?ht: >> wie...@porcupine.org (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, > > Unlike your unsupported configuration, gmail etc. do NOT require > that a client tries MORE THAN TWO addresses. > > Wietse I implemented bind9 views to present 2 MX records to the world, and 3 to my internal servers, with multiple smtp_fallback_relays as per your suggestions. Postfix is smart enough to figure it all out. The tiny arm box is working well now. Most of my remaining problems re email are DNS related and not relevant to this list, so I have been making updates to my blog regarding this project and the problems I've made for myself. Thanks for the help! -- Dave Taht http://the-edge.blogspot.com
Re: ipv6 and smart(er) relaying
d...@teklibre.org (Dave Täht) writes: One unanswered question from this series of emails: >> Dave Taht: > > 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 this already... -- Dave Taht http://the-edge.blogspot.com
Re: ipv6 and smart(er) relaying
Stan Hoeppner writes: > Dave Täht put forth on 10/6/2009 10:02 AM: >> d...@teklibre.org (Dave Täht) writes: >> >> One unanswered question from this series of emails: >> >>>> Dave Taht: >>> 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 this already... > > The world is going to force you to send your SMTP IPv6 email through an > IPv4 gateway for a very, very, very long time. Your time in this regard It's not going to force ME to send MY mail through an ipv4 gateway, nor on any other of the networks I run. Setting up ipv6 is too easy nowadays and direct p2p connectivity from secure site to secure site too useful to give up. > would be much better spent building a new supercharged 440 Hemi to drop > into a '70 Barracuda that you've redone from the frame rails up. ;) > That's a much more worthy use of your time. Heh. Aformentioned vehicle would also have to have "Damnation Alley" tires to survive more than a few miles where I live. I'll think about it... but getting/sending my email reliably during fits of internet inaccess is far more important than traveling anywhere, > > -- > Stan > -- Dave Taht http://the-edge.blogspot.com "Most people know my father as the despotic warlord that rules europa but he does have his musing sparky qualities. Do you know he really loves waffles?" - Gil Wulfenbach
Re: ipv6 and smart(er) relaying
wie...@porcupine.org (Wietse Venema) writes: > Dave T?ht: >> d...@teklibre.org (Dave T?ht) writes: >> >> One unanswered question from this series of emails: >> >> >> Dave Taht: >> > >> > 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 this already... > > Postfix sorts the remote SMTP server IP addresses by MX preference, > which are numbers in the range 0..32767. The next step is to avoid > backup MX loops: for this, the Postfix SMTP client must remove all > MX addresses that have the same of worse preference than Postfix's > own IP address. > > To give preference for IPvX over IPvY, it is sufficient to tweak > those preference numbers. For example, one could multiply the MX > preferences by 2, then add 1 if the address belongs to the less > preferred protocol. With this, Postfix can still correctly avoid > backup MX loops (the address elimination becomes a little trickier, > though). In my case, the mail servers involved are generally behind ipv4 NAT and thus will not have a correct reverse lookup. If they try to connect at all with other ipv4 servers on the net, some will no doubt be rejected (rightly) due to anti-spam measures. They need to iterate through the ipv6 enabled components of the mx list, then fall back to the dual homed smart host(s). They do (all but one that I'm trying to get fixed today (and coping with reverse DNS is a major hassle with ipv6)) have a valid reverse for ipv6 addresses. You make a good point about the possibility of invoking a mx loop if filtering of mx records and smart hosts is combined. I will try to wrap my head around it and the code this weekend. -- Dave Taht http://the-edge.blogspot.com
Re: ipv6 and smart(er) relaying
Stan Hoeppner writes: > Dave Täht put forth on 10/7/2009 2:40 PM: > >> I imagine you all were big fans of NETBUI and IPX/SPX too. > > That's a bit like comparing a German Shepherd and a Poodle to a Pig and > a Giraffe. IPv4/IPv6 share the same architecture (same species) and > base protocol, but use different addressing. IPv6 adds some sprinkles. > They are inter operable to a large degree. > > NetBeui/NetBIOS and IPX/SPX were completely different animals. IPX/SPX > had substantial benefits over NetBeui, specifically it could be routed > and the broadcast overhead wasn't as servere. They shared no > underpinnings (different species), and were not inter operable. > > You're making IPv6 out to be a much larger _core_ feature upgrade than > it really is. Well, actually, I was just venting. I'd solved an interesting problem in an interesting way. I was happy. > >> In terms of traction, here's a new data point for you: >> >> http://asert.arbornetworks.com/2009/09/who-put-the-ipv6-in-my-internet/ > > ROFL. Less than 1 percent (and from what God did Arbor get world wide > network statistics?) You quoted an article using Hurricane Electric as > it's crown jewel? HE is/was one of the largest spam hosts on the > planet. Many mail admins/orgs block their entire IPv4 address space, > including Nortel, a Canada based, worldwide telecom/network hardware > manufacturer with ~25K employees. Makes you wonder why HE is pushing > hard to transition to IPv6 eh? > > There was a very lengthy discussion about IPv6 on spam-l a while back. I will google for that discussion. I am always willing to learn. > Unanimous opinion was that all inbound SMTP mail from IPv6 addresses > would be outright blocked, period. Sending mail servers and MX hosts > must stay on IPv4 addresses, period. The reason? Yep, you guessed it, > spam. If everyone said, "sure, we'll accept your IPv6 mail traffic", > overnight, spammers would switch to IPv6, making 15 years of antispam > intelligence useless, and inboxen would overflow with thousands of > spams/day again before the anti-spam crowd could catch up. I agree that many of the anti-spam features developed over the last decades break down over ipv6. On the other hand quite a few features do apply. I sincerely doubt that everyone will switch to mail, or anything, really, over ipv6 overnight, and given the negative reaction among the anti-spam crowd, I concede it likely that smtp email may never be accepted over ipv6. Email, as we know it, will continue to become increasingly irrelevant, replaced by less painful protocols. > The public internet mail stays on IPv4 kids, whether you like it or not. > That's the way it's going to be, even if _everything else_ converts to > IPv6, smtp mail won't. For the rather distant foreseeable future at > least (10-20 years, maybe indefinitely). I take it this discussion took place entirely in english? In my case, Ipv6 solved a real problem. I tried really hard with my solution by participating on this list (and succeeded) in making my hybrid solution fully RFC compliant and interoperate with (so far as I can tell) 100% of the servers on the internet and hopefully some percentage of the future servers more directly and efficiently. I used cacert certificates, starttls encryption, and all but one of my ipv6 servers has valid reverse dns (which I am still fixing). Is there an Ipv6 provider with a less bad reputation that Hurricane? I wouldn't mind seeing ipv6 based mail servers adopt more stringent crypto and cert requirements than proposed by current rfcs, either, changing certain requirements from MAY to MUST... Did the discussion on spam-l result in an RFC? I have a pretty good anti-spam setup on the ipv4 side and one that is almost as good on the ipv6 side. (What I intend to do is aim one of my spam sump mailboxes at a test server in a jail and see what happens, I'm under the impression there is ivp6 rbl support now) In the end, we all have to keep banging the rocks together, kids or no. > > -- > Stan > -- Dave Taht http://the-edge.blogspot.com "The future is here, it just isn't evenly distributed yet" -
Re: ipv6 and smart(er) relaying
wie...@porcupine.org (Wietse Venema) writes: > Stan Hoeppner: >> Dave T?ht put forth on 10/7/2009 2:40 PM: >> >> > I imagine you all were big fans of NETBUI and IPX/SPX too. >> >> That's a bit like comparing a German Shepherd and a Poodle to a Pig and >> a Giraffe. IPv4/IPv6 share the same architecture (same species) and >> base protocol, but use different addressing. IPv6 adds some sprinkles. > > This is no longer about Postfix. Take it off-list, please. > Done, sorry. > 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 musing sparky qualities. Do you know he really loves waffles?" - Gil Wulfenbach
