lkml.org 
[lkml]   [1996]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: List sluggishness, and occasional deletion of people from the list
Date
	One other note.

Many, many many people with *.com domains have their dns
terribly misconfigured.

I have to set up explicit routes for people to get
mail to them on work.nether.net at times, as their domains as so
badly broken.

I will be contacting the internic about these "Lame" domains
very soon, and having them suspend domains where there are no dns
servers answering for the domain, which cause delays in relaying
others mail.

Also at the time where these date stamps mention, work.nether.net
was not relaying the mail. Another site was if i recall correctly.

And I can feel it when my desktop machine is relaying mail for
all your domains...

Also, attempt to get people to provide MX records for machines
that are on your network, and not send mail from ppp links, or at least
have your provider hold mail on their system if your ppp link goes
down.

This causes about 95% of the delays in the mailing list
relays that I do.

- Jared

Matti E Aarnio graced my mailbox with this long sought knowledge:
> Propagation delays do vary per direction..
>
> > From owner-linux-kernel-outgoing@vger.rutgers.edu Tue Jun 4 12:02:57 1996
> > To: submit-linux-dev-kernel@ratatosk.yggdrasil.com
> > Path: cortex.corpus.uni-muenster.de!not-for-mail
> > From: gutschk@uni-muenster.de (Markus Gutschke)
> > Newsgroups: linux.dev.kernel
> > Subject: This list is far too slow (Was: Re: 1.3.97 oops)
> > Date: 3 Jun 1996 19:58:39 +0200
>
> So this came thru in less than 24 hours -- from Germany
> via Yggdrasil thru VGER, and finally to me.
>
> Earlier sluggishness samples:
>
> > > MAA05711; Mon, 20 May 1996 12:46:58 -0400
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > Received: by vger.rutgers.edu id <105941-12788>; Wed, 8 May 1996 14:13:37 -0500
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > That's 12 days from one machine to the next in the same domain!

> Apparently the feed to *.com is VERY SLOW -- I suspect it
> is being fed thru some sendmail, which is dying under the
> load (while vger hums along with its zmailer ..)

Also, zmailer isn't the answer. It has been proven that sendmail
outperforms it multiple times. Although zmailers mail per domain routing
is much better than sendmails.

> There are multiple problems -- vger.rutgers.edu is VERY
> LOW POWERED MACHINE, and thus it can't deliver to the whole
> world all by itself. It needs to push some 200 000 emails
> every day, and that is more than even ZMailer can do at
> the given hardware via direct SMTP sessions. (I have
> benchmarked ZM to break the "one million messages per day"-
> mark, but it did require very powerfull machine -- like a
> magnitude more powerfull than VGER.)

Very true, but I have had sendmail boxes break the 1M mark for
a day also, and they were much more powerful also. (Ultrasparcs are cool
aren't they? :-)

> To be able to handle email to the world the VGER thus needs
> re-exploders, which usually are configured per the top-level
> domain -- *.de is routed to nic.funet.fi, *.com is routed
> to work.nether.net, etc.
> (Most of the Europe goes to nic.funet.fi, except NO and FR.
> Most of the southern part of Africa goes to paradigm.co.za,
> and most of the central/southern America go to Mexico)

> We do need email exploders to help vger -- or the lists will
> collapse. I am again calling for German, and UK sites that
> are willing to act as exploders -- you may need ZMailer in
> case your sendmail (or smail) dies under the load, though.
> I can even use multiple volunatry systems to share the load.
> ( Normally I would let VGERs real admins do the organizing
> job, but David Miller went to SGI for some project ... )
> ( Ask me about the ZMailer )

Please, please, please :-)

Perhaps dave can get us a sgi to do mail routing/delivery
on. :-)

- Jared


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.042 / U:4.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site