[Cake] cake for net-next 4.8

[Cake] cake for net-next 4.8

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

I quickly got sch_cake to work on top of net next. The attached diff
is probably not correct in some respect or another (what's to_free
for? And it looks like statistics collection has been parallelized
elsewhere)

... but I did not crash my box in an hour of trying, with it.

Judging from me tearing apart how TCP BBR works (presently) with ecn,
it looks like we need to add the equivalent to fq_codel ce_threshold
behaviors as well.

https://raw.githubusercontent.com/dtaht/blog-cerowrt/11cabc4c75358c075d4cab770377c986442282ec/content/flent/bbr-cethresh/think_cake_needs_ce_threshold.png



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

[-- Attachment #2: quick_hack_for_net_next_4.8.diff --]
[-- Type: text/x-patch, Size: 2478 bytes --]

diff --git a/codel5.h b/codel5.h
index e3fc94c..eb90239 100644
--- a/codel5.h
+++ b/codel5.h
@@ -62,7 +62,8 @@
 #include "codel5_compat.h"
 #else
 #define codel_stats_copy_queue(a, b, c, d) gnet_stats_copy_queue(a, b, c, d)
-#define codel_watchdog_schedule_ns(a, b, c) qdisc_watchdog_schedule_ns(a, b, c)
+// #define codel_watchdog_schedule_ns(a, b, c) qdisc_watchdog_schedule_ns(a, b, c)
+#define codel_watchdog_schedule_ns(a, b, c) qdisc_watchdog_schedule_ns(a, b)
 #endif
 
 
diff --git a/sch_cake.c b/sch_cake.c
index eae532d..e08fa91 100644
--- a/sch_cake.c
+++ b/sch_cake.c
@@ -318,7 +318,7 @@ cake_hash(struct cake_tin_data *q, const struct sk_buff *skb, int flow_mode)
 	host_keys.ports.ports     = 0;
 	host_keys.basic.ip_proto  = 0;
 	host_keys.keyid.keyid     = 0;
-	host_keys.tags.vlan_id    = 0;
+	//	host_keys.tags.vlan_id    = 0;
 	host_keys.tags.flow_label = 0;
 
 	switch (host_keys.control.addr_type) {
@@ -650,7 +650,9 @@ static inline u32 cake_get_diffserv(struct sk_buff *skb)
 
 static void cake_reconfigure(struct Qdisc *sch);
 
-static s32 cake_enqueue(struct sk_buff *skb, struct Qdisc *sch)
+// static s32 cake_enqueue(struct sk_buff *skb, struct Qdisc *sch)
+static s32 cake_enqueue(struct sk_buff *skb, struct Qdisc *sch,
+			struct sk_buff **to_free)
 {
 	struct cake_sched_data *q = qdisc_priv(sch);
 	u32 idx, tin;
@@ -694,7 +696,7 @@ static s32 cake_enqueue(struct sk_buff *skb, struct Qdisc *sch)
 		segs = skb_gso_segment(skb, features & ~NETIF_F_GSO_MASK);
 
 		if (IS_ERR_OR_NULL(segs))
-			return qdisc_reshape_fail(skb, sch);
+		  return qdisc_drop(skb, sch, to_free);
 
 		while (segs) {
 			nskb = segs->next;
@@ -859,8 +861,7 @@ begin:
 	/* global hard shaper */
 	if (q->time_next_packet > now) {
 		sch->qstats.overlimits++;
-		codel_watchdog_schedule_ns(&q->watchdog, q->time_next_packet,
-					   true);
+		qdisc_watchdog_schedule_ns(&q->watchdog, q->time_next_packet);
 		return NULL;
 	}
 
@@ -999,7 +1000,7 @@ retry:
 		/* drop this packet, get another one */
 		b->tin_dropped++;
 		qdisc_tree_reduce_backlog(sch, 1, qdisc_pkt_len(skb));
-		qdisc_drop(skb, sch);
+		__qdisc_drop(skb, NULL);
 	}
 
 	b->tin_ecn_mark += !!flow->cvars.ecn_marked;
@@ -1813,7 +1814,7 @@ static struct Qdisc_ops cake_qdisc_ops __read_mostly = {
 	.enqueue	=	cake_enqueue,
 	.dequeue	=	cake_dequeue,
 	.peek		=	qdisc_peek_dequeued,
-	.drop		=	cake_drop,
+	//	.drop		=	cake_drop,
 	.init		=	cake_init,
 	.reset		=	cake_reset,
 	.destroy	=	cake_destroy,

Re: [Cake] cake for net-next 4.8

[Jonathan Morton]

> On 25 Sep, 2016, at 21:30, Dave Taht <dave.taht@gmail.com> wrote:
> 
> I quickly got sch_cake to work on top of net next. The attached diff
> is probably not correct in some respect or another (what's to_free
> for? And it looks like statistics collection has been parallelized
> elsewhere)

Yet another mail I had to fish out of my spam folder.  Google really doesn’t seem to like you - I’m going to try looking for a whitelist option in the webmail interface (which I usually avoid).

I’m pretty sure to_free is for attaching a list of skbs for deferred bulk deletion.  Might help under sustained overload, but not in the common case.

 - Jonathan Morton

Re: [Cake] cake for net-next 4.8

[Dave Taht]

Annoying. Perhaps my link to the blog in my .sig? Perhaps they object
to my verbosity?

On Tue, Sep 27, 2016 at 7:38 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 25 Sep, 2016, at 21:30, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> I quickly got sch_cake to work on top of net next. The attached diff
>> is probably not correct in some respect or another (what's to_free
>> for? And it looks like statistics collection has been parallelized
>> elsewhere)
>
> Yet another mail I had to fish out of my spam folder.  Google really doesn’t seem to like you - I’m going to try looking for a whitelist option in the webmail interface (which I usually avoid).
>
> I’m pretty sure to_free is for attaching a list of skbs for deferred bulk deletion.  Might help under sustained overload, but not in the common case.
>
>  - Jonathan Morton
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://blog.cerowrt.org

Re: [Cake] cake for net-next 4.8

[Jonathan Morton]

> On 27 Sep, 2016, at 19:04, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Annoying. Perhaps my link to the blog in my .sig? Perhaps they object
> to my verbosity?

This seems relevant in the headers:

Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@gmail.com; spf=pass (google.com: best guess record for domain of cake-bounces@lists.bufferbloat.net designates 45.79.142.77 as permitted sender) smtp.mailfrom=cake-bounces@lists.bufferbloat.net; dmarc=fail (p=NONE dis=NONE) header.from=gmail.com

I forget exactly how DKIM and DMARC work, but DKIM seems to be stymied by the list adding its own message footer (which is nevertheless best-practice).  I don’t know how relevant a DMARC fail is to their filter, or how relevant it *should* be.

Could the listserver replace an original, verified DKIM certificate with its own after adding the footer?

On the upside, I was able to add a filter specifically saying “never send to Spam folder”, and it appears to be working so far.  But everyone probably needs to do that; it’s not a scalable solution, only a workaround.

 - Jonathan Morton

Re: [Cake] cake for net-next 4.8

[Jonathan Morton]

> On 25 Sep, 2016, at 21:30, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Judging from me tearing apart how TCP BBR works (presently) with ecn,
> it looks like we need to add the equivalent to fq_codel ce_threshold
> behaviors as well.

If I’m reading the legend correctly, you are setting ce_threshold to 1ms to get the better-controlled result.  But that effectively disables the codel algorithm and turns it into a simple “mark all packets over 1ms sojourn” for ECN capable traffic, because it’s a tighter limit than codel’s target.  That’s too aggressive for non-BBR traffic.

In these cases, I think you have to relax and let the FQ action take care of it.

 - Jonathan Morton

Re: [Cake] cake for net-next 4.8

[Dave Taht]

On Tue, Sep 27, 2016 at 10:52 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 25 Sep, 2016, at 21:30, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Judging from me tearing apart how TCP BBR works (presently) with ecn,
>> it looks like we need to add the equivalent to fq_codel ce_threshold
>> behaviors as well.
>
> If I’m reading the legend correctly, you are setting ce_threshold to 1ms to get the better-controlled result.  But that effectively disables the codel algorithm and turns it into a simple “mark all packets over 1ms sojourn” for ECN capable traffic, because it’s a tighter limit than codel’s target.  That’s too aggressive for non-BBR traffic.

Yes it is. :) However the consensus appears to be that ECN should be
an earlier signal than drop, and the work over on the tcp-prague list
centers around repurposing ECT(1) as more like a DCTCP multi-bit
signal.

ce_threshold 1ms is more like signaling loudly - "this is a solid
indicator of  your real OWD" and "you should fiddle with your TCP's
'gain' to compensate for it" - and it's certainly a lot simpler than
codel to do it this way. I haven't got around to fully evaluating a
comparison between BBR with ce_threshold and a non-ecn enabled TCP vs
codel, concurrently (or implementing different behaviors for ECT(1) in
the TCP negotiation step) ...

and... I'm really not sure if what I've seen with ce_threshold is the
desired behavior, vs a vs BBR, thus far - but I'd like to see the
option for it enter cake.

Also, in doing in my network this way, it became apparent to me that -
like several ecn encapsulation rfcs suggest - that when a packet is
already marked CE, and we want to also mark it CE, that the rightest
answer is to drop the packet - not giving pre-CE-marked flows a free
ride.

> In these cases, I think you have to relax and let the FQ action take care of it.

And yes, FQ handles it nicely. Got pics of that somewhere. I did do a
test with ce_threshold + ecn + bbr, vs no ecn and cubic, with the
usual lovely fq'd result.

>  - Jonathan Morton
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cake] cake for net-next 4.8

[Jonathan Morton]

> On 27 Sep, 2016, at 21:18, Dave Taht <dave.taht@gmail.com> wrote:
> 
>> On Tue, Sep 27, 2016 at 10:52 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>> 
>>> On 25 Sep, 2016, at 21:30, Dave Taht <dave.taht@gmail.com> wrote:
>>> 
>>> Judging from me tearing apart how TCP BBR works (presently) with ecn,
>>> it looks like we need to add the equivalent to fq_codel ce_threshold
>>> behaviors as well.
>> 
>> If I’m reading the legend correctly, you are setting ce_threshold to 1ms to get the better-controlled result.  But that effectively disables the codel algorithm and turns it into a simple “mark all packets over 1ms sojourn” for ECN capable traffic, because it’s a tighter limit than codel’s target.  That’s too aggressive for non-BBR traffic.
> 
> Yes it is. :) However the consensus appears to be that ECN should be
> an earlier signal than drop, and the work over on the tcp-prague list
> centers around repurposing ECT(1) as more like a DCTCP multi-bit
> signal.

My interpretation of the consensus is more subtle: we need a signal earlier than we currently do, and with a weaker meaning, but we still need the strong, later signal.

I don’t think we should use CE for that; it has a long-established and widely-deployed meaning.  We *can* use ECT(1), which is presently unused in practice.

> I'm really not sure if what I've seen with ce_threshold is the
> desired behavior, vs a vs BBR, thus far - but I'd like to see the
> option for it enter cake.

Before I even consider doing that, could you add a comparable run with the current version of cake to that graph?  COBALT is not quite identical to Codel, and this looks like a case where one of the differences could be important.

 - Jonathan Morton

Re: [Cake] cake for net-next 4.8

[Dave Taht]

On Tue, Sep 27, 2016 at 11:56 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 27 Sep, 2016, at 21:18, Dave Taht <dave.taht@gmail.com> wrote:
>>
>>> On Tue, Sep 27, 2016 at 10:52 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>>>
>>>> On 25 Sep, 2016, at 21:30, Dave Taht <dave.taht@gmail.com> wrote:
>>>>
>>>> Judging from me tearing apart how TCP BBR works (presently) with ecn,
>>>> it looks like we need to add the equivalent to fq_codel ce_threshold
>>>> behaviors as well.
>>>
>>> If I’m reading the legend correctly, you are setting ce_threshold to 1ms to get the better-controlled result.  But that effectively disables the codel algorithm and turns it into a simple “mark all packets over 1ms sojourn” for ECN capable traffic, because it’s a tighter limit than codel’s target.  That’s too aggressive for non-BBR traffic.
>>
>> Yes it is. :) However the consensus appears to be that ECN should be
>> an earlier signal than drop, and the work over on the tcp-prague list
>> centers around repurposing ECT(1) as more like a DCTCP multi-bit
>> signal.
>
> My interpretation of the consensus is more subtle: we need a signal earlier than we currently do, and with a weaker meaning, but we still need the strong, later signal.
>
> I don’t think we should use CE for that; it has a long-established and widely-deployed meaning.  We *can* use ECT(1), which is presently unused in practice.

I have not been paying much attention of late to more carefully manage
my blood pressure.

https://groups.google.com/forum/#!topic/bbr-dev/VNUBKAeJSdc


>> I'm really not sure if what I've seen with ce_threshold is the
>> desired behavior, vs a vs BBR, thus far - but I'd like to see the
>> option for it enter cake.
>
> Before I even consider doing that, could you add a comparable run with the current version of cake to that graph?  COBALT is not quite identical to Codel, and this looks like a case where one of the differences could be important.

OK, at some point, but I have to abandon the lab, it looks like:

http://abc7news.com/news/loma-fire-grows-to-at-least-1000-acres-in-santa-cruz-mountains-/1527657/

I'm currently packing up everything that's important!

>
>  - Jonathan Morton
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cake] cake for net-next 4.8

[Jonathan Morton]

> On 27 Sep, 2016, at 22:29, Dave Taht <dave.taht@gmail.com> wrote:
> 
> OK, at some point, but I have to abandon the lab, it looks like:

Yet another reason to be glad I live in a cold and slightly damp country.

> https://groups.google.com/forum/#!topic/bbr-dev/VNUBKAeJSdc

If BBR is not currently responding to CE marks, then ce_threshold should have no effect.  This leaves me confused as to what the graph actually shows.

But COBALT does have a better chance of controlling the spike after a short gap, because its resuming behaviour is more aggressive than standard Codel.  It will just have to do so with drops rather than marks.

 - Jonatan Morton

Re: [Cake] cake for net-next 4.8

[Dave Taht]

On Tue, Sep 27, 2016 at 11:56 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 27 Sep, 2016, at 21:18, Dave Taht <dave.taht@gmail.com> wrote:
>>
>>> On Tue, Sep 27, 2016 at 10:52 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>>>
>>>> On 25 Sep, 2016, at 21:30, Dave Taht <dave.taht@gmail.com> wrote:
>>>>
>>>> Judging from me tearing apart how TCP BBR works (presently) with ecn,
>>>> it looks like we need to add the equivalent to fq_codel ce_threshold
>>>> behaviors as well.
>>>
>>> If I’m reading the legend correctly, you are setting ce_threshold to 1ms to get the better-controlled result.  But that effectively disables the codel algorithm and turns it into a simple “mark all packets over 1ms sojourn” for ECN capable traffic, because it’s a tighter limit than codel’s target.  That’s too aggressive for non-BBR traffic.
>>
>> Yes it is. :) However the consensus appears to be that ECN should be
>> an earlier signal than drop, and the work over on the tcp-prague list
>> centers around repurposing ECT(1) as more like a DCTCP multi-bit
>> signal.
>
> My interpretation of the consensus is more subtle: we need a signal earlier than we currently do, and with a weaker meaning, but we still need the strong, later signal.
>
> I don’t think we should use CE for that; it has a long-established and widely-deployed meaning.  We *can* use ECT(1), which is presently unused in practice.

I have been avoiding the tcp-prague, l4s, etc debates, for health reasons,
and it's possible I've misunderstood something. All along I'd been assuming
that a specialized TCP of some new flavor yet-to-be-agreed-upon would
negotiate ECN and most/all its packets would be marked ECT(1), rather
than ECT(0), and a new AQM would treat a flow like that differently,
but still mark that flow with a CE that the endpoint would interpret
differently.

Are you saying ECT(1) would, instead, be used as a "weaker or harder" CE?


>> I'm really not sure if what I've seen with ce_threshold is the
>> desired behavior, vs a vs BBR, thus far - but I'd like to see the
>> option for it enter cake.
>
> Before I even consider doing that, could you add a comparable run with the current version of cake to that graph?  COBALT is not quite identical to Codel, and this looks like a case where one of the differences could be important.
>
>  - Jonathan Morton
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cake] cake for net-next 4.8

[Jonathan Morton]

> On 29 Sep, 2016, at 02:26, Dave Taht <dave.taht@gmail.com> wrote:
> 
> All along I'd been assuming
> that a specialized TCP of some new flavor yet-to-be-agreed-upon would
> negotiate ECN and most/all its packets would be marked ECT(1), rather
> than ECT(0), and a new AQM would treat a flow like that differently,
> but still mark that flow with a CE that the endpoint would interpret
> differently.
> 
> Are you saying ECT(1) would, instead, be used as a "weaker or harder" CE?

The former appears to be the solution TCP Prague are keen on.  It doesn’t seem like a robust, deployable solution to me, despite the tremendous amount of effort that’s gone into that class of solutions.

The latter is my suggestion - to use the distinction between ECT(0) and ECT(1) as a hint, rather than a command, to slow down.  I also think we should move computation of the congestion window to the receiver, as that greatly simplifies the reverse-path signalling problem.

You may remember my description of ELR.  I started documenting it more formally, and then got distracted by something more urgent...

 - Jonathan Morton

Re: [Cake] cake for net-next 4.8

[Andrew Shewmaker]

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

On Wed, Sep 28, 2016 at 5:34 PM, Jonathan Morton <chromatix99@gmail.com>
wrote:

>
> > On 29 Sep, 2016, at 02:26, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > All along I'd been assuming
> > that a specialized TCP of some new flavor yet-to-be-agreed-upon would
> > negotiate ECN and most/all its packets would be marked ECT(1), rather
> > than ECT(0), and a new AQM would treat a flow like that differently,
> > but still mark that flow with a CE that the endpoint would interpret
> > differently.
> >
> > Are you saying ECT(1) would, instead, be used as a "weaker or harder" CE?
>
> The former appears to be the solution TCP Prague are keen on.  It doesn’t
> seem like a robust, deployable solution to me, despite the tremendous
> amount of effort that’s gone into that class of solutions.
>
> The latter is my suggestion - to use the distinction between ECT(0) and
> ECT(1) as a hint, rather than a command, to slow down.  I also think we
> should move computation of the congestion window to the receiver, as that
> greatly simplifies the reverse-path signalling problem.
>

I agree that there's some big potential advantages to that. But I wouldn't
say the congestion window calculation should be moved to the receiver, so
much as duplicated by the receiver. Here's a link to a receiver-side
congestion control patch I've been working on:

https://github.com/systemslab/tcp_inigo/tree/master/inigo_receiver

It uses TCP timestamps to keep track of the accumulated differences in one
way delays, and adjusts the receive window similarly to DCTCP.

The mininet tests I've run show some promise making CUBIC and Reno share
more fairly and tightening up their RTT distribution, but I need to do a
lot more testing.

I'm looking forward to Eric Dumazet's usec resolution time stamp support
being upstreamed so that my receiver-side technique might become useful in
data centers.


> You may remember my description of ELR.  I started documenting it more
> formally, and then got distracted by something more urgent...
>
>  - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>



-- 
Andrew Shewmaker

[-- Attachment #2: Type: text/html, Size: 4156 bytes --]

Re: [Cake] cake for net-next 4.8

[Neil Shepperd]

[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]

I think I have now accumulated enough spam/nonspam classified emails to
make a statistically signification observation: it seems like all emails
classified as spam from these lists were send from ipv6:

SPF: PASS with IP 2600:3c03:0:0:f03c:91ff:fe61:86ce

All emails from bufferbloat.net lists are failing DKIM (because of the
mailing list footer breaking the DKIM signature) which might be worth
fixing, and failing DMARC because all mailing lists fails DMARC (however
google does not have a strict DMARC policy so that shouldn't matter, I
hope).

By the way, it's not just you, either. I have emails from others on these
lists in my spam folder.

The distinguishing factor seems to be whether the email was sent from the
lists.bufferbloat.net ipv6 address. Unless this address corresponds to some
kind of tunnel broker possibly also used by spammers, I can only assume
this is some kind of bug (after all, it was spf validated so the address
shouldn't matter at that point?).

I'm going to see if I can file some sort of a bug with special googler
powers, but I probably won't be allowed to tell you anything if they reply.

On Tue, 27 Sep 2016 at 12:14 Jonathan Morton <chromatix99@gmail.com> wrote:

>
> > On 27 Sep, 2016, at 19:04, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > Annoying. Perhaps my link to the blog in my .sig? Perhaps they object
> > to my verbosity?
>
> This seems relevant in the headers:
>
> Authentication-Results: mx.google.com; dkim=neutral (body hash did not
> verify) header.i=@gmail.com; spf=pass (google.com: best guess record for
> domain of cake-bounces@lists.bufferbloat.net designates 45.79.142.77 as
> permitted sender) smtp.mailfrom=cake-bounces@lists.bufferbloat.net;
> dmarc=fail (p=NONE dis=NONE) header.from=gmail.com
>
> I forget exactly how DKIM and DMARC work, but DKIM seems to be stymied by
> the list adding its own message footer (which is nevertheless
> best-practice).  I don’t know how relevant a DMARC fail is to their filter,
> or how relevant it *should* be.
>
> Could the listserver replace an original, verified DKIM certificate with
> its own after adding the footer?
>
> On the upside, I was able to add a filter specifically saying “never send
> to Spam folder”, and it appears to be working so far.  But everyone
> probably needs to do that; it’s not a scalable solution, only a workaround.
>
>  - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

[-- Attachment #2: Type: text/html, Size: 4079 bytes --]

Re: [Cake] cake for net-next 4.8

[Toke Høiland-Jørgensen]

Neil Shepperd <nshepperd@gmail.com> writes:

> I think I have now accumulated enough spam/nonspam classified emails
> to make a statistically signification observation: it seems like all
> emails classified as spam from these lists were send from ipv6:
>
> SPF: PASS with IP 2600:3c03:0:0:f03c:91ff:fe61:86ce  
>
> All emails from bufferbloat.net lists are failing DKIM (because of the
> mailing list footer breaking the DKIM signature) which might be worth
> fixing, and failing DMARC because all mailing lists fails DMARC
> (however google does not have a strict DMARC policy so that shouldn't
> matter, I hope).
>
> By the way, it's not just you, either. I have emails from others on
> these lists in my spam folder.
>
> The distinguishing factor seems to be whether the email was sent from
> the lists.bufferbloat.net ipv6 address. Unless this address
> corresponds to some kind of tunnel broker possibly also used by
> spammers, I can only assume this is some kind of bug (after all, it
> was spf validated so the address shouldn't matter at that point?).

Indeed, gmail requires extra measures for IPv6:
https://support.google.com/mail/answer/81126 (scroll down to "Additional
guidelines for IPv6").

Fixing DKIM might be worthwhile :)

-Toke

Re: [Cake] cake for net-next 4.8

[Neil Shepperd]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

Hmm, PTR record is there, so I guess setting up DKIM is indeed the most
likely culprit.

On 30 September 2016 at 04:02, Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Neil Shepperd <nshepperd@gmail.com> writes:
>
> > I think I have now accumulated enough spam/nonspam classified emails
> > to make a statistically signification observation: it seems like all
> > emails classified as spam from these lists were send from ipv6:
> >
> > SPF: PASS with IP 2600:3c03:0:0:f03c:91ff:fe61:86ce
> >
> > All emails from bufferbloat.net lists are failing DKIM (because of the
> > mailing list footer breaking the DKIM signature) which might be worth
> > fixing, and failing DMARC because all mailing lists fails DMARC
> > (however google does not have a strict DMARC policy so that shouldn't
> > matter, I hope).
> >
> > By the way, it's not just you, either. I have emails from others on
> > these lists in my spam folder.
> >
> > The distinguishing factor seems to be whether the email was sent from
> > the lists.bufferbloat.net ipv6 address. Unless this address
> > corresponds to some kind of tunnel broker possibly also used by
> > spammers, I can only assume this is some kind of bug (after all, it
> > was spf validated so the address shouldn't matter at that point?).
>
> Indeed, gmail requires extra measures for IPv6:
> https://support.google.com/mail/answer/81126 (scroll down to "Additional
> guidelines for IPv6").
>
> Fixing DKIM might be worthwhile :)
>
> -Toke
>

[-- Attachment #2: Type: text/html, Size: 2286 bytes --]

Re: [Cake] cake for net-next 4.8

[Dave Täht]

On 9/30/16 1:02 AM, Toke Høiland-Jørgensen wrote:
> Neil Shepperd <nshepperd@gmail.com> writes:
> 
>> I think I have now accumulated enough spam/nonspam classified emails
>> to make a statistically signification observation: it seems like all
>> emails classified as spam from these lists were send from ipv6:
>>
>> SPF: PASS with IP 2600:3c03:0:0:f03c:91ff:fe61:86ce  
>>
>> All emails from bufferbloat.net lists are failing DKIM (because of the
>> mailing list footer breaking the DKIM signature) which might be worth
>> fixing, and failing DMARC because all mailing lists fails DMARC
>> (however google does not have a strict DMARC policy so that shouldn't
>> matter, I hope).
>>
>> By the way, it's not just you, either. I have emails from others on
>> these lists in my spam folder.
>>
>> The distinguishing factor seems to be whether the email was sent from
>> the lists.bufferbloat.net ipv6 address. Unless this address
>> corresponds to some kind of tunnel broker possibly also used by
>> spammers, I can only assume this is some kind of bug (after all, it
>> was spf validated so the address shouldn't matter at that point?).
> 
> Indeed, gmail requires extra measures for IPv6:
> https://support.google.com/mail/answer/81126 (scroll down to "Additional
> guidelines for IPv6").
> 
> Fixing DKIM might be worthwhile :)

But it passes the spf check?? And the reverse lookup is correct.

How about I just disable ipv6?

Have no idea why dkim doesn't work.

> 
> -Toke
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
> 

Re: [Cake] cake for net-next 4.8

[Neil Shepperd]

[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]

Disabling ipv6 (at least in the mail server, in outgoing direction) is
probably the easiest option...
I see on most messages here DKIM-Signature headers apparently from gmail:
"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;". These
signatures are failing because of the added message footer. No sign of a
DKIM-Signature for lists.bufferbloat.net. You'd need to set that up in the
list MTA.

On Fri, 30 Sep 2016 at 15:42 Dave Täht <dave@taht.net> wrote:

>
>
> On 9/30/16 1:02 AM, Toke Høiland-Jørgensen wrote:
> > Neil Shepperd <nshepperd@gmail.com> writes:
> >
> >> I think I have now accumulated enough spam/nonspam classified emails
> >> to make a statistically signification observation: it seems like all
> >> emails classified as spam from these lists were send from ipv6:
> >>
> >> SPF: PASS with IP 2600:3c03:0:0:f03c:91ff:fe61:86ce
> >>
> >> All emails from bufferbloat.net lists are failing DKIM (because of the
> >> mailing list footer breaking the DKIM signature) which might be worth
> >> fixing, and failing DMARC because all mailing lists fails DMARC
> >> (however google does not have a strict DMARC policy so that shouldn't
> >> matter, I hope).
> >>
> >> By the way, it's not just you, either. I have emails from others on
> >> these lists in my spam folder.
> >>
> >> The distinguishing factor seems to be whether the email was sent from
> >> the lists.bufferbloat.net ipv6 address. Unless this address
> >> corresponds to some kind of tunnel broker possibly also used by
> >> spammers, I can only assume this is some kind of bug (after all, it
> >> was spf validated so the address shouldn't matter at that point?).
> >
> > Indeed, gmail requires extra measures for IPv6:
> > https://support.google.com/mail/answer/81126 (scroll down to "Additional
> > guidelines for IPv6").
> >
> > Fixing DKIM might be worthwhile :)
>
> But it passes the spf check?? And the reverse lookup is correct.
>
> How about I just disable ipv6?
>
> Have no idea why dkim doesn't work.
>
> >
> > -Toke
> > _______________________________________________
> > Cake mailing list
> > Cake@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake
> >
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

[-- Attachment #2: Type: text/html, Size: 3661 bytes --]

Re: [Cake] cake for net-next 4.8

[Dave Täht]

On 9/30/16 1:37 PM, Neil Shepperd wrote:
> Disabling ipv6 (at least in the mail server, in outgoing direction) is
> probably the easiest option...

It looks like the simplest thing I could do to allow inbound while
stopping outbound ipv6 would be to:

/etc/postfix/main.cf:
    smtp_bind_address6 = ::1


> I see on most messages here DKIM-Signature headers apparently from
> gmail: "v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com
> <http://gmail.com>; s=20120113;". These signatures are failing because
> of the added message footer. No sign of a DKIM-Signature
> for lists.bufferbloat.net <http://lists.bufferbloat.net>. You'd need to
> set that up in the list MTA.

Honestly my "email-fu" has declined considerably in recent years.
Despite the apparent simplicity of this idea, my brain just crashed
multiple times on setting it up with postfix + mailman 2.

And thank you for poking so deeply into this, I was A) really annoyed by
the bloat-list-as-spam thing and B) clueless.

> On Fri, 30 Sep 2016 at 15:42 Dave Täht <dave@taht.net
> <mailto:dave@taht.net>> wrote:
> 
> 
> 
>     On 9/30/16 1:02 AM, Toke Høiland-Jørgensen wrote:
>     > Neil Shepperd <nshepperd@gmail.com <mailto:nshepperd@gmail.com>>
>     writes:
>     >
>     >> I think I have now accumulated enough spam/nonspam classified emails
>     >> to make a statistically signification observation: it seems like all
>     >> emails classified as spam from these lists were send from ipv6:
>     >>
>     >> SPF: PASS with IP 2600:3c03:0:0:f03c:91ff:fe61:86ce
>     >>
>     >> All emails from bufferbloat.net <http://bufferbloat.net> lists
>     are failing DKIM (because of the
>     >> mailing list footer breaking the DKIM signature) which might be worth
>     >> fixing, and failing DMARC because all mailing lists fails DMARC
>     >> (however google does not have a strict DMARC policy so that shouldn't
>     >> matter, I hope).
>     >>
>     >> By the way, it's not just you, either. I have emails from others on
>     >> these lists in my spam folder.
>     >>
>     >> The distinguishing factor seems to be whether the email was sent from
>     >> the lists.bufferbloat.net <http://lists.bufferbloat.net> ipv6
>     address. Unless this address
>     >> corresponds to some kind of tunnel broker possibly also used by
>     >> spammers, I can only assume this is some kind of bug (after all, it
>     >> was spf validated so the address shouldn't matter at that point?).
>     >
>     > Indeed, gmail requires extra measures for IPv6:
>     > https://support.google.com/mail/answer/81126 (scroll down to
>     "Additional
>     > guidelines for IPv6").
>     >
>     > Fixing DKIM might be worthwhile :)
> 
>     But it passes the spf check?? And the reverse lookup is correct.
> 
>     How about I just disable ipv6?
> 
>     Have no idea why dkim doesn't work.
> 
>     >
>     > -Toke
>     > _______________________________________________
>     > Cake mailing list
>     > Cake@lists.bufferbloat.net <mailto:Cake@lists.bufferbloat.net>
>     > https://lists.bufferbloat.net/listinfo/cake
>     >
>     _______________________________________________
>     Cake mailing list
>     Cake@lists.bufferbloat.net <mailto:Cake@lists.bufferbloat.net>
>     https://lists.bufferbloat.net/listinfo/cake
> 

Re: [Cake] cake for net-next 4.8

[Neil Shepperd]

[-- Attachment #1: Type: text/plain, Size: 3860 bytes --]

Gmail spam team got back to me; they have apparently "fixed the problem",
which I guess means messages here should stop being marked as spam soon.
Because gmail's spam filters are top secret business, I couldn't tell you
anything else :)

On Fri, 30 Sep 2016 at 17:10 Dave Täht <dave@taht.net> wrote:

>
>
> On 9/30/16 1:37 PM, Neil Shepperd wrote:
> > Disabling ipv6 (at least in the mail server, in outgoing direction) is
> > probably the easiest option...
>
> It looks like the simplest thing I could do to allow inbound while
> stopping outbound ipv6 would be to:
>
> /etc/postfix/main.cf:
>     smtp_bind_address6 = ::1
>
>
> > I see on most messages here DKIM-Signature headers apparently from
> > gmail: "v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com
> > <http://gmail.com>; s=20120113;". These signatures are failing because
> > of the added message footer. No sign of a DKIM-Signature
> > for lists.bufferbloat.net <http://lists.bufferbloat.net>. You'd need to
> > set that up in the list MTA.
>
> Honestly my "email-fu" has declined considerably in recent years.
> Despite the apparent simplicity of this idea, my brain just crashed
> multiple times on setting it up with postfix + mailman 2.
>
> And thank you for poking so deeply into this, I was A) really annoyed by
> the bloat-list-as-spam thing and B) clueless.
>
> > On Fri, 30 Sep 2016 at 15:42 Dave Täht <dave@taht.net
> > <mailto:dave@taht.net>> wrote:
> >
> >
> >
> >     On 9/30/16 1:02 AM, Toke Høiland-Jørgensen wrote:
> >     > Neil Shepperd <nshepperd@gmail.com <mailto:nshepperd@gmail.com>>
> >     writes:
> >     >
> >     >> I think I have now accumulated enough spam/nonspam classified
> emails
> >     >> to make a statistically signification observation: it seems like
> all
> >     >> emails classified as spam from these lists were send from ipv6:
> >     >>
> >     >> SPF: PASS with IP 2600:3c03:0:0:f03c:91ff:fe61:86ce
> >     >>
> >     >> All emails from bufferbloat.net <http://bufferbloat.net> lists
> >     are failing DKIM (because of the
> >     >> mailing list footer breaking the DKIM signature) which might be
> worth
> >     >> fixing, and failing DMARC because all mailing lists fails DMARC
> >     >> (however google does not have a strict DMARC policy so that
> shouldn't
> >     >> matter, I hope).
> >     >>
> >     >> By the way, it's not just you, either. I have emails from others
> on
> >     >> these lists in my spam folder.
> >     >>
> >     >> The distinguishing factor seems to be whether the email was sent
> from
> >     >> the lists.bufferbloat.net <http://lists.bufferbloat.net> ipv6
> >     address. Unless this address
> >     >> corresponds to some kind of tunnel broker possibly also used by
> >     >> spammers, I can only assume this is some kind of bug (after all,
> it
> >     >> was spf validated so the address shouldn't matter at that point?).
> >     >
> >     > Indeed, gmail requires extra measures for IPv6:
> >     > https://support.google.com/mail/answer/81126 (scroll down to
> >     "Additional
> >     > guidelines for IPv6").
> >     >
> >     > Fixing DKIM might be worthwhile :)
> >
> >     But it passes the spf check?? And the reverse lookup is correct.
> >
> >     How about I just disable ipv6?
> >
> >     Have no idea why dkim doesn't work.
> >
> >     >
> >     > -Toke
> >     > _______________________________________________
> >     > Cake mailing list
> >     > Cake@lists.bufferbloat.net <mailto:Cake@lists.bufferbloat.net>
> >     > https://lists.bufferbloat.net/listinfo/cake
> >     >
> >     _______________________________________________
> >     Cake mailing list
> >     Cake@lists.bufferbloat.net <mailto:Cake@lists.bufferbloat.net>
> >     https://lists.bufferbloat.net/listinfo/cake
> >
>

[-- Attachment #2: Type: text/html, Size: 6252 bytes --]

Re: [Cake] cake for net-next 4.8

[Henning Rogge]

On Mon, Oct 3, 2016 at 11:17 PM, Neil Shepperd <nshepperd@gmail.com> wrote:
> Gmail spam team got back to me; they have apparently "fixed the problem",
> which I guess means messages here should stop being marked as spam soon.
> Because gmail's spam filters are top secret business, I couldn't tell you
> anything else :)

Yeah,

we know the drill... you could tell us, but then you would have to
delete our Google Account... ;)


Good to hear the problem is gone.

Henning
>
> On Fri, 30 Sep 2016 at 17:10 Dave Täht <dave@taht.net> wrote:
>>
>>
>>
>> On 9/30/16 1:37 PM, Neil Shepperd wrote:
>> > Disabling ipv6 (at least in the mail server, in outgoing direction) is
>> > probably the easiest option...
>>
>> It looks like the simplest thing I could do to allow inbound while
>> stopping outbound ipv6 would be to:
>>
>> /etc/postfix/main.cf:
>>     smtp_bind_address6 = ::1
>>
>>
>> > I see on most messages here DKIM-Signature headers apparently from
>> > gmail: "v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com
>> > <http://gmail.com>; s=20120113;". These signatures are failing because
>> > of the added message footer. No sign of a DKIM-Signature
>> > for lists.bufferbloat.net <http://lists.bufferbloat.net>. You'd need to
>> > set that up in the list MTA.
>>
>> Honestly my "email-fu" has declined considerably in recent years.
>> Despite the apparent simplicity of this idea, my brain just crashed
>> multiple times on setting it up with postfix + mailman 2.
>>
>> And thank you for poking so deeply into this, I was A) really annoyed by
>> the bloat-list-as-spam thing and B) clueless.
>>
>> > On Fri, 30 Sep 2016 at 15:42 Dave Täht <dave@taht.net
>> > <mailto:dave@taht.net>> wrote:
>> >
>> >
>> >
>> >     On 9/30/16 1:02 AM, Toke Høiland-Jørgensen wrote:
>> >     > Neil Shepperd <nshepperd@gmail.com <mailto:nshepperd@gmail.com>>
>> >     writes:
>> >     >
>> >     >> I think I have now accumulated enough spam/nonspam classified
>> > emails
>> >     >> to make a statistically signification observation: it seems like
>> > all
>> >     >> emails classified as spam from these lists were send from ipv6:
>> >     >>
>> >     >> SPF: PASS with IP 2600:3c03:0:0:f03c:91ff:fe61:86ce
>> >     >>
>> >     >> All emails from bufferbloat.net <http://bufferbloat.net> lists
>> >     are failing DKIM (because of the
>> >     >> mailing list footer breaking the DKIM signature) which might be
>> > worth
>> >     >> fixing, and failing DMARC because all mailing lists fails DMARC
>> >     >> (however google does not have a strict DMARC policy so that
>> > shouldn't
>> >     >> matter, I hope).
>> >     >>
>> >     >> By the way, it's not just you, either. I have emails from others
>> > on
>> >     >> these lists in my spam folder.
>> >     >>
>> >     >> The distinguishing factor seems to be whether the email was sent
>> > from
>> >     >> the lists.bufferbloat.net <http://lists.bufferbloat.net> ipv6
>> >     address. Unless this address
>> >     >> corresponds to some kind of tunnel broker possibly also used by
>> >     >> spammers, I can only assume this is some kind of bug (after all,
>> > it
>> >     >> was spf validated so the address shouldn't matter at that
>> > point?).
>> >     >
>> >     > Indeed, gmail requires extra measures for IPv6:
>> >     > https://support.google.com/mail/answer/81126 (scroll down to
>> >     "Additional
>> >     > guidelines for IPv6").
>> >     >
>> >     > Fixing DKIM might be worthwhile :)
>> >
>> >     But it passes the spf check?? And the reverse lookup is correct.
>> >
>> >     How about I just disable ipv6?
>> >
>> >     Have no idea why dkim doesn't work.
>> >
>> >     >
>> >     > -Toke
>> >     > _______________________________________________
>> >     > Cake mailing list
>> >     > Cake@lists.bufferbloat.net <mailto:Cake@lists.bufferbloat.net>
>> >     > https://lists.bufferbloat.net/listinfo/cake
>> >     >
>> >     _______________________________________________
>> >     Cake mailing list
>> >     Cake@lists.bufferbloat.net <mailto:Cake@lists.bufferbloat.net>
>> >     https://lists.bufferbloat.net/listinfo/cake
>> >
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

Re: [Cake] cake for net-next 4.8

[Dave Täht]

On 10/3/16 2:17 PM, Neil Shepperd wrote:
> Gmail spam team got back to me; they have apparently "fixed the
> problem", which I guess means messages here should stop being marked as
> spam soon. Because gmail's spam filters are top secret business, I
> couldn't tell you anything else :)

It is great to have friends (in places high and low). Thank you!

That said, I almost, but not quite, got the dkim stuff working the other
day - not that I can intuit that was the source of the problem!

> 
> On Fri, 30 Sep 2016 at 17:10 Dave Täht <dave@taht.net
> <mailto:dave@taht.net>> wrote:
> 
> 
> 
>     On 9/30/16 1:37 PM, Neil Shepperd wrote:
>     > Disabling ipv6 (at least in the mail server, in outgoing direction) is
>     > probably the easiest option...
> 
>     It looks like the simplest thing I could do to allow inbound while
>     stopping outbound ipv6 would be to:
> 
>     /etc/postfix/main.cf <http://main.cf>:
>         smtp_bind_address6 = ::1
> 
> 
>     > I see on most messages here DKIM-Signature headers apparently from
>     > gmail: "v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com
>     <http://gmail.com>
>     > <http://gmail.com>; s=20120113;". These signatures are failing because
>     > of the added message footer. No sign of a DKIM-Signature
>     > for lists.bufferbloat.net <http://lists.bufferbloat.net>
>     <http://lists.bufferbloat.net>. You'd need to
>     > set that up in the list MTA.
> 
>     Honestly my "email-fu" has declined considerably in recent years.
>     Despite the apparent simplicity of this idea, my brain just crashed
>     multiple times on setting it up with postfix + mailman 2.
> 
>     And thank you for poking so deeply into this, I was A) really annoyed by
>     the bloat-list-as-spam thing and B) clueless.
> 
>     > On Fri, 30 Sep 2016 at 15:42 Dave Täht <dave@taht.net
>     <mailto:dave@taht.net>
>     > <mailto:dave@taht.net <mailto:dave@taht.net>>> wrote:
>     >
>     >
>     >
>     >     On 9/30/16 1:02 AM, Toke Høiland-Jørgensen wrote:
>     >     > Neil Shepperd <nshepperd@gmail.com
>     <mailto:nshepperd@gmail.com> <mailto:nshepperd@gmail.com
>     <mailto:nshepperd@gmail.com>>>
>     >     writes:
>     >     >
>     >     >> I think I have now accumulated enough spam/nonspam
>     classified emails
>     >     >> to make a statistically signification observation: it seems
>     like all
>     >     >> emails classified as spam from these lists were send from ipv6:
>     >     >>
>     >     >> SPF: PASS with IP 2600:3c03:0:0:f03c:91ff:fe61:86ce
>     >     >>
>     >     >> All emails from bufferbloat.net <http://bufferbloat.net>
>     <http://bufferbloat.net> lists
>     >     are failing DKIM (because of the
>     >     >> mailing list footer breaking the DKIM signature) which
>     might be worth
>     >     >> fixing, and failing DMARC because all mailing lists fails DMARC
>     >     >> (however google does not have a strict DMARC policy so that
>     shouldn't
>     >     >> matter, I hope).
>     >     >>
>     >     >> By the way, it's not just you, either. I have emails from
>     others on
>     >     >> these lists in my spam folder.
>     >     >>
>     >     >> The distinguishing factor seems to be whether the email was
>     sent from
>     >     >> the lists.bufferbloat.net <http://lists.bufferbloat.net>
>     <http://lists.bufferbloat.net> ipv6
>     >     address. Unless this address
>     >     >> corresponds to some kind of tunnel broker possibly also used by
>     >     >> spammers, I can only assume this is some kind of bug (after
>     all, it
>     >     >> was spf validated so the address shouldn't matter at that
>     point?).
>     >     >
>     >     > Indeed, gmail requires extra measures for IPv6:
>     >     > https://support.google.com/mail/answer/81126 (scroll down to
>     >     "Additional
>     >     > guidelines for IPv6").
>     >     >
>     >     > Fixing DKIM might be worthwhile :)
>     >
>     >     But it passes the spf check?? And the reverse lookup is correct.
>     >
>     >     How about I just disable ipv6?
>     >
>     >     Have no idea why dkim doesn't work.
>     >
>     >     >
>     >     > -Toke
>     >     > _______________________________________________
>     >     > Cake mailing list
>     >     > Cake@lists.bufferbloat.net
>     <mailto:Cake@lists.bufferbloat.net>
>     <mailto:Cake@lists.bufferbloat.net <mailto:Cake@lists.bufferbloat.net>>
>     >     > https://lists.bufferbloat.net/listinfo/cake
>     >     >
>     >     _______________________________________________
>     >     Cake mailing list
>     >     Cake@lists.bufferbloat.net <mailto:Cake@lists.bufferbloat.net>
>     <mailto:Cake@lists.bufferbloat.net <mailto:Cake@lists.bufferbloat.net>>
>     >     https://lists.bufferbloat.net/listinfo/cake
>     >
> 

Re: [Cake] cake for net-next 4.8

[Neil Shepperd]

[-- Attachment #1: Type: text/plain, Size: 5485 bytes --]

Grr, looks like things are still getting spam-marked for me. I'll have to
reopen the report with gmail... In the mean time, I suppose we'll have to
keep fiddling with DKIM or turn off ipv6 again.

Damnit, so close.

On 4 October 2016 at 12:09, Dave Täht <dave@taht.net> wrote:

>
>
> On 10/3/16 2:17 PM, Neil Shepperd wrote:
> > Gmail spam team got back to me; they have apparently "fixed the
> > problem", which I guess means messages here should stop being marked as
> > spam soon. Because gmail's spam filters are top secret business, I
> > couldn't tell you anything else :)
>
> It is great to have friends (in places high and low). Thank you!
>
> That said, I almost, but not quite, got the dkim stuff working the other
> day - not that I can intuit that was the source of the problem!
>
> >
> > On Fri, 30 Sep 2016 at 17:10 Dave Täht <dave@taht.net
> > <mailto:dave@taht.net>> wrote:
> >
> >
> >
> >     On 9/30/16 1:37 PM, Neil Shepperd wrote:
> >     > Disabling ipv6 (at least in the mail server, in outgoing
> direction) is
> >     > probably the easiest option...
> >
> >     It looks like the simplest thing I could do to allow inbound while
> >     stopping outbound ipv6 would be to:
> >
> >     /etc/postfix/main.cf <http://main.cf>:
> >         smtp_bind_address6 = ::1
> >
> >
> >     > I see on most messages here DKIM-Signature headers apparently from
> >     > gmail: "v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com
> >     <http://gmail.com>
> >     > <http://gmail.com>; s=20120113;". These signatures are failing
> because
> >     > of the added message footer. No sign of a DKIM-Signature
> >     > for lists.bufferbloat.net <http://lists.bufferbloat.net>
> >     <http://lists.bufferbloat.net>. You'd need to
> >     > set that up in the list MTA.
> >
> >     Honestly my "email-fu" has declined considerably in recent years.
> >     Despite the apparent simplicity of this idea, my brain just crashed
> >     multiple times on setting it up with postfix + mailman 2.
> >
> >     And thank you for poking so deeply into this, I was A) really
> annoyed by
> >     the bloat-list-as-spam thing and B) clueless.
> >
> >     > On Fri, 30 Sep 2016 at 15:42 Dave Täht <dave@taht.net
> >     <mailto:dave@taht.net>
> >     > <mailto:dave@taht.net <mailto:dave@taht.net>>> wrote:
> >     >
> >     >
> >     >
> >     >     On 9/30/16 1:02 AM, Toke Høiland-Jørgensen wrote:
> >     >     > Neil Shepperd <nshepperd@gmail.com
> >     <mailto:nshepperd@gmail.com> <mailto:nshepperd@gmail.com
> >     <mailto:nshepperd@gmail.com>>>
> >     >     writes:
> >     >     >
> >     >     >> I think I have now accumulated enough spam/nonspam
> >     classified emails
> >     >     >> to make a statistically signification observation: it seems
> >     like all
> >     >     >> emails classified as spam from these lists were send from
> ipv6:
> >     >     >>
> >     >     >> SPF: PASS with IP 2600:3c03:0:0:f03c:91ff:fe61:86ce
> >     >     >>
> >     >     >> All emails from bufferbloat.net <http://bufferbloat.net>
> >     <http://bufferbloat.net> lists
> >     >     are failing DKIM (because of the
> >     >     >> mailing list footer breaking the DKIM signature) which
> >     might be worth
> >     >     >> fixing, and failing DMARC because all mailing lists fails
> DMARC
> >     >     >> (however google does not have a strict DMARC policy so that
> >     shouldn't
> >     >     >> matter, I hope).
> >     >     >>
> >     >     >> By the way, it's not just you, either. I have emails from
> >     others on
> >     >     >> these lists in my spam folder.
> >     >     >>
> >     >     >> The distinguishing factor seems to be whether the email was
> >     sent from
> >     >     >> the lists.bufferbloat.net <http://lists.bufferbloat.net>
> >     <http://lists.bufferbloat.net> ipv6
> >     >     address. Unless this address
> >     >     >> corresponds to some kind of tunnel broker possibly also
> used by
> >     >     >> spammers, I can only assume this is some kind of bug (after
> >     all, it
> >     >     >> was spf validated so the address shouldn't matter at that
> >     point?).
> >     >     >
> >     >     > Indeed, gmail requires extra measures for IPv6:
> >     >     > https://support.google.com/mail/answer/81126 (scroll down to
> >     >     "Additional
> >     >     > guidelines for IPv6").
> >     >     >
> >     >     > Fixing DKIM might be worthwhile :)
> >     >
> >     >     But it passes the spf check?? And the reverse lookup is
> correct.
> >     >
> >     >     How about I just disable ipv6?
> >     >
> >     >     Have no idea why dkim doesn't work.
> >     >
> >     >     >
> >     >     > -Toke
> >     >     > _______________________________________________
> >     >     > Cake mailing list
> >     >     > Cake@lists.bufferbloat.net
> >     <mailto:Cake@lists.bufferbloat.net>
> >     <mailto:Cake@lists.bufferbloat.net <mailto:Cake@lists.
> bufferbloat.net>>
> >     >     > https://lists.bufferbloat.net/listinfo/cake
> >     >     >
> >     >     _______________________________________________
> >     >     Cake mailing list
> >     >     Cake@lists.bufferbloat.net <mailto:Cake@lists.bufferbloat.net>
> >     <mailto:Cake@lists.bufferbloat.net <mailto:Cake@lists.
> bufferbloat.net>>
> >     >     https://lists.bufferbloat.net/listinfo/cake
> >     >
> >
>

[-- Attachment #2: Type: text/html, Size: 9591 bytes --]