AFAIK (IDK how either) this hasn't been a big issue in the past few years.
Is it really worth worrying about? I notified the MARC admin and it was
removed there within a few hours too - a dozen easily tracked messages in a
few hours and a few hours after that, it's done (or more like, filteres).
N
Hello,
As all of us know BGP was designed for scalability, thus slow
convergence. But it was also when CPU was slow :-).
What do you think about the standard eBGP hold timer of 180sec ?
Conservative ?
I'm asking because we see more and more peering partners which force the
hold timer to a
BFD is your friend. Yes it's require both parties to understand it but it much
better than 30sec hold time. BIRD already have support for BFD
> On 27 окт. 2015 г., at 10:31, "marcel.durega...@yahoo.fr"
> wrote:
>
> Hello,
>
> As all of us know BGP was designed for scalability, thus slow conve
On 27/10/2015 08:31, marcel.durega...@yahoo.fr wrote:
> I'm asking because we see more and more peering partners which force the
> hold timer to a lower value, and when BGP negotiate the timer, the lowest
> hold timer is the winner.
You need to be careful with this. On larger IXPs, there will be
low bgp timers usually done to allow faster hsrp failover result
colin
Sent from my iPhone
> On 27 Oct 2015, at 08:20, Nick Hilliard wrote:
>
>> On 27/10/2015 08:31, marcel.durega...@yahoo.fr wrote:
>> I'm asking because we see more and more peering partners which force the
>> hold timer to a
On Mon, Oct 26, 2015 at 02:48:59PM -0600, Brielle Bruns wrote:
> I get it that it is hard for large providers to be proactive about
> things going on due to the sheer size of their networks, but come
> on. That excuse only works for so long.
1. It's not hard. It's far easier for large providers t
Suppose you have the below network topology, where PE is connected to
P1, P1 is connected to P2 and P2 is connected to GW, all through 1G links.
[PE]-15001500-[P1]-16001600-[P2]-15001600-[GW]
The numbers represent the MTU values configured in the following
Hi,
> not even close to more discussing than from the original spam. Not even
> close.
data volume wise, the discussion of spam is easily beating the volume of spam
(which some people had issue with) as the SPAM emails were very small with just
a
URL - the discusions about it is now spread int
On Mon, Oct 26, 2015 at 9:40 PM, Octavio Alvarez
wrote:
> On 26/10/15 11:38, Jürgen Jaritsch wrote:
>
>
But it is originating all from different IP addresses. Who knows if this
> is an attack to get *@jdlabs.fr blocked from NANOG and is just getting
> its goal accomplished.
This is the part
Can we talk about something not SPAM for a minute?
Looking for fiber in or near Hoopeston, IL that's not the incumbent. Frontier
is the ILEC and it looks like New Wave is the MSO, but New Wave doesn't appear
to go to Chicago.
I know of networks near 57 and 65 and also McLeod's route to the so
On Tue, Oct 27, 2015 at 08:09:00AM -0400, Ian Smith wrote:
> This is the part that's been bugging me. Doesn't the NANOG server
> implement SPF checking on inbound list mail?
Don't know, but it doesn't matter: SPF has zero anti-spam value.
(I know. I've studied this in ridiculous detail using a v
On Mon, Oct 26, 2015 at 03:53:07PM -0700, Stephen Satchell wrote:
> Also, if you think what happened was a spam flood, you are very lucky.
Ironically - but alas also predictably - I have received far more list
traffic griping and moaning about this than I actually got from the spam
run.
--
Dav
Am 27.10.2015 13:09, schrieb Ian Smith:
> On Mon, Oct 26, 2015 at 9:40 PM, Octavio Alvarez
> wrote:
>
>> On 26/10/15 11:38, Jürgen Jaritsch wrote:
>>
>>
> But it is originating all from different IP addresses. Who knows if this
>> is an attack to get *@jdlabs.fr blocked from NANOG and is just g
But that's not how SPF works. In SPF, the domain of the envelope header
sender address is checked against that domain's sender policy. Since
jdlabs.fr has no policy specified, a strict SPF policy at the NANOG server
would have prevented this small issue.
As for the utility of SPF, well. It's no
On Tue, Oct 27, 2015 at 09:08:00AM -0400, Ian Smith wrote:
> But it's a bit of a stretch to say that [SPF] has zero value.
No, it's not a stretch at all. It's a statistical reality. And a single
isolated case does not alter that.
You're welcome to set up your own network of spamtraps and mailbo
I'm not making any argument about the relation of SPF compliance to message
quality or spam/ham ratio. You are no doubt correct that at this point in
the game SPF doesn't matter with respect to message quality in a larger
context, because these days messages that are not SPF compliant will simply
On 2015-10-27 13:08, Ian Smith wrote:
But that's not how SPF works. In SPF, the domain of the envelope
header
sender address is checked against that domain's sender policy. Since
jdlabs.fr has no policy specified, a strict SPF policy at the NANOG
server
would have prevented this small issue.
hosted gmail did catch some of the spam but not all , into auto junk filter due
to some of the weblinks were spammy
Colin
> On 27 Oct 2015, at 14:18, Ian Smith wrote:
>
> I'm not making any argument about the relation of SPF compliance to message
> quality or spam/ham ratio. You are no doubt
22 emails later (only counting this thread)...
Can someone with the proper privileges confirm they have the spam under
control? I think any solution would be acceptable at this point. If you all
would like to debate the pros/cons of different spam filtering theories
after the spam has subsided, I
On Tue, 27 Oct 2015, Mohamed Kamal wrote:
Suppose you have the below network topology, where PE is connected to P1, P1
is connected to P2 and P2 is connected to GW, all through 1G links.
[PE]-15001500-[P1]-16001600-[P2]-15001600-[GW]
The numbers represent
On Tue, Oct 27, 2015 at 10:18:11AM -0400, Ian Smith wrote:
> I'm not making any argument about the relation of SPF compliance to message
> quality or spam/ham ratio. You are no doubt correct that at this point in
> the game SPF doesn't matter with respect to message quality in a larger
> context,
>You can argue that envelope header forgery is irrelevant, and that corner
>cases don't matter. But I think this latest incident provides a good
>counterexample that it does matter. And it's easy to fix, so why not fix
>it?
Why do you think that the envelope addresses in the spam bore any
relati
FYI our DNS requests to resolve login.microsoftonline.com are failing because
of a DNSSEC error.
http://dnssec-debugger.verisignlabs.com/login.microsoftonline.com
http://dnsviz.net/d/login.microsoftonline.com/dnssec/
ns1 domain]$ drill -DT login.microsoftonline.com
Warning: No trusted keys
I was assuming that messages to the list were already filtered by sender,
so non-list or randomized senders would have been rejected by mailman.
-Ian
On Tue, 27 Oct 2015, Rich Kulawiec wrote:
It would be nice if it did; it would be nice if the fatuous claim
made at SPF's introduction ("Spam as a technical problem is solved
by SPF") were true. But it's not. It's worthless.
I disagree. Since implementing SPF, there have been no joe-jobs on
Bruce Curtis wrote:
>
> FYI our DNS requests to resolve login.microsoftonline.com are failing
> because of a DNSSEC error.
There's no DS record for microsoftonline.com so you shouldn't have any
DNSSEC problems with it - my servers can resolve it OK. DNSvis doesn't
show any problems. The only thin
I've seen this attack on a private list I'm on as well. It wasn't clear if the
subscribed address was being spoofed or if the user had an infected computer.
--
Mike Conlen
> On Oct 26, 2015, at 13:27, Patrick W. Gilmore wrote:
>
> I have 521 messages that match:
>To:nanog*
>Su
> On Oct 27, 2015, at 2:38 PM, Avdija Ahmedhodžić wrote:
>
> Also, ns2.bdm.microsoftonline.com is offline for about 12 hours
The problems started yesterday, more than 12 hours ago.
Thanks.
>
>> On 27 Oct 2015, at 18:35, Tony Finch wrote:
>>
>> Bruce Curtis wrote:
>>>
>>> FYI our DNS re
> On Oct 27, 2015, at 12:35 PM, Tony Finch wrote:
>
> Bruce Curtis wrote:
>>
>> FYI our DNS requests to resolve login.microsoftonline.com are failing
>> because of a DNSSEC error.
>
> There's no DS record for microsoftonline.com so you shouldn't have any
> DNSSEC problems with it - my servers
On Mon, 26 Oct 2015, Patrick W. Gilmore wrote:
Otherwise, everyone should thank the unpaid
volunteers for their gracious and excellent work day after day, year
after year. Or just STFU.
Thank you Communications Committee. What he said.
John Springer
Rich Kulawiec writes:
> On Tue, Oct 27, 2015 at 08:09:00AM -0400, Ian Smith wrote:
> > This is the part that's been bugging me. Doesn't the NANOG server
> > implement SPF checking on inbound list mail?
>
> Don't know, but it doesn't matter: SPF has zero anti-spam value.
> (I know. I've studied
Greetings NANOG Folks,
The last two NANOG meetings (San Francisco and Montreal) set records for
attendance and we hope and expect the trend of strong attendance numbers to
continue for the NANOG 66 meeting February 8-10, 2016 in San Diego, CA
which will be hosted by IIX, Inc.
The detailed NANOG6
> On Oct 27, 2015, at 3:37 PM, Bruce Curtis wrote:
>
>
>> On Oct 27, 2015, at 12:35 PM, Tony Finch wrote:
>>
>> Bruce Curtis wrote:
>>>
>>> FYI our DNS requests to resolve login.microsoftonline.com are failing
>>> because of a DNSSEC error.
>>
>> There's no DS record for microsoftonline.co
Wouldn't that be interesting -- you can't join NANOG unless your email
domain publishes an SPF record with a -all rule.
That would raise the bar AND prevent the kind of thing that happened this
weekend.
On Tue, 27 Oct 2015, Geoffrey Keating wrote:
... and thus a suitable topic for NANOG, I gue
The trouble is that this is not the NAMSOG (North American Mail Server
Operators Group). ;)
On Tue, Oct 27, 2015 at 4:59 PM, Peter Beckman wrote:
> Wouldn't that be interesting -- you can't join NANOG unless your email
> domain publishes an SPF record with a -all rule.
>
> That would raise the b
any gossip of a cable issue to algier?
randy
Not finding much but did run into this, posted within the past hour
(according to Google)
http://www.alhurra.com/content/algeria-internet/284810.html
Excerpt from Google translate "Internet service in Algeria fell to 80
percent because of damage caused, which hit the main cable that connects
betw
> http://www.alhurra.com/content/algeria-internet/284810.html
thanks, jake
randy
In article you write:
>Wouldn't that be interesting -- you can't join NANOG unless your email
>domain publishes an SPF record with a -all rule.
>
>That would raise the bar AND prevent the kind of thing that happened this
>weekend.
That's OK. It'd take about 15 minutes for the other 90% of us to
On Tue, 27 Oct 2015 17:59:29 -0400, Peter Beckman said:
> Wouldn't that be interesting -- you can't join NANOG unless your email
> domain publishes an SPF record with a -all rule.
>
> That would raise the bar AND prevent the kind of thing that happened this
> weekend.
And make a number of long-tim
Actually login.microsoftonline.com is resolving but the CNAME it points to,
login.microsoftonline.com.nsatc.net is not resolving because of a DNSSEC issue.
[ns1 ~]$ drill -k /tmp/rootkey -DT login.microsoftonline.com.nsatc.net CNAME
;; Number of trusted keys: 2
;; Domain: .
[T] . 172800 IN DNS
Also, ns2.bdm.microsoftonline.com is offline for about 12 hours
> On 27 Oct 2015, at 18:35, Tony Finch wrote:
>
> Bruce Curtis wrote:
>>
>> FYI our DNS requests to resolve login.microsoftonline.com are failing
>> because of a DNSSEC error.
>
> There's no DS record for microsoftonline.com so y
42 matches
Mail list logo
