ipv6 and smart(er) relaying

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ipv6 and smart(er) relaying

Dave Täht

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.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.

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
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Wietse Venema
Dave T?ht:
> 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.

> 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.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Dave Täht
[hidden email] (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
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Wietse Venema
Dave T?ht:

> [hidden email] (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
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Wietse Venema
In reply to this post by Wietse Venema
Wietse Venema:
> > 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.

... or override routing with relayhost.

So yes, a backup MX server should not use a relayhost unless
it also has a transport map to send mail to the primary MX.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Dave Täht
In reply to this post by Wietse Venema
[hidden email] (Wietse Venema) writes:

> Dave T?ht:
>> [hidden email] (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: [hidden email])

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
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Dave Täht
In reply to this post by Wietse Venema
[hidden email] (Wietse Venema) writes:

> Dave T?ht:
>> [hidden email] (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
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Dave Täht
In reply to this post by Dave Täht
[hidden email] (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
Reply | Threaded
Open this post in threaded view
|

ipv6 and smart(er) relaying

Stan Hoeppner
Dave Täht put forth on 10/6/2009 10:02 AM:

> [hidden email] (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
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.

--
Stan
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Dave Täht
Stan Hoeppner <[hidden email]> writes:

> Dave Täht put forth on 10/6/2009 10:02 AM:
>> [hidden email] (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
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Wietse Venema
In reply to this post by Dave Täht
Dave T?ht:

> [hidden email] (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).

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Dave Täht
[hidden email] (Wietse Venema) writes:

> Dave T?ht:
>> [hidden email] (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
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

@lbutlr
In reply to this post by Stan Hoeppner
On 6-Oct-2009, at 09:37, Stan Hoeppner wrote:
> Your time in this regard
> 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.

Yeah, I have to agree, and I didn't understand a single thing after  
the word 'new'. Something about motors. Some sort of boat?

IPv6 isn't gaining any traction, and IPv4 will be here for decades. I  
mean, unless all your mail is going to your own private intranet.  
Hell, we still have to worry about 7-bit mailservers so have to encode  
all binary data, inflating it 30%.

--
Why live in the world when you can live in your head?

Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Paul Cockings
LuKreme wrote:

> On 6-Oct-2009, at 09:37, Stan Hoeppner wrote:
>> Your time in this regard
>> 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.
>
> Yeah, I have to agree, and I didn't understand a single thing after
> the word 'new'. Something about motors. Some sort of boat?
>
> IPv6 isn't gaining any traction, and IPv4 will be here for decades. I
> mean, unless all your mail is going to your own private intranet.
> Hell, we still have to worry about 7-bit mailservers so have to encode
> all binary data, inflating it 30%.
>
I think i saw that the latest round of Microsoft small business server
(sbs2008?) by default uses IPv6 for LAN side.   That might make IPv6
more popular for the masses, but while no one is forcing me to use IPv6
I won't be spending time setting it up.  Just my 2cents.
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Dave Täht
Paul Cockings <[hidden email]> writes:

> LuKreme wrote:
>> On 6-Oct-2009, at 09:37, Stan Hoeppner wrote:
>>> Your time in this regard
>>> 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.
>>
>> Yeah, I have to agree, and I didn't understand a single thing after
>> the word 'new'. Something about motors. Some sort of boat?
>>
>> IPv6 isn't gaining any traction, and IPv4 will be here for
>> decades. I mean, unless all your mail is going to your own private
>> intranet. Hell, we still have to worry about 7-bit mailservers so
>> have to encode all binary data, inflating it 30%.
>>
> I think i saw that the latest round of Microsoft small business server
> (sbs2008?) by default uses IPv6 for LAN side.   That might make IPv6
> more popular for the masses, but while no one is forcing me to use
> IPv6 I won't be spending time setting it up.  Just my 2cents.


I'm not forcing IPv6 down anybody's throat, adopting it just happened to
solve 3 big problems I'd had recently - being stuck behind double nat
personally, and needing point2point connectivity between a bunch of
secured web and email servers elsewhere without wanting to setup or
maintain a full vpn.

I imagine you all were big fans of NETBUI and IPX/SPX too.

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/


--
Dave Taht http://the-edge.blogspot.com
"The future is here, it just isn't evenly distributed yet"
                         - William Gibson
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

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.
 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.

> 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.
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.

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

--
Stan
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Wietse Venema
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.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Dave Täht
In reply to this post by Stan Hoeppner
Stan Hoeppner <[hidden email]> 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"
                 -
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

Dave Täht
In reply to this post by Wietse Venema
[hidden email] (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
Reply | Threaded
Open this post in threaded view
|

Re: ipv6 and smart(er) relaying

@lbutlr
In reply to this post by Dave Täht
On 7-Oct-2009, at 13:40, Dave Täht wrote:

> I imagine you all were big fans of NETBUI and IPX/SPX too.


Nah, I WANT IPv6 to work, but the fact of the matter is, it's not. The  
ISPs have no interest in supporting it, and until it is simple for  
users to get static IPv6 addresses and rDNS on those addresses the  
appeal of it is just not going to expand in any meaningful way.

And yes, a jump for 0.002% to 0.03% is huge, relatively. But still  
insignificant when looked at in absolute terms. Where's IPv6 now?  
0.04% or so. Not even half a tenth of a percent.

Can I run my mailserver on my DHCP cable with NAT and talk to the  
world only through IPv6?

No? Well, then what good is it?

I'll go out on a limb and say that SMTP email will NEVER move to IPv6.  
If email moves to IPv6 it will be based on something totally new.

--
Why live in the world when you can live in your head?

12