[Brian May] IPv6 Linux question

2020-12-10 Thread Brian May via luv-main
I have posted this question here with some minor updates here:

https://unix.stackexchange.com/questions/623274/ipv6-addresses-on-interface-not-responding-to-ndp-packets-on-other-interface

 Start of forwarded message 
From: Brian May 
To: luv-main@luv.asn.au
Subject: IPv6 Linux question
Date: Sat, 05 Dec 2020 15:06:24 +1100

>From a given computer, if I do the following:

canidae# ip add dummy0 type dummy  
Command "dummy0" is unknown, try "ip address help".

canidae# ip link add dummy0 type dummy
canidae# ip addr add dev dummy0 2001:44b8:4112:8a02::55 
canidae# ip addr add dev dummy0 192.168.2.55
canidae# ip link set dummy0 up

Now from another computer on the network, I can ping 192.168.2.55. It
does not matter that the packets are coming in on enp3s0, not dummy0
because the IP address is global.

But I cannot ping 2001:44b8:4112:8a02::55 from a remote host unless I
assign the address to enp3s0.

My understanding is that this is suppose to work for IPv6 the same as
IPv4, but it doesn't.

This computer has no ip6tables that might be blocking something.

This computer is:

canidae# uname -a
Linux canidae 5.9.0-3-amd64 #1 SMP Debian 5.9.9-1 (2020-11-19) x86_64
GNU/Linux

But I have seen similar behaviour with:

root@kube-node-3:~# uname -a
Linux kube-node-3 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 
GNU/Linux

How do I fix?
-- 
Brian May 
https://linuxpenguins.xyz/brian/
 End of forwarded message 
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main


Re: Good starting point for learning about IPv6?

2018-07-28 Thread Duncan Roe via luv-main
On Wed, Jul 25, 2018 at 05:09:31PM +1000, luv-main wrote:
> Hey folks,
>
> Where's a good place to learn about IPv6?
>
> I've *mostly* got my head around IPv4 these days, and my ISP still only has
> an unsupported 6rd gateway which I've tried with momentary success on my
> router.
>
> I understand that the address space is 128 bits vs 32, that successive
> colons mean  between them, that devices can have "local" and "global"
> scoped addresses, and it's *supposed* to do away with NAT... but that's
> about as far as I've gotten :)
>
> A server I lease overseas has an IPv6 address block assigned to it, and I'm
> struggling to figure out how I'm supposed to assign a reverse DNS to it, so
> Google and friends don't flag it for the MTA not having a reverse lookup
> (for now, I just lock it to IPv4)... I figured I might as well learn more
> about how it works, different to IPv4..
>
> Any practical pointers?

I would recommend reading RFC 8200 "Internet Protocol, Version 6 (IPv6)
Specification", available from https://tools.ietf.org/html/rfc8200.

I learned IPv4 (or more especially UDP & TCP) from RFCs 791, 768 & 793.

Cheers ... Duncan.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main


Re: Good starting point for learning about IPv6?

2018-07-26 Thread Anthony via luv-main
Sounds good to me. I mean we keep getting told that IPv4 is going to go
away so I figure it's something worthwhile knowing..

Others'd be interested?

On Wed, Jul 25, 2018 at 7:45 PM Russell Coker  wrote:

> That would be a good topic for a Saturday session. I could run it.
>
> On 25 July 2018 5:09:31 pm AEST, Anthony via luv-main 
> wrote:
> >Hey folks,
> >
> >Where's a good place to learn about IPv6?
>
>
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main


Re: Good starting point for learning about IPv6?

2018-07-25 Thread Russell Coker via luv-main
That would be a good topic for a Saturday session. I could run it.

On 25 July 2018 5:09:31 pm AEST, Anthony via luv-main  
wrote:
>Hey folks,
>
>Where's a good place to learn about IPv6?
>
>I've *mostly* got my head around IPv4 these days, and my ISP still only
>has
>an unsupported 6rd gateway which I've tried with momentary success on
>my
>router.
>
>I understand that the address space is 128 bits vs 32, that successive
>colons mean  between them, that devices can have "local" and
>"global"
>scoped addresses, and it's *supposed* to do away with NAT... but that's
>about as far as I've gotten :)
>
>A server I lease overseas has an IPv6 address block assigned to it, and
>I'm
>struggling to figure out how I'm supposed to assign a reverse DNS to
>it, so
>Google and friends don't flag it for the MTA not having a reverse
>lookup
>(for now, I just lock it to IPv4)... I figured I might as well learn
>more
>about how it works, different to IPv4..
>
>Any practical pointers?

-- 
Sent from my Huawei Mate 9 with K-9 Mail.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main


Re: Good starting point for learning about IPv6?

2018-07-25 Thread Brett Pemberton via luv-main
I recommend following along with the certification here:
https://ipv6.he.net/certification/

It's a reasonable intro

Cheers,
Brett

On Wed, 25 Jul. 2018, 5:09 pm Anthony via luv-main, 
wrote:

> Hey folks,
>
> Where's a good place to learn about IPv6?
>
> I've *mostly* got my head around IPv4 these days, and my ISP still only
> has an unsupported 6rd gateway which I've tried with momentary success on
> my router.
>
> I understand that the address space is 128 bits vs 32, that successive
> colons mean  between them, that devices can have "local" and "global"
> scoped addresses, and it's *supposed* to do away with NAT... but that's
> about as far as I've gotten :)
>
> A server I lease overseas has an IPv6 address block assigned to it, and
> I'm struggling to figure out how I'm supposed to assign a reverse DNS to
> it, so Google and friends don't flag it for the MTA not having a reverse
> lookup (for now, I just lock it to IPv4)... I figured I might as well learn
> more about how it works, different to IPv4..
>
> Any practical pointers?
> ___
> luv-main mailing list
> luv-main@luv.asn.au
> https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
>
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main


Good starting point for learning about IPv6?

2018-07-25 Thread Anthony via luv-main
Hey folks,

Where's a good place to learn about IPv6?

I've *mostly* got my head around IPv4 these days, and my ISP still only has
an unsupported 6rd gateway which I've tried with momentary success on my
router.

I understand that the address space is 128 bits vs 32, that successive
colons mean  between them, that devices can have "local" and "global"
scoped addresses, and it's *supposed* to do away with NAT... but that's
about as far as I've gotten :)

A server I lease overseas has an IPv6 address block assigned to it, and I'm
struggling to figure out how I'm supposed to assign a reverse DNS to it, so
Google and friends don't flag it for the MTA not having a reverse lookup
(for now, I just lock it to IPv4)... I figured I might as well learn more
about how it works, different to IPv4..

Any practical pointers?
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Brian May via luv-main
Russell Coker  writes:

> Is there any way to publish the fact that I would prefer to receive mail via 
> SSL?

Not that I know of. I think you would have to configure the sending
server to require it for the destination server. Which really isn't what
you wanted.

> My understanding is that if a hostile party proxies the SMTP session such 
> that 
> the sender thinks that my MTA is incapable of SSL then the sender will 
> happily 
> send it unencrypted.

Yes, I believe you could be correct here. The sending server has no
secure way of knowing that the remote server supports SSL.

Ideally this could be published in DNS, I am not aware of any standards
to do this however. I haven't looked either.
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Erik Christiansen via luv-main
On 16.01.16 22:24, Andrew Pam via luv-main wrote:
> I'm all for loudly shaming organisations who break things, but I don't
> think it helps users to refuse to interoperate with them.  Should we
> insist that LUV members boycott Gmail, Yahoo, Facebook etc. unless and
> until they fix these email issues?  I don't think many of our members
> would thank us.

If we do not, then we define our list as a subservice of the capturing
hegemon.

Erik
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Craig Sanders via luv-main
On Sat, Jan 16, 2016 at 05:08:23PM +1100, Russell Coker wrote:
> On Sat, 16 Jan 2016 05:00:58 PM Craig Sanders via luv-main wrote:
> If you believed that there was nothing you could do then you wouldn't
> have spent months arguing.

i haven't. i've mostly ignored it for most of the last few months since
you broke the list and only got sucked into it in the last few days
because the thread's been going on for about a week.

and my procmail rule partially unbreaks the list (except for the munged
 Reply-To: header which 1. is unfixable and 2. isn't used much by
subscribers here AFAIK)


> OK, please go tell Yahoo etc that they are doing it wrong.  Let's
> leave the list server in it's current configuration until you convince
> Yahoo and Gmail of the error of their ways.

if you intend to do nothing, then just say so - don't make up some
bullshit impossible goal that "might" get you to unbreak the list.


> Actually the Gmail users didn't do anything, they just signed up for
> a mail service knowing nothing about DKIM or the Gmail actions that
> would happen when they received DKIM signed mail via a list.

it's really difficult to have much sympathy for the technical problems
experienced by people who chose to use a spyware service run by a giant
corporation.  They CHOSE to have no control over their mail, they get to
just suck it up and accept whatever problems that causes.  They don't
get to assume that their abdication of responsibility for their own
email automatically entitle them to cause problems for others.


> If they were so wrong then Gmail wouldn't implement DKIM/DMARC checks
> on mail it receives.

google has their own reasons for destroying independently run mailing
lists.

> > the mailman devs have obviously got it wrong. even they admit that
> > their implementation is buggy and broken.
>
> What is buggy is the fact that they can't preserve headers and body
> encoding.

there's also the fact that mailman strips attachments and makes other
changes to the message body which is going to invalidate any signing of
the original msg.

Look, the major problem with DMARC is that it uses the From: header.

If it used the Sender: header instead (or used it IF it exists in
the headers), then mailman could do the right thing by stripping
attachments, changing the encoding, or whatever and declare that the
list was the Sender: and DKIM sign it.

> > you're assuming that there is such a way.  IMO DMARC is
> > broken-by-design so it's impossible to do it in any good or even
> > reasonable way.
> >
> > in other words: the way i'd like is to not do it at all. i've said
> > that repeatedly.
>
> It's OK to wish that Yahoo, Gmail, Hotmail, Facebook, and other big
> companies would do things differently.  But your wishes aren't going
> to change anything.  Let's stick to discussing the reality of how to
> deal with mail to/from such services.

i didn't wish they did things differently, at least that's not the
argument i'm making here. my attitude is that their unreasonable demands
about changing the nature of email and mailing lists should be ignored,
not surrendered/pandered to.

craig

-- 
craig sanders 
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Chris Samuel via luv-main
On Fri, 15 Jan 2016 08:51:19 PM Joel W. Shea via luv-main wrote:

> Are there any minutes taken/published for committee meetings?

It's a legal requirement of the act that governs associations in Victoria for 
there to be minutes of committee meetings.

Members have a right to request to see such minutes but the committee has the 
right to refuse or excise parts for various listed reasons.

All the best,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Russell Coker via luv-main
On Sat, 16 Jan 2016 09:01:11 PM Craig Sanders via luv-main wrote:
> > OK, please go tell Yahoo etc that they are doing it wrong.  Let's
> > leave the list server in it's current configuration until you convince
> > Yahoo and Gmail of the error of their ways.
> 
> if you intend to do nothing, then just say so - don't make up some
> bullshit impossible goal that "might" get you to unbreak the list.

I have been very clear from the start that I intend to have the lists work 
reliably for delivering mail from all users (including Yahoo) and too all 
users (including Yahoo and Gmail).  I have no plans to change that.

I am entirely serious that if DMARC was to go away I would remove the DMARC 
specific setting.

> > Actually the Gmail users didn't do anything, they just signed up for
> > a mail service knowing nothing about DKIM or the Gmail actions that
> > would happen when they received DKIM signed mail via a list.
> 
> it's really difficult to have much sympathy for the technical problems
> experienced by people who chose to use a spyware service run by a giant
> corporation.  They CHOSE to have no control over their mail, they get to
> just suck it up and accept whatever problems that causes.  They don't
> get to assume that their abdication of responsibility for their own
> email automatically entitle them to cause problems for others.

So this is really a debate about who's the most elite under the guise of 
discussing list headers?

> > > the mailman devs have obviously got it wrong. even they admit that
> > > their implementation is buggy and broken.
> > 
> > What is buggy is the fact that they can't preserve headers and body
> > encoding.
> 
> there's also the fact that mailman strips attachments and makes other
> changes to the message body which is going to invalidate any signing of
> the original msg.

Yes.  But I'm not aware of other list software that does what we want and 
solves these problems.

> Look, the major problem with DMARC is that it uses the From: header.
> 
> If it used the Sender: header instead (or used it IF it exists in
> the headers), then mailman could do the right thing by stripping
> attachments, changing the encoding, or whatever and declare that the
> list was the Sender: and DKIM sign it.

Well that wasn't what DMARC was designed to do.

> > It's OK to wish that Yahoo, Gmail, Hotmail, Facebook, and other big
> > companies would do things differently.  But your wishes aren't going
> > to change anything.  Let's stick to discussing the reality of how to
> > deal with mail to/from such services.
> 
> i didn't wish they did things differently, at least that's not the
> argument i'm making here. my attitude is that their unreasonable demands
> about changing the nature of email and mailing lists should be ignored,
> not surrendered/pandered to.

We have to either make the list work with mail to/from such services or 
exclude them from the lists.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Craig Sanders via luv-main
On Sat, Jan 16, 2016 at 09:32:14PM +1100, Russell Coker wrote:
> > > Actually the Gmail users didn't do anything, they just signed up for
> > > a mail service knowing nothing about DKIM or the Gmail actions that
> > > would happen when they received DKIM signed mail via a list.
> > 
> > it's really difficult to have much sympathy for the technical problems
> > experienced by people who chose to use a spyware service run by a giant
> > corporation.  They CHOSE to have no control over their mail, they get to
> > just suck it up and accept whatever problems that causes.  They don't
> > get to assume that their abdication of responsibility for their own
> > email automatically entitle them to cause problems for others.
> 
> So this is really a debate about who's the most elite under the guise of 
> discussing list headers?

WTF has "elite" got to do with it?

if you choose to use a crappy service, you get a crappy service. same as
if you choose to eat dogfood out of a can or, worse, McDonalds, you get
to eat crappy pseudo-food.

choosing crap means you get crap. that's just one of the unalterable
facts about how the universe works. you can't choose crap things and
magically get good things.


> > Look, the major problem with DMARC is that it uses the From: header.
> > 
> > If it used the Sender: header instead (or used it IF it exists in
> > the headers), then mailman could do the right thing by stripping
> > attachments, changing the encoding, or whatever and declare that the
> > list was the Sender: and DKIM sign it.
> 
> Well that wasn't what DMARC was designed to do.

DMARC's design is broken.

> We have to either make the list work with mail to/from such services or 
> exclude them from the lists.

so?

how is that different to any other site or individual who deliberately
(or incompetently) breaks the expected standards? are google and
facebook and yahoo etc allowed to redefine standards just by breaking
them and demanding that everyone else follows their new way? who else is
allowed to do that? do you have to be a mega-corporation with billions
of dollars or is that priviledge available to us peasants too?


craig

-- 
craig sanders 

BOFH excuse #320:

You've been infected by the Telescoping Hubble virus.
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Erik Christiansen via luv-main
On 16.01.16 21:42, Russell Coker wrote:
> On Sat, 16 Jan 2016 09:20:03 PM Erik Christiansen via luv-main wrote:
> > You have still not informed us why you insist on denying list members a
> > genuine From: field, merely to grant the same to others. (My
> > understanding is that it is because you have not found a workable
> > solution to some other minor issue, so you've created a bigger problem.)
> 
> You are obviously not reading any messages that I write.  I am not going to 
> explain myself again.
> 
> It's time for this discussion to end.
> 
> Please take all further replies to luv-talk.

No. We will discuss the adequacy of the performance of the list server
on this list. Thank you for your participation.

Erik
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Joel W. Shea via luv-main
On Sat, Jan 16, 2016 at 05:08:23PM +1100, Russell Coker wrote:
> 
> OK, please go tell Yahoo etc that they are doing it wrong.  Let's
> leave the list server in it's current configuration until you convince
> Yahoo and Gmail of the error of their ways.

I would personally join the DMARC working group, if I thought I could
make any difference; but judging from the RFC, I can infer that my only
proposed suggestions have already been considered and placed out of
scope.


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Joel W. Shea via luv-main
On Sat, Jan 16, 2016 at 12:31:47PM +1100, Russell Coker wrote:
> > [...] headers are merely comments. To treat them as anything
> > different is just plain wrong.
> 
> Why are we having an argument about comments then?  If they are just
> comments then it shouldn't be a big deal.

Unfortunately the RFC5322.From field is one of the few comments that
MUST be present, which most MUA depend on to make the (claimed) author
visible to the user. 

It's disappointing that MUA weren't expected to highlight authenticated
authors instead (which they can already do with PGP and S/MIME), and
like we do in the browser world with SSL/TLS authenticated servers.

So rather than depend on MUA, the DMARC working group, along with the
RFC authors from Yahoo and Google, for better or worse decided to ensure
MTA took ownership of that responsibility instead.

To make matters worse, they will not entertain any alternatives, as the
RFC, and working group, clearly makes alternative fields (incl.
"Sender") out of scope


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Russell Coker via luv-main
On Sat, 16 Jan 2016 09:20:03 PM Erik Christiansen via luv-main wrote:
> You have still not informed us why you insist on denying list members a
> genuine From: field, merely to grant the same to others. (My
> understanding is that it is because you have not found a workable
> solution to some other minor issue, so you've created a bigger problem.)

You are obviously not reading any messages that I write.  I am not going to 
explain myself again.

It's time for this discussion to end.

Please take all further replies to luv-talk.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Erik Christiansen via luv-main
On 16.01.16 21:01, Craig Sanders via luv-main wrote:
> On Sat, Jan 16, 2016 at 05:08:23PM +1100, Russell Coker wrote:
> > Actually the Gmail users didn't do anything, they just signed up for
> > a mail service knowing nothing about DKIM or the Gmail actions that
> > would happen when they received DKIM signed mail via a list.
> 
> it's really difficult to have much sympathy for the technical problems
> experienced by people who chose to use a spyware service run by a giant
> corporation.  They CHOSE to have no control over their mail, they get to
> just suck it up and accept whatever problems that causes.  They don't
> get to assume that their abdication of responsibility for their own
> email automatically entitle them to cause problems for others.

Corporations cannot be allowed to deny the freedom of internet traffic.
If their DSHIT needs a header, then let them tack one on. It is both in
principle and in practice unacceptable to allow them to hijack existing
headers, particularly as it is to the practical detriment of list users.

If a minority of list members have made the mistake of using gmail, then
I _do_ have sympathy - sufficient to cordially recommend them moving to
a service which does not set out to break independent mailing lists.

Out list is _not_ primarily a subservice of gmail ... well, until
recently, it wasn't.

> 
> > If they were so wrong then Gmail wouldn't implement DKIM/DMARC checks
> > on mail it receives.
> 
> google has their own reasons for destroying independently run mailing
> lists.

+1

...

> > It's OK to wish that Yahoo, Gmail, Hotmail, Facebook, and other big
> > companies would do things differently.  But your wishes aren't going
> > to change anything.  Let's stick to discussing the reality of how to
> > deal with mail to/from such services.
> 
> i didn't wish they did things differently, at least that's not the
> argument i'm making here. my attitude is that their unreasonable demands
> about changing the nature of email and mailing lists should be ignored,
> not surrendered/pandered to.

Foolishly surrendering to one leads to surrendering to the others in
turn, as they work to copy gmail's hijack strategy. It is much better to
restore the status quo ante, and let gmail suffer loss of users as a
result of their sabotage of mailing lists.

Erik
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Erik Christiansen via luv-main
On 17.01.16 11:32, Brian May via luv-main wrote:
> Possibly the most productive thing would be if LUV had some sort of
> wiki, and people could write create *proposals* to *fix* the problem
> (not just a complaint that the current sitation is wrong), with
> arguments for and against.

A complete solution, i.e. one not introducing new problems, would have
been to munge headers for gmail recipients only. I.e. solve the problem
where it exists - don't pollute the list aimlessly.

That would also serve to defend an independent community against
internet hegemons - a non-trivial achievement in itself, with long-term
benefits.

I understand that Russel is content with half a solution, and that is
why examination of the residual problems "must cease forthwith - so
there!"

Well, if "nowhere near" is to be "good enough", then so be it.
Just please don't pretend it is any more then half a solution.
I'll just unmunge the headers on receipt, I think, as Craig is doing,
IIRC. Two horrible hacks can make a whole solution, I guess.

Erik
(Going bush for a week, so you can probably tie a knot in this thread
after all. ;)
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Andrew Pam via luv-main
On 16/01/16 21:01, Chris Samuel via luv-main wrote:
> Members have a right to request to see such minutes but the committee has the 
> right to refuse or excise parts for various listed reasons.

Thanks Chris, that's what I thought.

Regards,
Andrew

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-16 Thread Brian May via luv-main
Russell Coker via luv-main  writes:

> On Sat, 16 Jan 2016 09:20:03 PM Erik Christiansen via luv-main wrote:
> You are obviously not reading any messages that I write.  I am not going to 
> explain myself again.
>
> It's time for this discussion to end.

I tend to agree - this discussion seems to be going around in circles.

I think Russell Coker has clearly explained his position, and others
have clearly stated that they are unhappy with this. Continuing this
discussion is unlikely to presuade anybody to change their mind or lead
to any other type of positive outcome.

...unless anybody can provide significant arguments that *have* *not*
already beed made. I think all relevant issues have been raised however.

Possibly the most productive thing would be if LUV had some sort of
wiki, and people could write create *proposals* to *fix* the problem
(not just a complaint that the current sitation is wrong), with
arguments for and against.

Oh wait, maybe we do have a wiki. wiki.luv.asn.au. Seems to be very slow
however, and possibly broken (pages come up empty - not sure if this is
expected or not).
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: SPF/DKIM + DMARC (Was: IPv6)

2016-01-15 Thread Joel W. Shea via luv-main
On Fri, Jan 15, 2016 at 04:21:23PM +1100, Russell Coker wrote:
> 
> Is there an email equivalent to torchat?

I'm not not that parfait with torchat, but it's based on local hidden
services, AFAICT.

So I imagine any email service that only allows connections from tor
(via hidden service), and only between other tor hidden services, would
be the nearest analogue; for which there are many options.


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Russell Coker via luv-main
On Fri, 15 Jan 2016 09:52:35 PM Brian May via luv-main wrote:
> > [...]  If there was a system for encrypting mail between MTAs (like
> > using GPG with DKIM/DMARC type mechanisms for managing keys) then they
> > could display targeted adverts and users get the simplicity of having
> > things just work (GPG is too hard for most people).
> 
> That already exists - SMTP over SSL - while good, it doesn't solve any
> of the problems we are talking about here.

Is there any way to publish the fact that I would prefer to receive mail via 
SSL?

My understanding is that if a hostile party proxies the SMTP session such that 
the sender thinks that my MTA is incapable of SSL then the sender will happily 
send it unencrypted.

Is there any way for a MUA to specify that a message should be bounced if it 
can't be sent between MTAs via SSL?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Russell Coker via luv-main
On Fri, 15 Jan 2016 08:26:13 PM Joel W. Shea via luv-main wrote:
> > Is it possible to put a PGP/GPG public key in the DNS and have an MUA
> > use it?
> 
> Since you've asked; anything is possible[1], and since you're already
> aware of existing mechanisms (key servers) for distributing public
> PGP/GPG keys; I see what you're getting at, the verification of which is
> up to the end-user rather than a independent "trusted" third party, or
> by exhibiting the control of a domain via publishing in the DNS.
> 
> [1] Although it's entirely possible, I'm not aware of any implementation
> and without thinking it through more thoroughly I'm unsure why one would
> want to.

With DKIM/DMARC the receiving MTA can do the checks and ensure that the mail 
is valid.  If we wanted to use GPG/PGP in the same way then there needs to be 
an equivalent key management system.

On Fri, 15 Jan 2016 08:35:48 PM Brian May via luv-main wrote:
> Imagine if the big email providers, such as Google and Yahoo supported
> this sort of technology. They could push for the required client side
> encryption standards for browsers if they really wanted to. Suddenly
> encryption would be available to the masses.
> 
> I don't think this is going to happen however, those flying pigs would
> get in the way.
> 
> Or more seriously, I suspect Google don't want people using client side
> encryption, as this would prevent them scanning emails for advertising.

I don't think that Google and Yahoo have some nefarious plan.  If there was a 
system for encrypting mail between MTAs (like using GPG with DKIM/DMARC type 
mechanisms for managing keys) then they could display targeted adverts and 
users get the simplicity of having things just work (GPG is too hard for most 
people).

But GPG in the MUA is difficult for users and help desks.  I don't use it as 
much as I might because the KDE implementation is annoyingly difficult.  Using 
DKIM on my server is a much easier way of signing all my mail.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Andrew Pam via luv-main
On 15/01/16 20:51, Joel W. Shea via luv-main wrote:
> Are there any minutes taken/published for committee meetings? Are they
> even necessary? Other committee members feel free to chime in here.

Yes, minutes are normally taken by the Secretary and published to the
committee mailing list.

Cheers,
Andrew
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Joel W. Shea via luv-main
On Fri, Jan 15, 2016 at 09:14:09PM +1100, Russell Coker via luv-main
wrote:
> 
> With DKIM/DMARC the receiving MTA can do the checks and ensure that
> the mail is valid.  If we wanted to use GPG/PGP in the same way then
> there needs to be an equivalent key management system.

I think this would be akin to maintaining a keyring for mailing lists,
which isn't actually a bad idea at all.

As for the general case, it's in the too hard basket, as you mentioned
below.

> [...] But GPG in the MUA is difficult for users and help desks. [...]


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: SPF/DKIM + DMARC (Was: IPv6)

2016-01-15 Thread Russell Coker via luv-main
On Sat, 16 Jan 2016 12:08:16 AM Jason White via luv-main wrote:
> That's an interesting observation. On the other side, it isn't hard to set
> up a "reputable" provider. I recently did so by configuring SPF, DKIM and
> DMARC on my mail server.

If you send several messages to the Linux Australia list that aren't replies 
to other messages (IE they will have their subject munged) then you will 
trigger a mass unsubscribe of people who use services like Hotmail and Gmail.  
That's what happened when I did that in January 2015.

> I am nevertheless concerned by the centralization of mail services in the
> hands of large providers, and likewise the rise of large social networking
> sites which merge the features of mail, instant messaging, voice and video
> services, among others - all in a proprietary manner that lacks
> interoperability. Then there's the data mining which takes place to enable
> the social Web site operators to monetize the activities of their users.

I think that the merging is the most serious threat we face.  Gmail is a good 
mail service.  Hangouts is a good IM system which does voice and video in a 
seamless manner.  This combined with the fact that they are setup by default 
on almost every Android device, available from the Apple app store, and much 
of the functionality is available in any web browser makes it a compelling 
service.

Setting up a mail server for yourself that does everything you desire from the 
Gmail feature set isn't trivial for people like us.  IM is hard, ejabberd 
seems to be the best option, it's fragile and doesn't have the features of 
Hangouts and Jabber doesn't have a significant userbase of people who can talk 
to you.  VOIP and video calls is harder still as it requires better net access 
than you can get easily and cheaply in Australia and some significant effort to 
set things up.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Russell Coker via luv-main
On Sat, 16 Jan 2016 02:11:32 AM Craig Sanders via luv-main wrote:
> On Sat, Jan 16, 2016 at 12:31:47PM +1100, Russell Coker wrote:
> > On Sat, 16 Jan 2016 08:36:30 AM Craig Sanders via luv-main wrote:
> > Why are we having an argument about comments then?  If they are just
> > comments then it shouldn't be a big deal.
> 
> because munging them screws up an MUAs ability to reply correctly.

That means that they aren't comments.

> because overwriting the Reply-To: header can make it impossible to reply
> to the original sender.

I'm up for negotiating on that matter.

> because what mailman is doing with DMARC is broken.

It's doing the best it can in a difficult situation.

> > > if mailman is breaking DKIM-signed message then that needs to be fixed.
> > > mangling headers is a crappy workaround hack, not a fix.
> > 
> > Fine,  Tell us how to fix it without mangling headers.
> 
> why me? i'm not the one who wants to change anything. you've changed
> things and caused breakage.
> 
> a better idea would be for you to fix it instead of deciding that mangling
> headers is a reasonable thing to do.

I fixed it, mail is now being delivered reliably.  If you want "comments" to be 
different in email then you can help figure out how to do that without 
compromising mail reliability.

> i.e. you want it, you fix it.

Yes, you do that.
 
> a) i'm not a python programmer

Same here.

> b) i disagree with the concept of DMARC, so i have no desire to implement
> it or fix a particularly broken implementation of it.

I have things working quite well so I have little incentive to change Mailman 
code.

> > OK.  Let's fix that.  I don't have the time or skill to fix Mailman code,
> > could you please do it for me?
> 
> translation: i've enabled a broken feature and rather than revert that
> change, i'll badger someone else to fix the problem for me.  you enabled
> it, it's up to you to either fix it or disable it again.

Translation: You think that Yahoogroups, the Mailman developers and everyone 
else have got it wrong but can't be bothered showing us all how to do it in a 
way that you like.
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Russell Coker via luv-main
On Sat, 16 Jan 2016 05:00:58 PM Craig Sanders via luv-main wrote:
> > > because overwriting the Reply-To: header can make it impossible to
> > > reply to the original sender.
> > 
> > I'm up for negotiating on that matter.
> 
> what's to negotiate? you're either going to fix the damage you caused or
> you're not. i'm not going to beg you to do what. you're the list admin,
> if you insist on breaking the list, there's nothing i can do about it.

If you believed that there was nothing you could do then you wouldn't have 
spent months arguing.

> > > because what mailman is doing with DMARC is broken.
> > 
> > It's doing the best it can in a difficult situation.
> 
> even if you can manage to think of that as being only partly broken,
> partly broken is still broken. it's doing the wrong thing with DMARC.
> that means it's a "feature" that shouldn't be used.

OK, please go tell Yahoo etc that they are doing it wrong.  Let's leave the 
list server in it's current configuration until you convince Yahoo and Gmail of 
the error of their ways.

> > I fixed it, mail is now being delivered reliably.  If you want
> > "comments" to be different in email then you can help figure out how
> > to do that without compromising mail reliability.
> 
> you haven't fixed anything. you've solved one minor problem that
> affected only a handful of people (who inflicted it on themselves
> by using DKIM) at the cost of screwing up the From: and Reply-To:
> headers on all messages forwarded by the list, which affects all
> subscribers.

Actually the Gmail users didn't do anything, they just signed up for a mail 
service knowing nothing about DKIM or the Gmail actions that would happen when 
they received DKIM signed mail via a list.

> > Translation: You think that Yahoogroups, the Mailman developers and
> > everyone else have got it wrong
> 
> the fact that yahoogroups does it is undeniable proof that it's wrong.
> they never get anything right, they've been screwing up mail since the
> 90s.

If they were so wrong then Gmail wouldn't implement DKIM/DMARC checks on mail 
it receives.

> the mailman devs have obviously got it wrong. even they admit that their
> implementation is buggy and broken.

What is buggy is the fact that they can't preserve headers and body encoding.

> > but can't be bothered showing us all how to do it in a way that you
> > like.
> 
> you're assuming that there is such a way.  IMO DMARC is broken-by-design
> so it's impossible to do it in any good or even reasonable way.
> 
> in other words: the way i'd like is to not do it at all. i've said that
> repeatedly.

It's OK to wish that Yahoo, Gmail, Hotmail, Facebook, and other big companies 
would do things differently.  But your wishes aren't going to change anything.  
Let's stick to discussing the reality of how to deal with mail to/from such 
services.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Craig Sanders via luv-main
On Sat, Jan 16, 2016 at 12:31:47PM +1100, Russell Coker wrote:
> On Sat, 16 Jan 2016 08:36:30 AM Craig Sanders via luv-main wrote:
> Why are we having an argument about comments then?  If they are just
> comments then it shouldn't be a big deal.

because munging them screws up an MUAs ability to reply correctly.

because overwriting the Reply-To: header can make it impossible to reply
to the original sender.

because what mailman is doing with DMARC is broken.

> Stupidity is a problem.  But what we want to do here is to make it possible 
> for people who aren't particularly stupid to work this out without much 
> effort.

they can. It's not hard:  

1. Don't click on links in email.  

2. Don't trust that the message actually came from whoever it claims to
have come from unless it's signed and/or encrypted with a key you (your
system) knows, and even then be wary (keys can't protect you when the
sender is coerced to give up their private key)

that's it.  the rest is implementation details of those two things.

> They could have designed encryption and signing features from the start and 
> methods for recognising new senders.

those things are MUA functions (i.e. message payload), not MTA - i.e.
irrelevant to the SMTP protocol.


> > > Apart from the ones who receive mail viw Gmail, the ones who
> > > complained about my mail going to their spam folders which started me
> > > working on this.
> > 
> > if mailman is breaking DKIM-signed message then that needs to be fixed.
> > mangling headers is a crappy workaround hack, not a fix.
> 
> Fine,  Tell us how to fix it without mangling headers.

why me? i'm not the one who wants to change anything. you've changed
things and caused breakage.

a better idea would be for you to fix it instead of deciding that mangling
headers is a reasonable thing to do.

i.e. you want it, you fix it.

also:

a) i'm not a python programmer

b) i disagree with the concept of DMARC, so i have no desire to implement it or
fix a particularly broken implementation of it.


> > as i said, solve the right (actual!) problem. if mailman's handling of
> > DKIM-signed messages is broken then THAT is the problem that needs to be
> > fixed.
> 
> OK.  Let's fix that.  I don't have the time or skill to fix Mailman code, 
> could 
> you please do it for me?

translation: i've enabled a broken feature and rather than revert that change, 
i'll 
badger someone else to fix the problem for me.  you enabled it, it's up to you 
to
either fix it or disable it again.

craig

-- 
craig sanders 
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Joel W. Shea via luv-main
On Fri, Jan 15, 2016 at 07:01:30PM +1100, Russell Coker via luv-main wrote:
> On Fri, 15 Jan 2016 04:54:22 PM Craig Sanders via luv-main wrote:
> 
> I don't like the idea of having different handling methods for
> different messages.  We have already had one user complain about this
> even though we aren't doing it!

Technically, you are ... by munging the from field on all messages.

To wit, the difference in handling becomes very obvious when only
receiving the message directly, presumably because the recipient address
is also in the "To:" or the "Cc:" field and the list then may (or may
not) send a duplicate, exhibiting the different handling method.

> [...] Apart from the ones who receive mail viw Gmail, the ones who
> complained about my mail going to their spam folders which started me
> working on this.

Since Mailman was breaking the signature by re-folding the headers, this
could have been resolved in one of many ways; including signing with a
relaxed header canonicalization, or by having the list server strip the
DKIM signature entirely (having been verified by the MTA already).

There may (or may not) have been discussion amongst the committee
members about possible modifications to the list, but there doesn't
appear to be any transparency regarding this, and there certainly wasn't
any requests for consultation (commentary/suggestions) from ordinary
list members *before* making a seemingly unilateral change.


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: SPF/DKIM + DMARC (Was: IPv6)

2016-01-15 Thread Brian May via luv-main
Russell Coker via luv-main  writes:

> Not at all.  The distributed and decentralised part of email is inherently 
> not 
> mailing lists.  By definition lists are centralised!

nntp was suppose to be the distrbuted solution for mailing lists. Shame
it didn't work out. Mailing lists have won, but the RFC822 headers
weren't intended for mailing lists.
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Joel W. Shea via luv-main
On Fri, Jan 15, 2016 at 07:45:30PM +1100, Russell Coker via luv-main wrote:
> On Fri, 15 Jan 2016 06:54:22 PM Joel W. Shea via luv-main wrote:
> > Agreed, PGP/GPG and S/MIME solved this long ago, with the added
> > benefit of end-to-end encryption.
> 
> Is it possible to put a PGP/GPG public key in the DNS and have an MUA
> use it?

Since you've asked; anything is possible[1], and since you're already
aware of existing mechanisms (key servers) for distributing public
PGP/GPG keys; I see what you're getting at, the verification of which is
up to the end-user rather than a independent "trusted" third party, or
by exhibiting the control of a domain via publishing in the DNS.

[1] Although it's entirely possible, I'm not aware of any implementation
and without thinking it through more thoroughly I'm unsure why one would
want to.


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Russell Coker via luv-main
On Fri, 15 Jan 2016 08:09:29 PM Joel W. Shea via luv-main wrote:
> > I don't like the idea of having different handling methods for
> > different messages.  We have already had one user complain about this
> > even though we aren't doing it!
> 
> Technically, you are ... by munging the from field on all messages.
> 
> To wit, the difference in handling becomes very obvious when only
> receiving the message directly, presumably because the recipient address
> is also in the "To:" or the "Cc:" field and the list then may (or may
> not) send a duplicate, exhibiting the different handling method.

It is true that when someone receives 2 copies of the message (from the list 
and from a CC) they get 2 different versions.

I'm not totally opposed to using the DMARC setting.

> > [...] Apart from the ones who receive mail viw Gmail, the ones who
> > complained about my mail going to their spam folders which started me
> > working on this.
> 
> Since Mailman was breaking the signature by re-folding the headers, this
> could have been resolved in one of many ways; including signing with a
> relaxed header canonicalization, or by having the list server strip the
> DKIM signature entirely (having been verified by the MTA already).

Mailman is also reencoding my messages as base64 for some reason.  It's not 
doing it for everyone and other instances of Mailman don't so we can probably 
solve it.

But this still won't solve the issues with DMARC.

> There may (or may not) have been discussion amongst the committee
> members about possible modifications to the list, but there doesn't
> appear to be any transparency regarding this, and there certainly wasn't
> any requests for consultation (commentary/suggestions) from ordinary
> list members *before* making a seemingly unilateral change.

There wasn't a discussion because no-one on the committee felt the need for a 
discussion.  I suggested that we have one but it seems that no-one had any 
problems with it.  I enabled it on the committee list before luv-talk and 
everyone there seemed happy.

For comparison the committee discussion about moving the LUV server (probably 
the most important issue the committee has discussed in the past year or so) 
was held on Google Hangouts and we only got 5/9 in attendance.

The history of LUV shows that asking for commentary from members before making 
a change is something you only do if you don't want to make a change.  It took 
us years to get public archives for the LUV lists with many discussions like 
this along the way.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: SPF/DKIM + DMARC (Was: IPv6)

2016-01-15 Thread Joel W. Shea via luv-main
On Fri, Jan 15, 2016 at 08:18:56PM +1100, Brian May via luv-main wrote:
> 
> nntp was suppose to be the distrbuted solution for mailing lists.

Excellent point!

> Shame it didn't work out. Mailing lists have won, but the RFC822
> headers weren't intended for mailing lists.

Indeed, and both were replaced by web forums in many instances. I guess
there's no accounting for taste, eh?


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Brian May via luv-main
"Joel W. Shea via luv-main"  writes:

> Agreed, PGP/GPG and S/MIME solved this long ago, with the added benefit
> of end-to-end encryption.

Imagine if the big email providers, such as Google and Yahoo supported
this sort of technology. They could push for the required client side
encryption standards for browsers if they really wanted to. Suddenly
encryption would be available to the masses.

I don't think this is going to happen however, those flying pigs would
get in the way.

Or more seriously, I suspect Google don't want people using client side
encryption, as this would prevent them scanning emails for advertising.
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Brian May via luv-main
Russell Coker via luv-main  writes:

> On Fri, 15 Jan 2016 06:54:22 PM Joel W. Shea via luv-main wrote:
>> Agreed, PGP/GPG and S/MIME solved this long ago, with the added benefit
>> of end-to-end encryption.
>
> Is it possible to put a PGP/GPG public key in the DNS and have an MUA use it?

Top google search for "GPG DNS" gives me this

http://www.gushi.org/make-dns-cert/HOWTO.html

Suspect nothing has been implemented in MUAs however. Also the date on
that page is 2010...
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Joel W. Shea via luv-main
On Fri, Jan 15, 2016 at 08:34:35PM +1100, Russell Coker wrote:
> 
> Mailman is also reencoding my messages as base64 for some reason.
> It's not doing it for everyone and other instances of Mailman don't so
> we can probably solve it.

I vaguely recall something in the DKIM spec where a certain setting
requires base64 encoding, but I don't remember what that was.

> But this still won't solve the issues with DMARC.

Probably not :-(


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-15 Thread Joel W. Shea via luv-main
On Fri, Jan 15, 2016 at 08:34:35PM +1100, Russell Coker wrote:
> On Fri, 15 Jan 2016 08:09:29 PM Joel W. Shea via luv-main wrote:
> > There may (or may not) have been discussion amongst the committee
> > [...]
> 
> There wasn't a discussion because no-one on the committee felt the
> need for a discussion.  I suggested that we have one but it seems that
> no-one had any problems with it.  I enabled it on the committee list
> before luv-talk and everyone there seemed happy.

I guess that works in-lieu of a discussion. Thanks for the explaination,
I appreciate that.

> For comparison the committee discussion about moving the LUV server
> (probably the most important issue the committee has discussed in the
> past year or so) was held on Google Hangouts and we only got 5/9 in
> attendance.

Are there any minutes taken/published for committee meetings? Are they
even necessary? Other committee members feel free to chime in here.

> The history of LUV shows that asking for commentary from members
> before making a change is something you only do if you don't want to
> make a change.

Ha ha, fair enough, I can sympathise with that :-)

> It took us years to get public archives for the LUV lists with many
> discussions like this along the way.

Your memory on that issue is obviously much better than mine, thanks for
the context.


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: Inconsistent list behaviour (was: IPv6)

2016-01-14 Thread Russell Coker via luv-main
On Thu, 14 Jan 2016 02:46:03 AM Tony Langdon via luv-main wrote:
> I am not bothered by the changing From: line, but the messages with the
> From: line preserved here, also don't allow me to use Reply List, which
> is the annoying part. The only saving grace is the button is in the same
> place, but then having to clean up the To: addresses (and I've just
> deleted the wrong one, so gotta screw around more. :/ )

I'm CCing you so you will receive 2 copies of this message.  The one that has 
"via luv-main" will support reply to list and the one that goes directly 
won't.  Best to not "clean up" the addresses.
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-14 Thread Russell Coker via luv-main
On Wed, 13 Jan 2016 08:42:23 PM Erik Christiansen via luv-main wrote:
> > I got it wrong, was actually referring to From:  address munging.
> 
> Nah, I wouldn't hold my breath. Hints on that one have been going to
> /dev/null since last year. It seems we're all supposed to undo the crap
> individually at our ends.

We had a problem of Gmail and other recipients falsely regarding mail from the 
LUV server as forged and assigning it to the spam folder.

We are dealing with a couple of bugs in Mailman, what I consider to be a 
deficiency in OpenDKIM and some interactions between SPF and DMARC.

If you would like to help with some of these technical issues then go for it.

http://postmaster.facebook.com/reputation_and_authentication

Facebook is now compelling sysadmins to use SPF or DKIM.  This isn't going to 
go away.  It's only a matter of time before Internode starts using DKIM to 
placate Facebook.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-14 Thread Jason White via luv-main
Russell Coker via luv-main  wrote:
> On Fri, 15 Jan 2016 09:52:30 AM Tony Langdon via luv-main wrote:
> > > Facebook is now compelling sysadmins to use SPF or DKIM.  This isn't
> > > going to go away.  It's only a matter of time before Internode starts
> > > using DKIM to placate Facebook.
> > 
> > Looks like it's a case of having to follow suit., like it or not.
> 

I predict that mailing lists, and mail behaviour in general, will simply need
to adapt to SPF, DKIM and DMARC as the emerging means of establishing the
authenticity of messages with a certain degree of assurance. What this means
is that (provided the sending MTA only serves authorized users) there is
reasonable assurance that the sender identified in the "From" header is the
actual sender, and that certain header fields and the body have not been
modified in transit.

> Yes.  I'd appreciate it if people would stop acting like I'm doing something 
> I 
> want to do here.  I just want mail to go through reliably and I'm doing what 
> is necessary to achieve that goal.


Widespread use of DMARC will result in changes to well established
conventions. I don't personally object to having the list server rewrite the
"From" field and add a "Reply-to" header that designates the original sender;
but some people have needs which differ from mine, and for them it can be an
inconvenience.

If I were running a mailing list server, however, I would make it compatible
with DMARC "reject" policies.

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-14 Thread Tony Langdon via luv-main
On 15/01/2016 12:14 AM, Russell Coker via luv-main wrote:
> On Wed, 13 Jan 2016 08:42:23 PM Erik Christiansen via luv-main wrote:
>>> I got it wrong, was actually referring to From:  address munging.
>>
>> Nah, I wouldn't hold my breath. Hints on that one have been going to
>> /dev/null since last year. It seems we're all supposed to undo the crap
>> individually at our ends.
> 
> We had a problem of Gmail and other recipients falsely regarding mail from 
> the 
> LUV server as forged and assigning it to the spam folder.

Nothing that can't be fixed with a filter (use the "Never send it to
spam" option in the Gmail filter for LUV list mail).
> 
> We are dealing with a couple of bugs in Mailman, what I consider to be a 
> deficiency in OpenDKIM and some interactions between SPF and DMARC.
> 
> If you would like to help with some of these technical issues then go for it.
> 
> http://postmaster.facebook.com/reputation_and_authentication
> 
> Facebook is now compelling sysadmins to use SPF or DKIM.  This isn't going to 
> go away.  It's only a matter of time before Internode starts using DKIM to 
> placate Facebook.
> 
Looks like it's a case of having to follow suit., like it or not.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


DMARC moderation (Was: IPv6)

2016-01-14 Thread Joel W. Shea via luv-main
On Thu, Jan 14, 2016 at 01:26:42AM +, Russell Coker via luv-main wrote:
> 
> [...] the dmarc_moderation_action action that Joel requests gives
> different behavior for everyone using DKIM (even those not using
> DMARC) to those who don't. [...]

I can't reproduce that behaviour, according to my testing, it only takes
action on messages with a "From:" field that contain a domain with a
DMARC policy published, even if they are DKIM signed.

I could understand if it was inadvertently acting where DMARC "p=none",
but that would also be a bug.


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: SPF/DKIM + DMARC (Was: IPv6)

2016-01-14 Thread Joel W. Shea via luv-main
On Fri, Jan 15, 2016 at 04:30:47AM +, Russell Coker wrote:
> 
> Not at all.  The distributed and decentralised part of email is
> inherently not mailing lists.  By definition lists are centralised!

By that logic, either are mailbox providers, as they are also
centralised

> No it just means that you have to use other services.

Yes, a "reputable" one, as defined by what ever criteria some few large
corporations dictate.

> [...]

Which would still fail if corporations suddenly started dictating that
you must have a DMARC policy for your mail to be accepted.

> As for censorship, if you are worried about that then you probably
> shouldn't be using Gmail at all.

Agreed, we should all run our own mail services. Or at least, select
those with sane policies if we want to be uncensored.

> The real issue is that nothing we agree on matters much if Google and
> Yahoo don't agree.

Also agreed, pretty much what I was inferring with the hyperbole about
Internet nuetrality.


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: SPF/DKIM + DMARC (Was: IPv6)

2016-01-14 Thread Russell Coker via luv-main
On Fri, 15 Jan 2016 03:56:38 PM Joel W. Shea wrote:
> On Fri, Jan 15, 2016 at 04:30:47AM +, Russell Coker wrote:
> > Not at all.  The distributed and decentralised part of email is
> > inherently not mailing lists.  By definition lists are centralised!
> 
> By that logic, either are mailbox providers, as they are also
> centralised

They are only centralised to the extent that you have to use them.  For 
typical computer users it's very centralised.  For typical members of this 
list running their own mail server is an option.

Is there an email equivalent to torchat?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: SPF/DKIM + DMARC (Was: IPv6)

2016-01-14 Thread Craig Sanders via luv-main
On Fri, Jan 15, 2016 at 05:03:39PM +1100, Craig Sanders wrote:
> being able to run mailing lists is an essential part of the open
> internet and *IS* de-centralised.  At least until the corporates
> manage to kill off any alternatives to their spyware services via
> DKIM.

sorry. i've typed DKIM here and in other places, but meant DMARC.

craig

-- 
craig sanders 
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: SPF/DKIM + DMARC (Was: IPv6)

2016-01-14 Thread Russell Coker via luv-main
On Fri, 15 Jan 2016 04:01:28 AM Joel W. Shea via luv-main wrote:
> > Widespread use of DMARC will result in changes to well established
> > conventions. I don't personally object to having the list server
> > rewrite the "From" field and add a "Reply-to" header that designates
> > the original sender; but some people have needs which differ from
> > mine, and for them it can be an inconvenience.
> 
> Yes, it also has the potential to reduce the distributed and
> decentralised nature of email;

Not at all.  The distributed and decentralised part of email is inherently not 
mailing lists.  By definition lists are centralised!

> I.e. if you're not sending via a "reputable" service provider, your mail
> wont get routed. This is antithetical to an open Internet, Internet
> neutrality, and it could also be considered a means of censorship by
> some.

No it just means that you have to use other services.

If you and a bunch of like minded people wanted to have a list where no-one 
used DKIM/DMARC then there's nothing stopping you from doing it.

As for censorship, if you are worried about that then you probably shouldn't 
be using Gmail at all.

> I believe this has also been suggested by others in the past, but went
> nowhere; along with the concept of an "X-Original-Authentication-Result"
> header, although those could be easily forged, and we're back to the
> subjectivity of trust problem.

The real issue is that nothing we agree on matters much if Google and Yahoo 
don't agree.
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-14 Thread Craig Sanders via luv-main
On Thu, Jan 14, 2016 at 08:56:52PM -0500, Jason White wrote:
> Russell Coker via luv-main  wrote:
> > On Fri, 15 Jan 2016 09:52:30 AM Tony Langdon via luv-main wrote:
> > > > Facebook is now compelling sysadmins to use SPF or DKIM.  This isn't
> > > > going to go away.  It's only a matter of time before Internode starts
> > > > using DKIM to placate Facebook.
> > > 
> > > Looks like it's a case of having to follow suit., like it or not.

well, SPF is fine.  no problem with that.

DKIM is an ill-conceived abomination.  It actually cares about the
*headers* in a message rather than the **envelope*.  To an MTA, headers
are irrelevant, they're just commentswhat matters is the envelope
sender address and the envelope recipient address.

And worse, DKIM cares about the From: header rather than the Sender:
header.

This is just broken in every possible way.

> > Yes.  I'd appreciate it if people would stop acting like I'm doing
> > something I want to do here.  I just want mail to go through
> > reliably and I'm doing what is necessary to achieve that goal.

unfortunately, you stil haven't impleemnted the minimum-damage option
that only munges posts that are sent by users from domains that
implement DKIM (like google or yahoo), and leaves other mail alone.

it's not like anyone ever posts from those domains to our lists anyway.

which is one of the more annoying things about this issue - the
configuration messes things up for active participants on the list, and
it doesn't even provide any benefit to the lurkers who never say or
contribute anything.

That's entirely the wrong thing to do. those who contribute may well
stop bothering if they get annoyed enough, and non-contributors won't
step forward to replace them...if they were inclined to, they'd already
be posting.

driving away those who write the posts (that both they and the lurkers
read) is self-defeating.

> Widespread use of DMARC will result in changes to well established
> conventions.

IMO it's an attempt by major corporate players to completely take over
email so that no email is ever sent that they don't get a copy of to
examine and index and use to build up profiles on individuals.

and to sell to the NSA etc of course.

Message forgery is a solved problem.  SPF works.  DKIM is a) overkill
and b) unnecesary.

If individual senders need more identity verification than SPF, there
are numerous encryption and signing options availablewith support
built in to many MUAs.



> I don't personally object to having the list server rewrite the "From"
> field and add a "Reply-to" header that designates the original sender;
> but some people have needs which differ from mine, and for them it can
> be an inconvenience.

NO!

those who refuse to learn from history are doomed to repeat the same
damned stupid mistakes.  This issue was settled definitively in the 90s.

Mailing lists should *never*, under any circumstances, mess with the
Reply-To header.  That belongs solely to the original sender.

Lists have several alternatives they can use, including Mail-Followup-To:
and List-Post:

and Lists shouldn't mess with the From: header, either.  No matter what
corporate vermin demand.  WGAF what facebook wants?  how many emails
from luv lists ever go to facebook?

craig

-- 
craig sanders 
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: SPF/DKIM + DMARC (Was: IPv6)

2016-01-14 Thread Craig Sanders via luv-main
On Fri, Jan 15, 2016 at 04:30:47AM +, Russell Coker wrote:
> On Fri, 15 Jan 2016 04:01:28 AM Joel W. Shea via luv-main wrote:
> > Yes, it also has the potential to reduce the distributed and
> > decentralised nature of email;
> 
> Not at all.  The distributed and decentralised part of email is
> inherently not mailing lists.  By definition lists are centralised!

yeah. and sucks to be us if we want to run our own lists and not google
or yahoo or msn shite.

being able to run mailing lists is an essential part of the open internet
and *IS* de-centralised.  At least until the corporates manage to kill off
any alternatives to their spyware services via DKIM.

> The real issue is that nothing we agree on matters much if Google and
> Yahoo don't agree.

To the contrary, nothing that google or yahoo demand matters if we just
ignore them.

Neither of them are necessary to the function of our list. If they want
to do a dis-service to their users by rejecting mail from legitimate
lists, that's a problem for them and their users, not a problem for us.

if mail from the list sent to gmail etc bounces because of their
misconfiguration, the correct response is to think "shit happens.
this is nothing new, there's always been idiot mail admins at large
corporations" and ignore it, not jump through their hoops that are
designed to let them gain complete control over all email on the net.

craig

-- 
craig sanders 
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-14 Thread Joel W. Shea via luv-main
On Fri, Jan 15, 2016 at 04:54:22PM +1100, Craig Sanders via luv-main wrote:
> On Thu, Jan 14, 2016 at 08:56:52PM -0500, Jason White wrote:
> > Russell Coker via luv-main  wrote:
> 
> [...] And worse, DKIM cares about the From: header rather than the
> Sender: header.

I'm assuming this was one of those places where you meant DMARC, because
DKIM only cares about what you tell it to sign (or not, for that matter)

> This is just broken in every possible way.
> 
> > > Yes.  I'd appreciate it if people would stop acting like I'm doing
> > > something I want to do here.  I just want mail to go through
> > > reliably and I'm doing what is necessary to achieve that goal.
>
> [...] That's entirely the wrong thing to do. those who contribute may
> well stop bothering if they get annoyed enough, [...] driving away
> those who write the posts (that both they and the lurkers read) is
> self-defeating.

Conversely, it's actually caused me to contribute more than usual, merely
to express said annoyance, I'm not sure I want to burn any more calories
bothering in future, and have certainly considered unsubscribing.

> > Widespread use of DMARC will result in changes to well established
> > conventions.
> 
> IMO it's an attempt by major corporate players to completely take over
> email so that no email is ever sent that they don't get a copy of to
> examine and index and use to build up profiles on individuals.

If we're being generous, it's probably just a pleasant side affect.
However, I'm yet to see many 

> and to sell to the NSA etc of course.
> 
> Message forgery is a solved problem.  SPF works.  DKIM is a) overkill
> and b) unnecesary.
> 
> If individual senders need more identity verification than SPF, there
> are numerous encryption and signing options availablewith support
> built in to many MUAs.

Agreed, PGP/GPG and S/MIME solved this long ago, with the added benefit
of end-to-end encryption.

> [...] those who refuse to learn from history are doomed to repeat the
> same damned stupid mistakes.  This issue was settled definitively in
> the 90s.

Well said.

> [...] 


signature.asc
Description: PGP signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-13 Thread Erik Christiansen via luv-main
On 13.01.16 20:09, Tony Langdon via luv-main wrote:
> On 13/01/2016 10:31 AM, Brian May wrote:
> > Tony Langdon via luv-main  writes:
> > 
> >> On closer observation, it started with the message from you that I
> >> replied to, and it's only you.  Another coincidence is that the Subject:
> >> header hasn't been munged in this thread, yet everyone else's posts
> >> still have the Subject: munging.
> > 
> > I don't see any subject munging for any posts on luv-main.
> 
> I got it wrong, was actually referring to From:  address munging.

Nah, I wouldn't hold my breath. Hints on that one have been going to
/dev/null since last year. It seems we're all supposed to undo the crap
individually at our ends.

Erik
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-13 Thread Tony Langdon via luv-main
On 13/01/2016 10:31 AM, Brian May wrote:
> Tony Langdon via luv-main  writes:
> 
>> On closer observation, it started with the message from you that I
>> replied to, and it's only you.  Another coincidence is that the Subject:
>> header hasn't been munged in this thread, yet everyone else's posts
>> still have the Subject: munging.
> 
> I don't see any subject munging for any posts on luv-main.

I got it wrong, was actually referring to From:  address munging.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-13 Thread Jason White via luv-main
Brian May via luv-main  wrote:
 
> Seems to work for me. Is very slow to respond however. 10 seconds just
> to get the HTML page, 


No such delays from here (central Princeton over a cable connection).

ping6 shows
rtt min/avg/max/mdev = 115.398/119.020/125.329/3.533 ms

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-13 Thread Tony Langdon via luv-main
On 13/01/2016 8:42 PM, Erik Christiansen via luv-main wrote:
> On 13.01.16 20:09, Tony Langdon via luv-main wrote:
>> On 13/01/2016 10:31 AM, Brian May wrote:
>>> Tony Langdon via luv-main  writes:
>>>
 On closer observation, it started with the message from you that I
 replied to, and it's only you.  Another coincidence is that the Subject:
 header hasn't been munged in this thread, yet everyone else's posts
 still have the Subject: munging.
>>>
>>> I don't see any subject munging for any posts on luv-main.
>>
>> I got it wrong, was actually referring to From:  address munging.
> 
> Nah, I wouldn't hold my breath. Hints on that one have been going to
> /dev/null since last year. It seems we're all supposed to undo the crap
> individually at our ends.

I'm just mystified as to why the thread that Russell's message started
is not being From: munged, whereas all else is.  Though your message is
munged, and Reply List is working perfectly.

It wasn't so much the From: munging that was bothering me, but the
inconsistent reply behaviour (I dislike Reply All, because of the extra
emails it generates, much prefer Reply List).

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-13 Thread Brian May via luv-main
Tony Langdon via luv-main  writes:

> I'm just mystified as to why the thread that Russell's message started
> is not being From: munged, whereas all else is.  Though your message is
> munged, and Reply List is working perfectly.

Are you sure you are not getting confused with emails (like this) that
are being CCed to you?

You might be looking at the email that was sent directly to you without
going via the mailing list.
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-13 Thread Russell Coker via luv-main
On Wed, 13 Jan 2016 10:20:06 PM Tony Langdon via luv-main wrote:
> It wasn't so much the From: munging that was bothering me, but the
> inconsistent reply behaviour (I dislike Reply All, because of the extra
> emails it generates, much prefer Reply List).

Tony, the dmarc_moderation_action action that Joel requests gives different 
behavior for everyone using DKIM (even those not using DMARC) to those who 
don't.  If that was used as Joel requested then mail from me, Lev, everyone 
who uses Gmail, and others would go as it does now and mail from everyone else 
would have the From: line preserved.

I agree that consistent behavior is a good thing.

On Wed, 23 Dec 2015 10:56:06 AM Joel W. Shea via luv-main wrote:
> Could you please disable from_as_list? As dmarc_moderation_action would
> suffice.
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-13 Thread Tony Langdon via luv-main
On 14/01/2016 9:34 AM, Brian May wrote:
> Tony Langdon via luv-main  writes:
> 
>> I'm just mystified as to why the thread that Russell's message started
>> is not being From: munged, whereas all else is.  Though your message is
>> munged, and Reply List is working perfectly.
> 
> Are you sure you are not getting confused with emails (like this) that
> are being CCed to you?
> 
> You might be looking at the email that was sent directly to you without
> going via the mailing list.
> 

They're still being filtered into my LUV-Main folder.  I'm going to have
to check my filter settings for the list.


-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Inconsistent list behaviour (was: IPv6)

2016-01-13 Thread Tony Langdon via luv-main
On 14/01/2016 12:26 PM, Russell Coker wrote:
> On Wed, 13 Jan 2016 10:20:06 PM Tony Langdon via luv-main wrote:
>> It wasn't so much the From: munging that was bothering me, but the
>> inconsistent reply behaviour (I dislike Reply All, because of the extra
>> emails it generates, much prefer Reply List).
>
> Tony, the dmarc_moderation_action action that Joel requests gives
different
> behavior for everyone using DKIM (even those not using DMARC) to those
who
> don't.  If that was used as Joel requested then mail from me, Lev,
everyone
> who uses Gmail, and others would go as it does now and mail from
everyone else
> would have the From: line preserved.
>
> I agree that consistent behavior is a good thing.

I am not bothered by the changing From: line, but the messages with the
From: line preserved here, also don't allow me to use Reply List, which
is the annoying part. The only saving grace is the button is in the same
place, but then having to clean up the To: addresses (and I've just
deleted the wrong one, so gotta screw around more. :/ )

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-12 Thread Brian May via luv-main
Russell Coker  writes:

> I don't know about paypalobjects or even why we are using it (might be an 
> issue for Lev who's doing the Drupal stuff).

Suspect it might something to do with the Donate button.

> It should be better now as I've finished disk intensive stuff for the moment. 
>  
> Also as I've optimised the MySQL database all files that are used in normal 
> operation will now fit into RAM.  So once the system has been running for a 
> while almost everything will come from cache and performance should be good.  
> But when there's disk IO shortly after boot performance will be bad.

It takes 2.77 seconds to load the HTML page (7KB) now. Which isn't
great, but a lot better then it was before.

Or about 7 seconds to load the page with all the resources (excluding
the paypal one which wont load).

Should have tested before the move for the numbers to mean something :-)
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-12 Thread Russell Coker via luv-main
On Tue, 12 Jan 2016 09:39:42 PM Tony Langdon wrote:
> On 12/01/2016 3:53 PM, Russell Coker wrote:
> > On Tue, 12 Jan 2016 03:25:49 PM Tony Langdon via luv-main wrote:
> >> Browsing to luv.asn.au gets an empty directory. I'm running native IPv6
> >> here, and IPv6 is the preferred protocol.
> > 
> > I think I've fixed that problem.  Please test it again for me.
> 
> Yep works now.  Now, what's up with the list?  I no longer have a Reply
> List button. Something screwed with the headers?

I made no changes to the list configuration.  Please compare messages from the 
list a few days ago with ones from today, you shouldn't notice any difference.  
Note I say "shouldn't" because it's sometimes difficult to know all the 
implications of regular Debian package updates (which are supposed not to 
break anything because they are only security fixes etc but sometimes do).

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-12 Thread Erik Christiansen via luv-main
On 12.01.16 21:54, Russell Coker via luv-main wrote:
> On Tue, 12 Jan 2016 09:39:42 PM Tony Langdon wrote:
> > Yep works now.  Now, what's up with the list?  I no longer have a Reply
> > List button. Something screwed with the headers?
> 
> I made no changes to the list configuration.  Please compare messages from 
> the 
> list a few days ago with ones from today, you shouldn't notice any 
> difference.  
> Note I say "shouldn't" because it's sometimes difficult to know all the 
> implications of regular Debian package updates (which are supposed not to 
> break anything because they are only security fixes etc but sometimes do).

A datapoint: In mutt, 'L' still replies to list, as before.
The List-ID and List-Post headers are still there. I'm not sure which
one mutt's using, but I don't even have a "subscribe luv-main@luv.asn.au"
in .muttrc; it's figuring it out with no hints.

Now let's see if the thread is highlighted now that I've posted to it -
i.e. has the "From" munge been fixed.

Erik
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-12 Thread Tony Langdon via luv-main
On 12/01/2016 3:53 PM, Russell Coker wrote:
> On Tue, 12 Jan 2016 03:25:49 PM Tony Langdon via luv-main wrote:
>> Browsing to luv.asn.au gets an empty directory. I'm running native IPv6
>> here, and IPv6 is the preferred protocol.
> 
> I think I've fixed that problem.  Please test it again for me.
> 

Yep works now.  Now, what's up with the list?  I no longer have a Reply
List button. Something screwed with the headers?


-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-12 Thread Tony Langdon via luv-main
On 12/01/2016 9:54 PM, Russell Coker wrote:
> On Tue, 12 Jan 2016 09:39:42 PM Tony Langdon wrote:
>> On 12/01/2016 3:53 PM, Russell Coker wrote:
>>> On Tue, 12 Jan 2016 03:25:49 PM Tony Langdon via luv-main wrote:
>>>> Browsing to luv.asn.au gets an empty directory. I'm running native IPv6
>>>> here, and IPv6 is the preferred protocol.
>>>
>>> I think I've fixed that problem.  Please test it again for me.
>>
>> Yep works now.  Now, what's up with the list?  I no longer have a Reply
>> List button. Something screwed with the headers?
> 
> I made no changes to the list configuration.  Please compare messages from 
> the 
> list a few days ago with ones from today, you shouldn't notice any 
> difference.  
> Note I say "shouldn't" because it's sometimes difficult to know all the 
> implications of regular Debian package updates (which are supposed not to 
> break anything because they are only security fixes etc but sometimes do).
> 

On closer observation, it started with the message from you that I
replied to, and it's only you.  Another coincidence is that the Subject:
header hasn't been munged in this thread, yet everyone else's posts
still have the Subject: munging.

You're doing something funky with procmail in the last day or so, by any
chance?

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-12 Thread Brian May via luv-main
Tony Langdon via luv-main  writes:

> On closer observation, it started with the message from you that I
> replied to, and it's only you.  Another coincidence is that the Subject:
> header hasn't been munged in this thread, yet everyone else's posts
> still have the Subject: munging.

I don't see any subject munging for any posts on luv-main.

Maybe you are confused with luv-talk, which does appear to prefix
subject lines wiht '[luv-talk]'?
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


IPv6 at beginners' SIG

2016-01-11 Thread Russell Coker via luv-main
Is there any interest in an IPv6 training session at the beginners' SIG?

I'm not volunteering to run it as I don't consider myself an expert on it (and 
I'm doing lots of other things).  But I can help out, the LUV server isn't the 
first server I've setup for IPv6.

Tony would you like to run such a session if there's interest?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-11 Thread Russell Coker via luv-main
On Tue, 12 Jan 2016 03:25:49 PM Tony Langdon via luv-main wrote:
> Browsing to luv.asn.au gets an empty directory. I'm running native IPv6
> here, and IPv6 is the preferred protocol.

I think I've fixed that problem.  Please test it again for me.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


IPv6

2016-01-11 Thread Russell Coker via luv-main
I have enabled IPv6 on the LUV server.  I would appreciate it if anyone who is 
interested could test it out.  Just do basic stuff like force your web browser 
to IPv6 and visit the web site or force your MTA to IPv6 and send mail to the 
list.

Andrew please add 2a01:4f8:100:7463::9 to the glue record for itmustbe, then 
IPv6-only recursive DNS servers (if they happen to exist) can successfully 
query the LUV server.

If your MTA has IPv6 enabled but broken (which is probably more common than 
having IPv6 enabled and working correctly) then this may make it impossible 
for you to participate in the LUV lists.

This change is probably going to cause some pain for some people (mostly me).  
But it's something that we need to do.  The world needs to move to IPv6 and as 
an IT organisation operating in the public interest LUV should be in the lead.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-11 Thread Brian May via luv-main
Russell Coker via luv-main <luv-main@luv.asn.au> writes:

> On Tue, 12 Jan 2016 03:25:49 PM Tony Langdon via luv-main wrote:
>> Browsing to luv.asn.au gets an empty directory. I'm running native IPv6
>> here, and IPv6 is the preferred protocol.
>
> I think I've fixed that problem.  Please test it again for me.

Seems to work for me. Is very slow to respond however. 10 seconds just
to get the HTML page, now trying to load pixel.gif from
paypalobjects.com which is taking ages.

I don't have any time to debug right now, will investigate more when I
get a chance.
-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-11 Thread Russell Coker via luv-main
On Tue, 12 Jan 2016 04:07:32 PM Brian May via luv-main wrote:
> Seems to work for me. Is very slow to respond however. 10 seconds just
> to get the HTML page, now trying to load pixel.gif from
> paypalobjects.com which is taking ages.

I don't know about paypalobjects or even why we are using it (might be an 
issue for Lev who's doing the Drupal stuff).  But as for the speed of the main 
server, it used to run on a pair of 15000rpm SAS disks that were dedicated to 
LUV.  Now it's running on a pair of 750G SATA disks that date back to when 
750G was a big disk - and sharing those with other VMs.  This combined with 
the fact that I've been copying files around to migrate to BTRFS has given poor 
performance this afternoon.

It should be better now as I've finished disk intensive stuff for the moment.  
Also as I've optimised the MySQL database all files that are used in normal 
operation will now fit into RAM.  So once the system has been running for a 
while almost everything will come from cache and performance should be good.  
But when there's disk IO shortly after boot performance will be bad.

The new server has significantly more CPU power which should help performance 
when things are going well.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6

2016-01-11 Thread Tony Langdon via luv-main
On 12/01/2016 3:11 PM, Russell Coker via luv-main wrote:
> I have enabled IPv6 on the LUV server.  I would appreciate it if anyone who 
> is 
> interested could test it out.  Just do basic stuff like force your web 
> browser 
> to IPv6 and visit the web site or force your MTA to IPv6 and send mail to the 
> list.

root@vk3irl:~# ping6 luv.asn.au
PING luv.asn.au(itmustbe.luv.asn.au) 56 data bytes
64 bytes from itmustbe.luv.asn.au: icmp_seq=1 ttl=47 time=387 ms
64 bytes from itmustbe.luv.asn.au: icmp_seq=2 ttl=47 time=381 ms
64 bytes from itmustbe.luv.asn.au: icmp_seq=3 ttl=47 time=386 ms
^C
--- luv.asn.au ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3001ms
rtt min/avg/max/mdev = 381.614/385.104/387.423/2.612 ms
root@vk3irl:~#


Browsing to luv.asn.au gets an empty directory. I'm running native IPv6
here, and IPv6 is the preferred protocol.

I'm using Google, so you'd have to see what IP version is in the headers.
> 
> Andrew please add 2a01:4f8:100:7463::9 to the glue record for itmustbe, then 
> IPv6-only recursive DNS servers (if they happen to exist) can successfully 
> query the LUV server.
> 
> If your MTA has IPv6 enabled but broken (which is probably more common than 
> having IPv6 enabled and working correctly) then this may make it impossible 
> for you to participate in the LUV lists.
> 
> This change is probably going to cause some pain for some people (mostly me). 
>  
> But it's something that we need to do.  The world needs to move to IPv6 and 
> as 
> an IT organisation operating in the public interest LUV should be in the lead.
> 

Agree, everyone should be adopting IPv6 nowadays.


-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: Telstra 4G & IPv6

2015-12-08 Thread Jason White via luv-main
Brian May via luv-main <luv-main@luv.asn.au> wrote:
> Just wondering if Telstra supports IPv6? 


When I last checked (several years ago, at best), they supported it only over
their high-end business-grade connections, and definitely not over Bigpond.

If they had commenced support for it recently, I would expect them to have
made noise about it in a press release.

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Telstra 4G & IPv6

2015-12-08 Thread Brian May via luv-main
Hello,

Just wondering if Telstra supports IPv6? It didn't think so, however I
seem to be receiving RA packets on 80% of my connections, which
automatically configures an IPv6 address and route.

The problem with this is that IPv6 packets are getting silently dropped,
so I have to drop the default route in order to force my computer to
websites such as Google using IPv4. Otherwise the connections time out.

If there is someway this could be my fault ... However I can't see
how. Not running radvd locally.


#
# radvd configuration generated by radvdump 1.9.1
# based on Router Advertisement from fe80::100:0:0:0
# received by interface wwan0
#

interface wwan0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 21840;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvLinkMTU 1500;

prefix ::/64
{
AdvValidLifetime infinity; # (0x)
AdvPreferredLifetime infinity; # (0x)
AdvOnLink off;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition

}; # End of interface definition


% ip -6 addr 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
177: wwan0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1428 qlen 1000
inet6 ::c1f:e4ff:fef9:6bf8/64 scope global mngtmpaddr dynamic 
   valid_lft forever preferred_lft forever
inet6 fe80::c1f:e4ff:fef9:6bf8/64 scope link 
   valid_lft forever preferred_lft forever


% ip -6 route
local ::1 dev lo  proto kernel  metric 256 
fe80::/64 dev wwan0  proto kernel  metric 256 
default via fe80::100:0:0:0 dev wwan0  proto ra  metric 1024  expires 21669sec 
hoplimit 64



-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: Telstra 4G & IPv6

2015-12-08 Thread Brian May via luv-main
Jason White via luv-main  writes:

> When I last checked (several years ago, at best), they supported it only over
> their high-end business-grade connections, and definitely not over Bigpond.
>
> If they had commenced support for it recently, I would expect them to have
> made noise about it in a press release.

That is what I would have thought too. However, in that case why am I
receiving RA packets?
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: IPv6 PPPoA and MTU

2013-06-16 Thread Jason White
Brian May br...@microcomaustralia.com.au wrote:
 At Julien Goodwin's talk in April, he said, if I understand correctly,
 Internode has a bug in their implementation of PPPoA and IPv6 in that 1500
 size packets will get silently dropped. Only for IPv4, not IPv6.

It's happening for IPv4 here as well as IPv6.

I have to set my MTU to 1496 bytes on ppp0.

The symptom was that calls made to Internode's Nodephone service from my
FreeSWITCH installation failed - that is, SIP packets were dropped on the way
out.

Setting MTU to 1496 was enough to solve it. I just tested again:
ip link set mtu 1500 dev ppp0
called a Nodephone test number - no connection.

ip link set mtu 1496 dev ppp0
Repeated the call - it worked.

When originally diagnosing the problem, I ran pings of different sizes and
verified the cause.

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: Getting started with IPv6

2013-06-12 Thread Jason White
Trent W. Buck trentb...@gmail.com wrote:
  $ sysctl net.ipv6.conf.eth1.disable_ipv6=1
 deleted all IPv6 addresses from eth1, including the link-local addresses.
 
 Ah, thanks.  I remember that was the (Debian-)recommended way to blanket
 disable IPv6 on a system, before it was added a /proc/cmdline option.
 That seems like a pretty safe approach.

Another safe approach, on the router, would be
ip6tables -A OUTPUT -o eth1 -j DROP
ip6tables -A FORWARD -o eth1 -j DROP
ip6tables -A INPUT -o eth1 -j DROP

but my IPTables knowledge is hazy - I think the above should be enough to do it
however.

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Getting started with IPv6

2013-06-11 Thread Matthew Cengia
Hi all,

I want IPv6 experience.
Our main link at work is Internode, so I can get native IPv6.
I want an isolated test net that can talk IPv6 to the internet,
without leaking IPv6 into my production network.

I think I can do this by simply enabling IPv6 in the bastion's
kernel, and dropping IPv6 packets that aren't going between the test
net and the internet.

Is this safe?  Can IPv6 leak into my production net?





More details follow
---

I have a /24 IPv4 network with Internode. My router (known as Alpha)
is a full Ubuntu Lucid server with 4 downstream interfaces (each
serving a public /26) and 2 upstream ppp connections. (ppp0 is
Internode, ppp1 is an irrelevent backup Exetel link.)

| cyber@alpha:~$ ip link
| 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
| link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| 2: eth0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen 1000
| link/ether 1c:6f:65:c6:47:46 brd ff:ff:ff:ff:ff:ff
| 3: managed: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state 
UP qlen 1000
| link/ether 00:1b:21:b6:65:99 brd ff:ff:ff:ff:ff:ff
| 4: unmanaged: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast 
state UP qlen 1000
| link/ether 00:1b:21:b6:65:98 brd ff:ff:ff:ff:ff:ff
| 5: dmz: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
| link/ether 00:1b:21:b6:65:9b brd ff:ff:ff:ff:ff:ff
| 6: scratch: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state 
UP qlen 1000
| link/ether 00:1b:21:b6:65:9a brd ff:ff:ff:ff:ff:ff
| 518: ppp0: POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP mtu 1492 qdisc 
pfifo_fast state UNKNOWN qlen 3
| link/ppp
| 542: ppp1: POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP mtu 1492 qdisc 
pfifo_fast state UNKNOWN qlen 3
| link/ppp

IPv6 is disabled in Alpha's kernel. I want to give Alpha an extra
network interface called ip6test (or rename eth0 above) and have IPv6
passed through (and completely *isolated*) to the network segment
connected to that NIC. The top priority is ensuring that Alpha and the 4
IPv4 subnets (managed, unmanaged, dmz, and scratch) all drop IPv6
packets until I've more IPv6 experience.

Here's what I *think* is required, but I'm looking for a second opinion:

| #!/usr/sbin/ip6tables-apply
| *filter
| :OUTPUT ACCEPT  # Local users/processes are trusted.
| :INPUT  DROP# Ingress policy is default deny.
| :FORWARDDROP# Routing policy is default deny.
| :PRELUDE-   # Best practices for filtered chains.
|
| ## Quickly handle the essentials of a default deny environment.
| ## Anything left after this chain implicitly has --ctstate NEW.
| -A INPUT -j PRELUDE
| -A FORWARD -j PRELUDE
| -A PRELUDE -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
| -A PRELUDE -m conntrack ! --ctstate NEW -j DROP -m comment --comment Same as 
--ctstate INVALID.
| -A PRELUDE -o ip6test -p icmp -j ACCEPT -m comment --comment For now, only 
allow ICMP to test network
| -A PRELUDE -i lo -j ACCEPT
|
| ## YOUR RULES GO HERE
| -A FORWARD -o ip6test -p tcp --dport ssh -j ACCEPT -m comment --comment 
Allow IPv6 SSH traffic to test network
|
| ## Finally, politely reject all other attempts.  Omit these to use the
| ## chains' default policies (DROP, above) instead.
| -A INPUT   -j REJECT
| -A FORWARD -j REJECT
| COMMIT

So I expect, having enabled IPv6 in Alpha's kernel, Alpha
gets an IPv6 address on ppp0, but due to the above firewall,
IPv6 traffic not from/to ip6test will be rejected. Due to the
PRELUDE chain, ICMPv6 will be allowed to machines connected to the
ip6test interface, all of which I expect toobtain an IPv6 address.  The
FORWARD chain will allow direct SSH to those machines.

Assuming all the above is suitably secure, I then expect to carefully
open more IPv6 access up to the ip6test interface for further testing.

Further, will I need radvd or similar on Alpha, or will it be good
enough to handle that on another box connected to the ip6test interface,
or let Internode deal with it?

How does this all sound?

-- 
Regards,
Matthew Cengia


signature.asc
Description: Digital signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: Getting started with IPv6

2013-06-11 Thread John Mann
Hi,

IPv6 operation is dependent upon ICMPv6 working (for RA, RS, ND, DAD,
PMTUD, ...)
So, I think it is essential that you allow ICMPv6 in on ppp0 to Alpha.

Also, you will want to allow ICMPv6 in on ip6test to Alpha
and allow forwarding of ICMPv6 from ip6test to ppp0.
etc etc.

===
In short, I think you are trying too hard to filter traffic (before you
know how it all works),
and will likely end up with an IPv6 system that doesn't work, or doesn't
work well.

I would control traffic by giving ppp0, ip6test, and lo interfaces IPv6
addresses,
and not giving IPv6 addresses to the interfaces you do not want to
send/receive IPv6 traffic.
Alpha won't send IPv6 traffic out the other interfaces if it doesn't have a
route pointing out there.
Also, without IPv6 enabled, it won't receive IPv6 packets on those
interfaces.

You probably want to use DHCPv6 Prefix Delegation to communicate with
Internode to find your allocated IPv6 prefix
(so need to allow some IPv6 UDP in and out on ppp0).
How about DNS over IPv6?  If you give a test host an IPv6 address, but DNS
traffic over IPv6 times out, it could be seconds before the host retries
over IPv4.

I would recommend running radvd on Alpha, so that hosts on ip6test will
learn that Alpha is their default router.

 John



On 12 June 2013 14:27, Matthew Cengia matt...@gmail.com wrote:

 Hi all,

 I want IPv6 experience.
 Our main link at work is Internode, so I can get native IPv6.
 I want an isolated test net that can talk IPv6 to the internet,
 without leaking IPv6 into my production network.

 I think I can do this by simply enabling IPv6 in the bastion's
 kernel, and dropping IPv6 packets that aren't going between the test
 net and the internet.

 Is this safe?  Can IPv6 leak into my production net?





 More details follow
 ---

 I have a /24 IPv4 network with Internode. My router (known as Alpha)
 is a full Ubuntu Lucid server with 4 downstream interfaces (each
 serving a public /26) and 2 upstream ppp connections. (ppp0 is
 Internode, ppp1 is an irrelevent backup Exetel link.)

 | cyber@alpha:~$ ip link
 | 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
 | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 | 2: eth0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen 1000
 | link/ether 1c:6f:65:c6:47:46 brd ff:ff:ff:ff:ff:ff
 | 3: managed: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast
 state UP qlen 1000
 | link/ether 00:1b:21:b6:65:99 brd ff:ff:ff:ff:ff:ff
 | 4: unmanaged: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc
 pfifo_fast state UP qlen 1000
 | link/ether 00:1b:21:b6:65:98 brd ff:ff:ff:ff:ff:ff
 | 5: dmz: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast
 state UP qlen 1000
 | link/ether 00:1b:21:b6:65:9b brd ff:ff:ff:ff:ff:ff
 | 6: scratch: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast
 state UP qlen 1000
 | link/ether 00:1b:21:b6:65:9a brd ff:ff:ff:ff:ff:ff
 | 518: ppp0: POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP mtu 1492 qdisc
 pfifo_fast state UNKNOWN qlen 3
 | link/ppp
 | 542: ppp1: POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP mtu 1492 qdisc
 pfifo_fast state UNKNOWN qlen 3
 | link/ppp

 IPv6 is disabled in Alpha's kernel. I want to give Alpha an extra
 network interface called ip6test (or rename eth0 above) and have IPv6
 passed through (and completely *isolated*) to the network segment
 connected to that NIC. The top priority is ensuring that Alpha and the 4
 IPv4 subnets (managed, unmanaged, dmz, and scratch) all drop IPv6
 packets until I've more IPv6 experience.

 Here's what I *think* is required, but I'm looking for a second opinion:

 | #!/usr/sbin/ip6tables-apply
 | *filter
 | :OUTPUT ACCEPT  # Local users/processes are trusted.
 | :INPUT  DROP# Ingress policy is default deny.
 | :FORWARDDROP# Routing policy is default deny.
 | :PRELUDE-   # Best practices for filtered chains.
 |
 | ## Quickly handle the essentials of a default deny environment.
 | ## Anything left after this chain implicitly has --ctstate NEW.
 | -A INPUT -j PRELUDE
 | -A FORWARD -j PRELUDE
 | -A PRELUDE -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
 | -A PRELUDE -m conntrack ! --ctstate NEW -j DROP -m comment --comment
 Same as --ctstate INVALID.
 | -A PRELUDE -o ip6test -p icmp -j ACCEPT -m comment --comment For now,
 only allow ICMP to test network
 | -A PRELUDE -i lo -j ACCEPT
 |
 | ## YOUR RULES GO HERE
 | -A FORWARD -o ip6test -p tcp --dport ssh -j ACCEPT -m comment --comment
 Allow IPv6 SSH traffic to test network
 |
 | ## Finally, politely reject all other attempts.  Omit these to use the
 | ## chains' default policies (DROP, above) instead.
 | -A INPUT   -j REJECT
 | -A FORWARD -j REJECT
 | COMMIT

 So I expect, having enabled IPv6 in Alpha's kernel, Alpha
 gets an IPv6 address on ppp0, but due to the above firewall,
 IPv6 traffic not from/to ip6test will be rejected. Due

Re: Getting started with IPv6

2013-06-11 Thread Matthew Cengia
Hi John, thanks for your response.

On 2013-06-12 14:56, John Mann wrote:
[...]
 I would control traffic by giving ppp0, ip6test, and lo interfaces
 IPv6 addresses, and not giving IPv6 addresses to the interfaces you do
 not want to send/receive IPv6 traffic.

 Alpha won't send IPv6 traffic out the other interfaces if it doesn't have a
 route pointing out there.
 Also, without IPv6 enabled, it won't receive IPv6 packets on those
 interfaces.

How can I prevent these other interfaces obtaining IPv6 addresses if
these are being auto-configured via route advertisements etc.? Assuming
that's achievable reliably, I agree this is probably the best way to
ensure my primary FR: keeping my downstream IPv4 networks secure.

 You probably want to use DHCPv6 Prefix Delegation to communicate with
 Internode to find your allocated IPv6 prefix
 (so need to allow some IPv6 UDP in and out on ppp0).

I've not read up on DHCPv6 at all yet, so will need to do so before I
can fully understand the ramifications of the above paragraph

 How about DNS over IPv6?  If you give a test host an IPv6 address, but DNS
 traffic over IPv6 times out, it could be seconds before the host retries
 over IPv4.

This is true; as I said though, I'm prepared to open up other access
(such as DNS) to ip6test, and DNS would be one of the first candidates.

 I would recommend running radvd on Alpha, so that hosts on ip6test will
 learn that Alpha is their default router.

Right. The upcoming concern is going to be taking sufficient care when
configuring IPv6 stuff on Alpha to prevent accidental interruption of
the IPv4 traffic. I'll do some more research. I may be able to set up a
test system (e.g. using 6to4 upstream of a test Alpha) just to get the
config right before deploying on the production box.

-- 
Regards,
Matthew Cengia


signature.asc
Description: Digital signature
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: Getting started with IPv6

2013-06-11 Thread Trent W. Buck
John Mann john.m...@monash.edu writes:

 I would control traffic by giving ppp0, ip6test, and lo interfaces
 IPv6 addresses, and not giving IPv6 addresses to the interfaces you do
 not want to send/receive IPv6 traffic.

IME if you enable IPv6 in the kernel, EVERY up interface will have an
IPv6 address (the link-local one, I suppose).

 Also, without IPv6 enabled, it won't receive IPv6 packets on those
 interfaces.

Are you asserting that if IPv6 is enabled in-kernel, but an interface
has no IPv6 address, IPv6 traffic arriving on that interface will be
dropped on the floor?  What about broadcast traffic?

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main


Re: Getting started with IPv6

2013-06-11 Thread Trent W. Buck
John Mann john.m...@monash.edu writes:

 $ sysctl -a | grep ipv6.*disable
 net.ipv6.conf.all.disable_ipv6 = 0
 net.ipv6.conf.default.disable_ipv6 = 0
 net.ipv6.conf.eth0.disable_ipv6 = 0
 net.ipv6.conf.eth1.disable_ipv6 = 0
 net.ipv6.conf.lo.disable_ipv6 = 0

 $ sysctl net.ipv6.conf.eth1.disable_ipv6=1
deleted all IPv6 addresses from eth1, including the link-local addresses.

Ah, thanks.  I remember that was the (Debian-)recommended way to blanket
disable IPv6 on a system, before it was added a /proc/cmdline option.
That seems like a pretty safe approach.

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main